Hello Jules !
I just want to tell you that I need to comment manually the line 49 of juce_graphics.h each time I get the new Juce library with GIT. Indeed, I’m working with Windows XP, and I don’t have the SDK of Windows 7, so I can’t use the DirectWrite functions. So, I can’t compile anything if the JUCE_USE_DIRECTWRITE macro is activated. It is possible to add something in the library so this macro is not included all the time by default ?
Thanks !
:roll: The reason that it’s a macro is so you don’t have to hack the code to remove it! The introjucer has a box to disable it in that module’s settings, or you could manually put a define in your AppConfig.h file, or even just define it as 0 in your IDE’s project settings!
I had troubles using the IntroJucer to create a new plug-in project for Windows XP and Visual Studio 2008, and I needed to use this “hack” to compile it successfully.
After trying again to compile something from scratch, I think it has more something to do with the behaviour of the IntroJucer when I’m using it without copying the modules inside my project folder(retrieved today from GIT). I’m missing something maybe, but when you select in the IntroJucer that you don’t want all the Juce files to be copied into your own project, the VS file should include links to these files in their original place, shouldn’t it ? This not the case for me, and I need to include everything manually (so I don’t have any place where I can just write #define JUCE_USE_DIRECTWRITE 0 anywhere but in the juce_graphics.h, and the macro was disabled in the IntroJucer !).
Then make it a global macro definition in your project!
And so, when you want everything to work as expected in the IntroJucer, is it a must need to enable the copy of all the modules in the project folder ? Or I have missed something ? I don’t see the point of disabling the macro about DirectWrite in the IntroJucer if I need to add “#define JUCE_USE_DIRECTWRITE 0” manually in my project !
Sorry, I don’t really understand what you’re asking.
If you’re using the introjucer, then it has a handy setting that will change that macro for you. If you’re not using the introjucer, then set the macro manually in whatever way you normally set macros. Simple as that, isn’t it?
I’m using the Introjucer with Windows XP, and I have creating a plug-in project for Visual Studio 2008. I’m disabling the option to copy the modules of Juce into my project folder, which means they should be included in the project from their original place on my disk (say c:\sdk\juce\modules).
However, when I open the Visual Studio project generated, it is not linked to any of the Juce modules, and everything I have checked in the IntroJucer has no effect (like disabling DirectWrite). So, I need to include these files manually, and that’s why I had this problem with DirectWrite (which looks like to be a problem with the IntroJucer and not with what I thought first).
So now I’m wondering if I am the only one who has this issue with Windows XP + Visual Studio 2008 + Set Copying mode disabled…
I think this is a bug of the IntroJucer : my AppConfig.h and JuceHeader.h should include, obviously, all the information about the plug-in (company, ID etc.) and the JUCE modules, but this is not the case…
That works in all my own projects… Can you explain how I could reproduce it?
So I’m with Windows XP SP3. I have the last version of IntroJucer.exe (retrieved today) in “c:\SDK\Juce2”.
I open the IntroJucer, I create a new project in D:\Projets\Test which is a plug-in. I delete the exporter for Visual Studio 2010 and I add one for Visual Studio 2008. In modules, I click on “Set Copying Mode” and select “Disable”. The C:\SDK\Juce2\Module folder is selected by default into modules source folder. I save+open in Visual Studio 2008, and I have the following files generated automatically :
JuceHeader.h
[code]/*
IMPORTANT! This file is auto-generated each time you save your
project - if you alter its contents, your changes may be overwritten!
This is the header file that your files should include in order to get all the
JUCE library headers. You should avoid including the JUCE headers directly in
your own source files, because that wouldn't pick up the correct configuration
options for your app.
*/
#ifndef APPHEADERFILE_VNZK8N
#define APPHEADERFILE_VNZK8N
#include “AppConfig.h”
#if ! DONT_SET_USING_JUCE_NAMESPACE
// If your code uses a lot of JUCE classes, then this will obviously save you
// a lot of typing, but can be disabled by setting DONT_SET_USING_JUCE_NAMESPACE.
using namespace juce;
#endif
namespace ProjectInfo
{
const char* const projectName = “NewProject”;
const char* const versionString = “1.0.0”;
const int versionNumber = 0x10000;
}
#endif // APPHEADERFILE_VNZK8N[/code]
AppConfig.h
[code]/*
IMPORTANT! This file is auto-generated each time you save your
project - if you alter its contents, your changes may be overwritten!
There's a section below where you can add your own custom code safely, and the
Introjucer will preserve the contents of that block, but the best way to change
any of these definitions is by using the Introjucer's project settings.
Any commented-out settings will assume their default values.
*/
#ifndef JUCE_APPCONFIG_VNZK8N
#define JUCE_APPCONFIG_VNZK8N
//==============================================================================
// [BEGIN_USER_CODE_SECTION]
// (You can add your own code in this section, and the Introjucer will not overwrite it)
// [END_USER_CODE_SECTION]
//==============================================================================
#endif // JUCE_APPCONFIG_VNZK8N
[/code]
So, no JUCE module is linked into my project 
There is nothing in the project properties too…
Well, it clearly can’t find any modules. When you look at the modules page, presumably it’s showing nothing in the list, and you need to make sure it’s pointing at a sensible folder.
You’ve compiled the latest version from GIT, right? The last compiled binary is quite old now, and I’ll be updating it soon.
Have you tried creating the project on the same drive as the Juce folder (C:)?
I vaguely remember that due to the relative paths, when not copying the modules the Introjucer won’t find the modules if the project is on another drive. Can’t say what happens if you copy the modules as I never do this.
Chris
Jules > this is the last version of the IntroJucer, got with GIT
ckk > you are right ! Everything works if the project folder is on the same drive than the Juce SDK.
Moreover, I have created two projects called “NewProject” (the default name), and IntroJucer is opening two instances of itself with each project when I execute once the program 
In the introjucer, each export target (e.g. your Visual Studio 2010 exporter) specifies its own path where it will look for the juce folder, so you need to set those correctly.
Remember that each target is generating project files that will be used in different OSes, with completely different file systems, so you obviously have to set the path for each one individually.
I’m intrigued about it opening multiple copies of the project though - are you sure you’re not just seeing it re-load the last set of projects that were open when you quit?
I remember that there was a problem with the two instances of IntroJucer. My taskbar displayed two instances, and when I closed one, the other one closed too…
Moreover, I do confirm that there is a problem with the choice of the project folder in another drive than Juce. When I open the two projects, one on C:\ and the other one on D:, the JUCE folder is set correctly everywhere, as everything else, but the second one is incorrectly initialized in Visual Studio.
EDIT : I have seen two things odd
I’m really not convinced that this isn’t just the wrong path in your exporter. I’ll need more detailed evidence if you think there’s really something wrong.
You choose whether to enter a relative path or not! Do you actually understand the point I made in my earlier post?
My point is : “…\SDK\Juce2\modules” and “C:\SDK\Juce2\modules” are EXACTLY the same thing (the project folder is c:\test). Moreover, the second path can’t be anything else but right because it has been written automatically in one of the cases, and all the modules are detected, with their serials displayed in the IntroJucer. However, in one case everything is working, and not in the other. So there is something odd.
Moreover, someone else has the same problem with the paths…
You said it failed when they were on different drives, but these are on the same drive…?
I’ve had a quick test of both relative and absolute paths on windows, but can’t find any problems. Maybe give me some more precise instructions on exactly what to do to make it go wrong?
I have done a few tests too.
The procedure to make it going wrong is the following :
Now, if I want the bugs to appear, I can
After digging into the Introjucer code, I have found that everything is related to the function “bool ModuleList::isModulesFolder (const File& folder)” in jucer_Modules.cpp. In the case (A), the function returns true, because the function folder.getFileName() returns “modules”. The folder.fullpath is “C:\SDK\Juce2\modules”.
However, in the case (B), when this function is called, it returns false, because the function folder.getFileName() returns “c:/SDK/Juce2/modules” instead of “modules”. And so everything is working incorrectly… It looks like a bug about the separator character set incorrectly in the case (B) and not in the case (A)…
