FileBasedDocument::get/setLastDocumentOpened ()


#1

this is probably a stupid question, but i’m a bit baffled as to what juce wants me to do with this pair of functions.

i’m building an application ‘document’ set of classes, allowing for simple creation of document structures that can be neatly and securely manipulated, and easily written to and loaded from a file.

i’m just having a hard time figuring out what to do with these other two pure virtual functions. doesn’t it keep an internal File for the last one opened?


#2

from what i remember you should set here the directory where the file resides, which is used in the FileChooser when loading / saving
:wink:


#3

but why is this a pure virtual function and not something hard coded into the base class itself? i’m confused, it implies there should be some kind of custom behaviour but i can’t think of anything that would be done differently, let alone what it might actually want me to do with it.

also, what about the getDocumentTitle()? Is this the same as what would be the file name? Why is this not just given a String in the FileBasedDocument class, using predefined functions?


#4

yes i find this class be a bit trivial in some parts. some things are good, but there are some pure virtuals that can be already be done virtual with base implementation… that’s why i have a FileDocument that just implements those pure virtuals that i don’t want to reimplement every time i make a new derived class…


#5

Ok, I’d better improve the comments for that stuff!

The get/set recent files methods have to be virtual because you need to be able to decide how this value is stored - whether it’s just a variable, or in a properties file. I guess the base class could implement a method to store it in a static variable, which is mostly what you’d want to do.

getDocumentTitle is virtual because the name might be generated on the fly, depending on the nature of your document. It’s not necessarily the same as the filename, it’s the name that you’d expect to display in the title bar of a window, for example. You might want to base it on the filename, in which case the function would generate the name on the fly, or the user might be able to edit it, so you’d store it somewhere else.


#6

this isn’t at all a bump, i just felt it wasn’t remotely big enough a request to start a new thread!

just for neatness, is it possible FileBasedDocument can have an additional function to retrieve the file extension already specified in the constructor? Seems a waste to have to hard-code it in more places (when making additional load/save helpers) if it’s already been specified.


#7