Include <windows.h> in plug-in AppConfig.h file

Hi all! I’m working on a plug-in project that requires access to the GetModuleFileName() function,(included in <windows.h>) in the user code section of AppConfig.h

This section:

// (You can add your own code in this section, and the Projucer will not overwrite it)
#include <windows.h> 


I need to access the VST3’s executable location in the user code section before “JucePluginDefines.h” is included. Of course adding #include <windows.h> here causes issues with linking. Is there any way to achieve this functionality? Or possibly a way of customizing the way my AppConfig.h and JuceHeader.h files work to achieve it?

Thanks, guys!

Hi all! I’m working on a plug-in project that requires access to the GetModuleFileName() function,(included in <windows.h>) in the user code section of AppConfig.h

Why? This sounds like you’re doing something quite strange - use juce::File::getSpecialLocation(currentExecutableFile) reference here.

You should almost never add logic like this to a header file, it belongs in a constructor/initialization method.

Of course. It is quite a strange use case, not something I would usually do. For the specific project, I need access to the location of the executable here. It’s quite difficult to explain without sharing information about the project that I am not at liberty to share.
I was able to get things working on the Mac side with #include <CoreFoundation/CoreFoundation.h>, now trying to port that behavior to Windows.

It’s quite trivial to do this using the File APIs provided in JUCE, it’s just very strange you need to do this in a header file. Putting code before a known entry point is a very fragile design that is difficult to debug and test.

100% agreed. It’s a very specific use case.

Create a global include file… I normally name it StandardIncludes.h – instead of including JuceHeader.h include this StandardIncludes.h before anything else in all your implementation files.

In StandardIncludes.h you can have control of the order of includes before the Juce header is included…

#pragma once

#ifdef __APPLE__
    #include <MacTypes.h>           // Added for XCode 11.x to avoid ambiguity compiler errors
    #include <pthread.h>
    #include <sys/time.h>
    #define NOGDI
    #include <windows.h>

#include "../JuceLibraryCode/JuceHeader.h"



Thank you! I’m going to give this a try and see if I have any luck.

I will need declare some #defines before #include "JucePluginDefines.h" to prevent JucePluginDefines.h from overwriting them. Where do you include JucePluginDefines.h in your StandardIncludes.h method?


Are these JUCE related macros you need to define?

If they’re just global #defines (macros) then include them in StandardIncludes.h like:

#define UseEncryption 1

// Constants

constexpr static int    kParameterVersionHint = 1;

constexpr static int    g_iBetaVersionNumber = 17;

constexpr static double g_dSmoothTimeInSecs = 0.001;

JucePluginDefines.h is included in AppConfig.h (if you have the option in ProJucer enabled to use the AppConfig header)… which will be included when you include the JuceHeader.h… so define them before including the JuceHeader


They are the specific #defines found in JucePluginDefines.h
My issue is that I need the current executable directory before making a few of these #defines and including <windows.h> before <JuceHeader.h> causes linking issues in Visual Studio.
Thanks again for your help, Rail!

You can only set #defines at compile time

You need to rethink what you’re trying to accomplish at runtime



I know, with inline functions I have been able to get around that on macOS. The whole thing is a bit hacky and obviously not ideal. Though it is the only solution I’ve found to solve the issue my client presented me with.


Can you give more detail about what you are trying to accomplish?

This sounds like you’re trying to hack around a deficiency in building or packaging software, neither of which are well suited for #defines that depend on the install location of an executable (this is ultimately nonsensical, the compiler can’t know where something is loaded from!).

If you’re trying to embed assets in an executable, there are alternatives. If you need things loaded relative to the executable, there are other alternatives. If you’re trying to do something different based on the install location of a plugin, there are even more alternatives.

At runtime, I am reading an XML file that holds information for my plug-in, name, company name, unique codes, etc. From the contents of the XML file, I am setting defines found in JucePluginDefines.h This allows me to tweak certain #defines post-build.
Let me know if that helps.

As Rail pointed out, a define is evaluated at compile time, to be precise before compile time, hence the name preprocessor.

But what you can do is to use your dynamic information in callbacks of the AudioProcessor class.
E.g. in the AudioProcessor::getName().

Some of the information is in the Info.plist, so there is no way to change that dynamically.

You can’t tweak a #define post build - (#defines are the first thing evaluated by the compiler, which is why they’re called “pre-processor” directives - the preprocessor runs before anything else). What you can do (and I suspect this is what you’re doing inadvertently) is have a #define expand to a function call instead of a hard coded value.

If you want to set a #define using a configuration file, you can write a simple script to read the XML and write out a .h file, and add this as a dependency of your plugin library. This is a great use of cmake.

If you actually need this data to change at runtime, you need a fundamentally different approach like @daniel mentioned, override the methods in AudioProcessor to return data read from the file.