Paulo, when you ask questions involving code, please show us the surrounding function and class where (1) each of your variables are defined and (2) the code you've shown is written. In C++, it is so important to understand the scope of your variables.
Try something like this:
options.applicationName = ProjectInfo::projectName;
options.folderName = ProjectInfo::projectName;
options.filenameSuffix = "settings";
options.osxLibrarySubFolder = "Application Support";
void MyClass::setTerminalType(int terminalType)
return appProperties.getUserSettings()->getIntValue ("TerminalType", 0);
Suggestion #1: Make appProperties a class member variable. This variable must exist as long as you want to access the PropertiesFile* that it manages. Once appProperties falls out of scope, you can't use the PropertiesFile pointer that getUserSettings() returned. Which brings me to....
Suggestion #2: Don't save the pointer returned from getUserSettings() for very long. The problem with storing it is that (1) once appProperties goes out of scope, it is no longer valid (this is a correctness issue), and (2) now you have two things to keep track of instead of just one (this is a maintenance issue).
If you need to access a lot of settings, you could do this:
PropertiesFile* const props = appProperties.getUserSettings();
} // <- at this point, props falls safely out of scope,
// but appProperties is still valid so you can still call
// getUserSettings() and it will return a valid pointer
In other words, don't save props in a class member variable, but it's okay to use it as a local variable for easy access.
Hopefully you can see how important it is to understand the scope of your variables. This is why we need to see where your code is in the class, just as Rail mentioned.