Getting module (library) path

Hi Jules.

I’m developing a plugin (actually porting it from some old win32/vst code) from VST to JUCE because we want built OSX (AU, and RTAS if possible) versions.

This plugin has a bitmaps based GUI wich user could modify, and the old version just had the bitmaps (bmp) and data files along the dll, distributed like this:

Main library module (dll):

VstPluginsInstallPath/…/Company_Name/VASynth/VASynth.dll

Bitmap files:

VstPluginsInstallPath/…/Company_Name/VASynth/Skin/main.bmp
VstPluginsInstallPath/…/Company_Name/VASynth/Skin/knobs.bmp

Data files:

VstPluginsInstallPath/…/Company_Name/VASynth/Data/presets.dat
VstPluginsInstallPath/…/Company_Name/VASynth/Data/config.dat

The question is simple: looking at SystemStats members, it looks that I can get the main exe path, temp path, user directory path and application data path.

I know I should use the later (app data path) in order to store the data, but I would like to do the mostly unobstrubsive package for users, avoiding put data out of the folder where the main binary file is set.

Using Win32 is just a GetModulePath call iirc, but it could be possible to get the library pathin a “Juicy” way. and the most important question, there’s anythings in the AU version to be considered if I want to distribute the data in the same style.

If there’re problems I guess I’ll better have to use the app data path way.

What you recommend in any case?.

Thanks for your amazing library.

Regards,

Argu.

For a plugin, the app path that is returned by SystemStats is actually your plugin’s DLL file - for doing exactly the sort of thing that you’re doing…

Well, actually:

getCurrentExecutableFileName -> gives the host exe path (ie: “C:/Program Files/Image Line/FL6.exe”).

and getUserApplicationDataDirectory()

gives user data folder as:

“C:/Documents And Settings/UserName/Application Data”

What systemstats function you refer?.

Ah yes, you’re right. In fact I’ve been updating all those methods for the next version, so will get it fixed. In the meantime, you can use PlatformUtilities::getCurrentModuleInstanceHandle() to get the handle of the DLL, and use that to get the filename. That’s what it’s supposed to be doing internally, but it looks like it’s using 0 instead, sorry!