[HELP] How to use $(codeblocks) in help system

[shajunxing]

I used $(codeblocks) in the compiler settings and have successfully made all the compile system portablely. I found some useful Win32API help files from Delphi and copied to codeblocks folder. And configured the help using $(codeblocks) but it doesn't work. Is the reason that the help system doesn't support $(codeblocks)? And how can i use these help files portablely? Thanks.

[Ceniza]

If you mean the help plugin, it only uses $(keyword), that will be replaced by the word under the cursor. If you add $(codeblocks) it will leave it just like that (same for any other word).

If what you got is a chm file, just add a new entry in the configuration dialog of the help plugin, point it to that file and that's all.

[shajunxing]

Would you please add $(codeblocks) support to help plugins? :lol: :lol: :lol:

[Ceniza]

Could you tell me what $(codeblocks) should return and why it is so important?

[thomas]

It's one of the many builtin variables that the build system supports via MacrosManager (more specifically the one that points to the location of the currently running application image's executable).

Not sure why one would need that variable for anything else but an installer post-build step, though (that's what it was made for originally).

[mandrav]

Could you tell me what $(codeblocks) should return and why it is so important?

$(codeblocks) returns the C::B installation dir and is mainly used when people put C::B in a portable medium, like a usb key, so that they don't have any absolute paths in the configuration file.

[wxLearner]

Hello,
on windows, I also like portability. One reason is, because there is no standard location for include files or libs. If you compile Code::Blocks yourself, you only have to say

Code

Manager::Get()->GetMacrosManager()->ReplaceMacros(helpfile);

in help_plugin.cpp and you're done and can locate your help files relatively to Code::Blocks. Of course it would be nicer, if there was official support.

There are some other issues with portability too, for example regrettably you can't port "User templates". The relocation-mode works much better, if the ConfigManager::GetConfigFolder() API semantics change and the currently used config directory is returned, so essential facilities like "User templates" are also portable, but regarding this discussion it looks like that won't be officially supported and you're left on your own. On windows I use a portable version with a folder for the config files next to the Code::Blocks executable, if I don't want portability I remove the folder or move the files into the profile and in relocation mode all facilities including User templates a portable. And all that with a very very small patch (in FindConfigFile in configmanager.cpp), if Code::Blocks doesn't find the config in the profile it doesn't look next to the executable but in a folder next to the executable and while changing to relocation mode in the version I use it also sets ConfigManager::config_folder to the currently used config folder relative to the Code::Blocks executable.

Thank you for all the possibilities   

[Ceniza]

Done.

[shajunxing]

Thank you very much. Now i can pack everything together and let my students use it everywhere. :lol: :lol: :lol: