Handling resources attached to modules

Hi, just wondered what people do here. If we attach resources to a Projucer project we get a BinaryData object containing the data - obv this isn’t possible for modules. Wondering what people do here, do you generally provide the resources as files that are installed by the install process and then access them via file?


My workflow is to use the BinaryBuilder in the JUCE/extras/BinaryBuilder directory to create the BinaryData.h/.cpp files and give them a namespace unique to my module.

Then I copy that file into the module, including the generated files in the module.h/.cpp.

Ideally I save a little shell script to update the file (so I don’t have to look it up again).

 BinaryBuilder!  Visit www.juce.com for more info.
 Usage: BinaryBuilder  sourcedirectory targetdirectory targetclassname [optional wildcard pattern]

 BinaryBuilder will find all files in the source directory, and encode them
 into two files called (targetclassname).cpp and (targetclassname).h, which it
 will write into the target directory supplied.

 Any files in sub-directories of the source directory will be put into the
 resultant class, but #ifdef'ed out using the name of the sub-directory (hard to
 explain, but obvious when you try it...)

Ah, nice - wasn’t aware of that little extra - thanks Daniel!

Another solution that involves little changes in your workflow is to use the BinaryData::getNamedResource helper, in the module, just declare it like this:

namespace BinaryData {

const char *getNamedResource(const char *name, int &bytes);

}  // namespace BinaryData

At link time, the module will find the corresponding symbol and call it properly.

Now, instead of using BinaryData::resource_ext and BinaryData::resource_extSize in the module, you can get it like this:

int size = 0;
const char* data = BinaryData::getNamedResource("resource_ext", size);

Don’t forget to link your data with your plug-in and module, so that the module can access data.

One downside is that you have to check for errors at runtime instead of compile time, yet I find this less of a problem than having to use the BinaryBuilder.