ProjectInfo

1

Couild ProjectInfo be moved to the top of the AppConfig.h flie so it can be used by modules?

1 Like
2

It could… though it may not exist, depending on the user’s settings.

You could actually use it without needing it to be moved though, if you declare it as extern inside your module, e.g.

namespace ProjectInfo
{
    extern const char* const  ProjectInfo::projectName;
3

Of course. Nice one.

Why might it not exist? It’d be handy to be able to get a project name and version in some kind of generic way. (It’s for an error reporting and analytics module I use in different projects).

4

It may not exist if the user is just including modules in their non-projucer-generated project, which is a totally valid thing to do, and there’s no obligation for them to provide that header file at all.

1 Like
5

Oh that’s ok … I can ignore that case!

6

I tried to add the following in one of my juce module header

namespace ProjectInfo
{
    extern const char* const  ProjectInfo::projectName;
    extern const char* const  ProjectInfo::companyName;
    extern const char* const  ProjectInfo::versionString;
    extern const int          ProjectInfo::versionNumber;
}

But got this warning and error on XCode 13.2.1 with Projucer 6.1.5

It doesn’t compiled.

7

Probably doesn’t need those ProjectInfo:: inside the namespace curly braces

8

without those ProjectInfo:: got this error

9

I dont’ think extern things should cause a duplicate symbol… should cause it to point to one that exists somewhere :confused:

10

I also have tried to move

namespace ProjectInfo
{
    const char* const  projectName    = "Application Name";
    const char* const  companyName    = "";
    const char* const  versionString  = "1.0.0";
    const int          versionNumber  = 0x10000;
}

to the top of JuceHeader.h, before the modules #include lines, but no cigar.

The only way to make it compiled is, rebuilding the project with Global AppConfig header (previously disabled). And move the ProjectInfo namespace to the top of AppConfig header user section.

Now, my modules could access those variables even without extern as @jules suggested.

So yes please,

11

I think better practice would be to hand the information down in class constructors, that way the user is free to supply the information from ProjectInfo::projectName or any other string in the calling code.

1 Like
12

I have modules which provide helpers for calling NativeMessageBox, FileChooser (for saving and loading presets), etc. which need those information on ProjectInfo, which should be consistent either it was audio plug-ins or standalone outside its class scope.