I’m still experiencing a few annoying issues with the Projucer on Windows :
The global path for the user modules seems to be not working at all
When a module path somewhere is changed, the other modules seems to be updated the wrong way (for example if I have JUCE 5.0 everywhere, and then I change the path of one module for JUCE 5.2, all the other modules are saying they are on JUCE 5.2 as well even without without changing their paths)
Sometimes, the colours of the modules are not updated, for example when the path is first wrong and then right
When a module is selected, it is not possible to click on the “+” item and select a new module to add, I need to click on the window first
When I add a new group for the files to add in the project, the TextEditor is still displayed on top on a Label with a wrong content
Thanks Ivan! Sorry for the late reply, I’ve been away for the holidays and have only got around to looking at these issues today.
What do you mean by not working? I am able to add a non-JUCE module to a Projucer project using the global user module path and use it in a project as expected.
well, the time I wrote this , it was possible to pass the project name creation phase without specifying the module directory (still I dont’ understand why we should specify the module directory, are there any 3rd party modules around ? or what’s wrong doing it by default the ?Juce/modules directory ? ) Then it was not possible to select any modules on exporter paths as non of these options were available. I had to drag the modules into Projucer manually. And now with the update it seems to be fixed as we cannot pass the project name creator phase without specifiying manually the modules directory. I hope it is clear.
Yes, I have remarked this behavior with the new update.
How about the idea of leaving this box unchecked by default, so that people can start creating a new project with Projucer their layout ready by default with the modules directory.
Well the idea is that once you’ve set the global module path once, using either the dialog that pops up in the new project screen or by the “Global search paths…” menu option in the Projucer, you shouldn’t need to select it again. This path will be saved in the Projucer’s global settings and will be used whenever you create a new project.
Hi @ed95, we’re still encountering that first issue where adding user modules doesn’t seem to work properly when making them use the global user modules path.
When I make a new project I plan to add a user module to, I end up with no user module options even though my module is in ~modules:
I can add the module via “Add a module from a specified folder…”, but it isn’t recognized by the global paths option (checkbox) still. Instead, user modules using the global path only work by leaving the path text field blank and the global path checkbox unchecked.
After adding that module my other user modules are available, but only in the “Exporter paths” submenu rather than “Global user modules path”.
It is probably a typo, but ~modules is != ~/modules. Your path would expand to /Users/modules/ or /home/modules/ on a proper unix/linux/osx instead of the /Users/<username>/modules/ that was probably intended
Hello @ed95 ! I have a new issue to report with the Projucer (last one on develop, tested on Windows 8.1 64 bits with VS2017).
Let’s say I have all of my JUCE modules in a given project set with a local path, and some other modules set with a global path. Then, in the project, in VS2017, the references for the JUCE modules headers (say juce_dsp.h) are not the local ones set in the Projucer, but the ones in the registered global path, even if we are not supposed to use that.
I had a problem with this today because some files in the module audio_basics have been relocated in the last develop commits, and that change wasn’t there yet in master branch.
I’m not sure we can do much about that. Let’s say for example you have your global path set to ~/JUCE/modules and are using this for your JUCE modules but you have set the path for juce_core to be ~/othermodules. The Projucer will add the ~/JUCE/modules and ~/othermodules paths to the IDE’s header search paths but obviously juce_core exists in both places so it’s undefined which will actually be used.
Do you mean it’s the IDE fault if when I click say on juce_core.h then, it opens ~/JUCE/modules/juce_core/juce_core.h instead of ~/othermodules/juce_core/juce_core.h ? If that’s the case then indeed you can’t anything about it.
Anyway, in general I use either everything in global mode or everything in local mode. Maybe the right solution would be to prevent mixing of the two options in a given project in the Projucer…
Both search paths are added to the IDE so I think it’s just up to the IDE at that point which will be used. Like you said the best solution is just not to mix the two but there might be some cases in which you want to do that like for example if you are adding a new module or a user (non-JUCE) module.
It’s me again !
