Precompiled headers (PCH) support in Code::Blocks

[mandrav]

After reading this post by tiwag, I sat down to try gcc precompiled headers once again. I had tried before, but I always stumped on a "Bad file descriptor" error when including the precompiled header...

Anyway, this time I had total success  :lol:

I 'm commiting the changes soon. All *.cpp files have changed but don't be shocked! They were only changed to include the precompiled header
OK.

The current CVS version is not aware of the PCH support, i.e. compiling the PCH from within C::B is not possible. So you 'll have to create the PCH manually. Here's how:

Create the file src/gen_pch.bat and paste the following in it:

Code

set WXBASEPATH=C:\Devel\wxWidgets-2.6.1

@rem
@rem SDK-used PCH
@rem
@echo Generating precompiled headers for SDK internal usage
@mingw32-g++.exe   -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DTIXML_USE_STL -DCB_PRECOMP -DWX_PRECOMP -DEXPORT_LIB -DEXPORT_EVENTS -Isdk -I%WXBASEPATH%\include -I%WXBASEPATH%\lib\gcc_dll\msw -I%WXBASEPATH%\lib\gcc_dllNonUnicode\msw -I%WXBASEPATH%\contrib\include -Isdk\wxscintilla\include  -IC:\MinGW\include -c sdk\sdk_precomp.h

@rem
@rem App and plugins used PCH
@rem
@echo Generating precompiled headers for plugins usage
@mingw32-g++.exe   -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DTIXML_USE_STL -DCB_PRECOMP -DWX_PRECOMP -DBUILDING_PLUGIN -Isdk -I%WXBASEPATH%\include -I%WXBASEPATH%\lib\gcc_dll\msw -I%WXBASEPATH%\lib\gcc_dllNonUnicode\msw -I%WXBASEPATH%\contrib\include -Isdk\wxscintilla\include  -IC:\MinGW\include -c sdk\sdk.h

(you might have to edit the WXBASEPATH variable)

What? Two PCHs? That's right. We need two of them, because we have two different sets of compiler options: one for the sdk and one for everything else.

*EDIT* Run a 'cvs update' to update your sources.

Now run the batch file. It is important that it doesn't produce any errors. If it does, double check the include dirs etc.
When the PCHs are ready, fire up C::B, press "Build" and behold the wonder!
Full C::B compilation takes me now about 3:30, including tinyxml, wxscintilla and wxdockit. These targets do not use PCH so they 're compiled at the usual PCH-less speed.

The C::B version that is now built, supports gcc precompiled headers natively. This means that if you check the file properties of sdk/sdk.h and sd/sdk_precomp.h (the two PCHs) you 'll see they 're set to compile. If any change is made in any of these, the relevant PCH will be rebuilt automatically

Notes to C::B devs:
The files under sdk/ use sdk/sdk_precomp.h as a PCH. All other targets (i.e. the app and plugins) must use the sdk/sdk.h PCH. I 've updated all C::B targets to use the correct PCH.

Notes to everyone wishing to use PCH for their projects:

• Create a header file in your project and #include there all your rare-changing header files.
• In C::B, right-click this header file in the project manager and select "Properties".
• Click the "Compile" checkbox and make sure it's checked.
• In all C++ source files (not headers), add #include "yourpch.h" as the very first non-comment line.
  
• Click "Build" :)

Worked like a charm for me. If you 're having problems, post them here and I 'll be glad to help you solve them

I hope I haven't forgotten anything...
Yiannis.

[mandrav]

I forgot to add that I have only updated codeblocks-wx2.6.0.cbp.
I will update the wx2.4 version later...

[Ceniza]

Hmmmm, are you sure about the order?

Shouldn't the cvs checkout/update be ran before executing the BAT?

I just made a cvs checkout, ran the BAT and now I'm going to try it

[thomas]

There is a way to do it without changing the .cpp files. I did that yesterday (although I think you need more than two .pch files. I created one for every target to be sure.).

Create the .pch files exactly as you did, but do not touch any of the .cpp files. Then add -include "sdk_precomp.h" to "other compiler options". Done.

The headers are all protected against recursive inclusion, so they're skipped immediately after the #ifdef. This is 99% as efficient, but does not require you to change a single line of code.
Compiles the whole thing in under 3 minutes. And... it is failsafe and backwards-compatible. If someone does not like precompiled headers, he can still compile normally

I have been thinking about a plugin that does this automatically for any kind of project, but haven't figured how to add an option to a project (have figured how to get to the commandline).

[mandrav]

Shouldn't the cvs checkout/update be ran before executing the BAT?

Nice catch
(edited the post)

[mandrav]

Create the .pch files exactly as you did, but do not touch any of the .cpp files. Then add -include "sdk_precomp.h" to "other compiler options". Done.

Thanks for the info Thomas
The PCH support is currently for GCC, but at the future it might (should) support all compilers that support PCHs. So, I guess, this "-include" won't work for all compilers...

[Ceniza]

Process terminated with status 0 (5 minutes, 30 seconds)

Pretty good having in mind I remove the -g and change it to -O3 -s.

Without precompiled headers it always took 11 minutes to compile

[thomas]

The PCH support is currently for GCC, but at the future it might (should) support all compilers that support PCHs. So, I guess, this "-include" won't work for all compilers...

No it won't work for all, but there is a good reason why I suggested that. Most compilers don't need precompiled headers, to be honest. It is mostly gcc that turns from "painful" to "hey, quite ok".

Takeshimiya keeps suggesting DM for its compilation speed, as you know. When I remarked that gcc is not so painful with precompiled headers at all, he replied:

As for precompiler headers, there are a lot of people that doesn't know how to use them, or don't want to (for the side effects).

You know I do not share his opinion at all regarding compilers, I think being able to compile Code::Blocks with gcc alone will do just fine for almost everybody (we are ONLY talking about compiling Code::Blocks!), and will cause the least problems (keep the code free of #ifdefs, thus better readable).

However, I must admit that he has a very valid point nevertheless. What if someone does not want precompiled headers or does not understand them...
Compiling Code::Blocks with a non-precompiled precomp.h includes 20-30 times as many include files as before - takes about 40 minutes on my machine. If you change a header and you have no clue (unless the IDE is precomp-aware), you will wonder for hours why it does not work. This can be quite a dealbreaker.

The -include solution has the advantage that it is a "pluggable" solution. It does not change anything. If you want to use precompiled headers, fine, and if you dont want to, it is fine, too.

The "final" solution which I was thinking of in my other post was something like this:
- on request, have a plugin create a precompXXX.h file for every target (scan .cpp files in project)
- put the commandline in a comment on top
- compile that, evaluate errors (yes, you cannot precompile everything)
- comment out the includes that cause trouble
- attach the -include flag to every target (with the respective file)
- on next run, check file modification for changed files, ignore the ones that are commented
- if options have changed, recompile the whole thing

That could actually be done inside the compilergcc plugin, too... as part of the actual compile.

Pretty good having in mind I remove the -g and change it to -O3 -s.

And here's the gotcha... changing options disables the precompiled header. (Edit: not all options do, but many, and it is not a trivial matter which do)
This is why I think this should absolutely be automated somehow, else there will be a lot of grief sooner or later - not everybody is aware of this. People will run the batch file and change options the other day, and will wonder why it suddenly takes an hour to build.

[Ceniza]

And here's the gotcha... changing options disables the precompiled header.

I also changed the options in the BAT file

[Urxae]

Create the .pch files exactly as you did, but do not touch any of the .cpp files. Then add -include "sdk_precomp.h" to "other compiler options". Done.

Thanks for the info Thomas
The PCH support is currently for GCC, but at the future it might (should) support all compilers that support PCHs. So, I guess, this "-include" won't work for all compilers...

I'd advise to at least take some kind if command-line switch to turn using the precompiled header on/off. Maybe just put a big #ifdef CB_PRECOMP around the contents of the precompile #includes (if you haven't done this already that is).

For my own projects I've hacked my way around it by using a (MSYS bash) shell script that precompiles headers given as command-line arguments, but only if the header has changed since the last precompile (date of .h newer than date of .h.gch). It doesn't take into account dependancies though. Oh, and it also recompiles if the script itself has changed, in case the parameters have changed.
I use this script as a 'before' command.

By the way, is there any way to extract the command-line parameters C::B passes to the compiler when compiling the current target? A ${VARIABLE} maybe? That way I could change it to use that instead of hardcoding the parameters into the script, making it more gereric. Of course, I'd need to store them so I can compare them to the parameters used last time, but that shouldn't be too problematic.

Oh, and the "Bad file descriptor" error was probably caused by this GCC bug involving #includeing the same precompiled header twice in the same translation unit (.cpp file). Though I don't know why it would stop appearing unless you didn't do that anymore somehow.

[mandrav]

No it won't work for all, but there is a good reason why I suggested that. Most compilers don't need precompiled headers, to be honest. It is mostly gcc that turns from "painful" to "hey, quite ok".

Well, I 'll have to disagree a little with you here. I work with MSVC Toolkit for some of my projects and I can tell you that without PCH, MS's compiler is much slower than it's perceived to be than when using it...
I don't have actual timings to show, but let's just say that I wasn't dazzled by the speed difference between gcc and MSVC toolkit (both without PCH).

And here's the gotcha... changing options disables the precompiled header.  (Edit: not all options do, but many, and it is not a trivial matter which do)
This is why I think this should absolutely be automated somehow, else there will be a lot of grief sooner or later - not everybody is aware of this. People will run the batch file and change options the other day, and will wonder why it suddenly takes an hour to build.

Not exactly...
Inside the PCH, all of the includes are guarded by CB_PRECOMP. If this isn't defined then it's like you didn't include the PCH file in the first place.
Your "-include" trick would need a rebuild to switch from using-PCH to not-using-PCH. So does the implemented solution.

The big advantage of the way it's done now, is that the PCH compilation is part of the project compilation, meaning it's definetely using the correct compiler flags (assuming you 've set it up properly).

I'd advise to at least take some kind if command-line switch to turn using the precompiled header on/off. Maybe just put a big #ifdef CB_PRECOMP around the contents of the precompile #includes (if you haven't done this already that is).

Actually, CB_PRECOMP is used

[rickg22]

Does it work for linux builds, too? If it does, then we're all set for RC2!

[mandrav]

Does it work for linux builds, too? If it does, then we're all set for RC2!

Not yet. I 'm looking for ways to add it (btw, does anyone know how to add pch support in autotools?).

And Rick, we 're not set for RC2. After your changes in threadpool, my C::B deadlocks quite often (0% CPU - a mutex lock). I 'm not sure it's this, but I started having these freezes right after that change. I 'm looking into it...

[tiwag]

well done Yiannis !!
i haven't had the heart to propose such because the much work you've done now...

[mandrav]

well done Yiannis !!
i haven't had the heart to propose such because the much work you've done now...

Thanks for motivating me (again), with your referenced post

[Urxae]

I'd advise to at least take some kind if command-line switch to turn using the precompiled header on/off. Maybe just put a big #ifdef CB_PRECOMP around the contents of the precompile #includes (if you haven't done this already that is).

Actually, CB_PRECOMP is used

Ah, good. I had no way to check as it doesn't seem to have propagated to anonymous CVS yet .

[rickg22]

Hmmmmmmmmmmm.... argh. Well, good luck, I guess that's all I can do...

Or maybe... does it deadlock with the "enhanced stability" on? If that's the case it could be a recursive wxYield problem. (I mention this because i haven't experienced such deadlocks in my config...)

is there any way to set or release a mutex checking the current thread #? So it won't try to lock a mutex twice in the same thread?

[mandrav]

What would be the point? Mutexes are used for isolating access to one thread at a time  :shock:

[rickg22]

Yes but I wondered if the hang was caused by a mutex being locked twice in the same thread.
Anyway is the error you talk about the same than the one reported here? http://forums.codeblocks.org/index.php/topic,1051.0.html

Erm, I better shut up, this thread is going out of topic.

[thomas]

Is it possible that this freeze is due to a screwed config file or something, completely unrelated to threads and mutexes?

After working with HEAD for a while now, I switched back to RC1-1 which I normally used for development (don't feel comfortable developing on a cvs version for some reason), and guess what....
I experienced the Rick syndrome twice within one hour. I never had it before.
So if that was not mere coincidence, the formerly stable release caught the pestilence from the afflicted one, or it is unrelated to the actual executable...  (or, I dread to think... it's been broken all the time, but nobody noticed before).

Rick:
Linux pthreads check for double locking (if requested), but Windows does not, this is explicitely documented on MSDN. So since wxWindows must take the least common denominator...

What might work for your idea, though, is something like this:

Code

static size_t LockingThreadID;

if(lockingTID == GetThreadID())
  return; // or whatever, just don't get the lock
mutex.Lock(); 
lockingTID = GetThreadID();
...
do something that needs to be protected ...
...
lockingTID = 0; // don't call wxYield now...
mutex.UnLock();
// now do what you want

This tampering with the thread id variable is obviously not thread safe as such, but hey, we aren't interested in that! We are interested to prevent the same thread from entering again. A different thread will block acquiring the lock, fair enough. And the same thread coming back through a recursive wxYield will never try to get the lock.
The only important thing is not to have anything that might call wxYield after resetting the thread id variable to zero, obviously.

[MortenMacFly]

Dear Devs,

first of all I didn't know whether to put tjhis in here (because it is related to these changes) or in the Fortran77 thread. However: I thought I let you know:

I found out that luckily (!) the the latest changes enabled the "full" Fortran (77) support via Code::Blocks! How to attach the G77 compiler has already been discussed, hence there was this problem loosing the "compile" and "link" flag for Fortran files. Thus they had to be enabled manually every time the project was re-loaded. The following changes in the code (which is taken from the current CVS branch) lead to the flags being restored "correclty" also for non-C/C++ files:

Code

//	FileType ft = FileTypeOf(filename);
    localCompile = compile;// &&
//					(ft == ftSource ||
//					ft == ftResource);
    localLink = link;// &&
//				(ft == ftSource ||
//				ft == ftResource ||
//				ft == ftObject ||
//				ft == ftResourceBin ||
//				ft == ftStaticLib);

The file-check (not including Fortran source code files) has gone.

To sum up: To enable Fortran (77) support one is required to:
1.) add the G77 compiler (just make a copy of GCC and replace the gcc compiler/linker with g77)
2.) add the Fortran file types (Project->Project tree->Edit file types & categories)
3.) enable "compile" and "link" options for the Fortran source files
...and you're done.

Works very well for me!!!

Thanks - that's making my life a lot easier!

With best regards,

Morten.

[mandrav]

Glad it works for you Morten

On another note, the autotools build system used to build C::B under non-windows platforms, is now supporting precompiled headers. Set with --enable-pch. The feature is enabled by default and is only used if the compiler really supports it.

Code

time make

<...build log snipped...>

real    5m7.585s
user    4m10.873s
sys     0m42.310s

[rickg22]

Question - shouldn't the gen_pch.bat be added to CVS?
BTW, the MinGW path should also be in an environment variable.

*Update*

Just rebuild the entire project. On my Athlon XP 1800+ it took 6 minutes, 58 seconds. Impressive

Now I have a question. If I change one of the headers, i'll have to generate the PCHs again, right?

I was wondering, if with the new dependencies stuff we could be able to make a separate Target (PCH) that consists of an MS-DOS command (the batch file) and depends on all the headers? Can it be done?

[Urxae]

Question - shouldn't the gen_pch.bat be added to CVS?

That might cause problems as it might be different for everyone (hardcoded paths), and CVS would try to version it. Maybe add a gen_pch.bat.template and have everyone copy and edit it locally.

BTW, the MinGW path should also be in an environment variable.

Actually, it shouldn't be necessary at all, MinGW automatically adds that path at the end of the include path list.

[mandrav]

Question - shouldn't the gen_pch.bat be added to CVS?
BTW, the MinGW path should also be in an environment variable.

Not really... This batch should be created and used by those who want to enable PCH support before RC2.

Now I have a question. If I change one of the headers, i'll have to generate the PCHs again, right?

I was wondering, if with the new dependencies stuff we could be able to make a separate Target (PCH) that consists of an MS-DOS command (the batch file) and depends on all the headers? Can it be done?

Now that you 've built the latest C::B, the project file contains everything needed to rebuild the PCHs automatically if they change. No need for external batch files or anything. C::B is now PCH-aware (for gcc, that is)

[rickg22]

Cool! Should we be working on the "New features in RC2" list now?

[Ceniza]

Hmmm, stc was replaced by wxScintilla, right? So... what's <wx/stc/stc.h> doing in sdk_precomp.h?

[sarcasm]
Would it be too hard to fix?
[/sarcasm]

 :?

[mandrav]

Hmmm, stc was replaced by wxScintilla, right? So... what's <wx/stc/stc.h> doing in sdk_precomp.h?

[sarcasm]
Would it be too hard to fix?
[/sarcasm]

 :?

Ooops  :oops:, my bad. You see I had tried to use PCH before and I had this file ready...
I 'll fix this ASAP.

[byo]

Ok, I tried to use PCHs in wxSmith and here's result (I don't really know what does it mean, maybe gcc bug  :?):

Code

...
ar.exe: creating propgrid\libpropgrid.a
Switching to target: wxSmith
mingw32-g++.exe   -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DTIXML_USE_STL -DCB_PRECOMP -DWX_PRECOMP -DBUILDING_PLUGIN -g -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL    -I..\..\..\sdk -I..\..\..\sdk\wxscintilla\include -Ipropgrid\include -ID:\CodeBlocks\wxWidgets-2.6.2\include -ID:\CodeBlocks\wxWidgets-2.6.2\lib\gcc_dll\msw -ID:\CodeBlocks\wxWidgets-2.6.2\lib\gcc_dllNonUnicode\msw -ID:\CodeBlocks\wxWidgets-2.6.2\contrib\include  -IC:\MinGW\include -ID:\CodeBlocks\wxWidgets-2.6.2\include -ID:\CodeBlocks\wxWidgets-2.6.2\lib\gcc_dll\msw -ID:\CodeBlocks\wxWidgets-2.6.2\lib\gcc_dllNonUnicode\msw -ID:\CodeBlocks\wxWidgets-2.6.2\contrib\include -c defwidgets\wxsboxsizer.cpp -o .objs\defwidgets\wxsboxsizer.o
In file included from defwidgets\/../wxsdefsizer.h:6,
                 from defwidgets\/wxsboxsizer.h:4,
                 from defwidgets\wxsboxsizer.cpp:1:
defwidgets\/../wxscontainer.h:4:17: calling fdopen: Bad file descriptor
In file included from defwidgets\/../wxscontainer.h:6,
                 from defwidgets\/../wxsdefsizer.h:6,
                 from defwidgets\/wxsboxsizer.h:4,
                 from defwidgets\wxsboxsizer.cpp:1:
defwidgets\/../widget.h:4:17: calling fdopen: Bad file descriptor
In file included from defwidgets\/../widget.h:15,
                 from defwidgets\/../wxscontainer.h:6,
                 from defwidgets\/../wxsdefsizer.h:6,
                 from defwidgets\/wxsboxsizer.h:4,
                 from defwidgets\wxsboxsizer.cpp:1:
defwidgets\/../wxsglobals.h:4:17: calling fdopen: No such file or directory
In file included from defwidgets\/../widget.h:16,
                 from defwidgets\/../wxscontainer.h:6,
                 from defwidgets\/../wxsdefsizer.h:6,
                 from defwidgets\/wxsboxsizer.h:4,
                 from defwidgets\wxsboxsizer.cpp:1:
defwidgets\/../wxsproperties.h:4:17: calling fdopen: No such file or directory
In file included from defwidgets\/../widget.h:17,
                 from defwidgets\/../wxscontainer.h:6,
                 from defwidgets\/../wxsdefsizer.h:6,
                 from defwidgets\/wxsboxsizer.h:4,
                 from defwidgets\wxsboxsizer.cpp:1:
defwidgets\/../wxswindoweditor.h:4:17: calling fdopen: No such file or directory
In file included from defwidgets\/../wxswindoweditor.h:9,
                 from defwidgets\/../widget.h:17,
                 from defwidgets\/../wxscontainer.h:6,
                 from defwidgets\/../wxsdefsizer.h:6,
                 from defwidgets\/wxsboxsizer.h:4,
                 from defwidgets\wxsboxsizer.cpp:1:
defwidgets\/../wxsproject.h:4:17: calling fdopen: No such file or directory

... (and few more)

I've added #include <sdk.h> almost everywhere and CB_PRECOMP define, so it should at least work.
I've noticed that there's problem when <sdk.h> is included twice.

Compiling C::B was just ... exciting, these files were compiling so fast  But this

EDIT: I've made it working with PCH-s, wxSmith can be compiled in 5 minutes on my XP 2000+ . I've even made one more step and compilation time reduced to 1 min 47 sec really, I'll write about it tomorrow somewhere in RAD forums

[tiwag]

hi byo
i just tried to compile wxsmith with your latest commit and had to do some changes until it built correctly for me.

1.) i cleaned wxsmith project and did a rebuild without using pch, i got linker errors something related to stl

2.) project cleaned by hand, ie. deleted all .obj's and .dll

3.) i manually compiled the wxsheaders.h to wxsheaders.h.gch
because the wxSmith_2_6.cbp project file has not marked the wxsheaders.h to use it pre-compiled.
(nice feature which Yiannis added into one of the very last CB commits, thanks to Yiannis btw. !!)

4.) rebuild was OK now.

really nice !

[tiwag]

@Yiannis

i just updated some of my private projects to use CB's PCH-support and would like to know,
if there is some proposed way till now, to change the compiling sequence.

* all my projects where i have added PCH support, have the relevant header file precomp.h as last file in the project list

* when i do a Rebuild, all source files get compiled without PCH and at last the header precomp.h get's precompiled to precomp.h.gch :?

* i changed the "Priority Weight" Slider of the precomp.h to 100%, but it didn't change anything

* as last resort i edited the project file and put the precomp.h at the first position of project files, 
 but it didn't change anything

? is it somehow possible to create the .gch file BEFORE the source modules are compiled when i use Rebuild Project ?

thanks

[Urxae]

3.) i manually compiled the wxsheaders.h to wxsheaders.h.gch
because the wxSmith_2_6.cbp project file has not marked the wxsheaders.h to use it pre-compiled.

Why not just mark them as precompiled yourself? (and adjust priorities, see below)

(nice feature which Yiannis added into one of the very last CB commits, thanks to Yiannis btw. !!)
[...]
really nice !

I agree

@Yiannis

Not me, but I'll answer anyway

* when i do a Rebuild, all source files get compiled without PCH and at last the header precomp.h get's precompiled to precomp.h.gch :?

* i changed the "Priority Weight" Slider of the precomp.h to 100%, but it didn't change anything

* as last resort i edited the project file and put the precomp.h at the first position of project files, 
 but it didn't change anything

? is it somehow possible to create the .gch file BEFORE the source modules are compiled when i use Rebuild Project ?

You should set the "Priority Weight" slider to 0% (or anything below the other source files at least). This one had me confused also, but basically it works the other way around than you'd expect :shock:. Lower priority weight means compiled earlier.
If you have multiple precompiled headers, and one uses the other, make sure the used one's priority weight is lower than the using one.

But this is indeed a very cool feature . Thanks, Yiannis.

[tiwag]

...You should set the "Priority Weight" slider to 0% (or anything below the other source files at least). This one had me confused also, but basically it works the other way around than you'd expect :shock:. Lower priority weight means compiled earlier....

thanks Urxae for enlightening me !! it works as you told , even when i never expected it working this way ... ( i have to improve my logic  :? isn't it ?)

But this is indeed a very cool feature . Thanks, Yiannis.

indeed it is, again, thanks too !

as i know CB is the second IDE which is able to use GCC's PCH features
(the first one was Chinook, from where i looked how it works)

[tiwag]

3.) i manually compiled the wxsheaders.h to wxsheaders.h.gch
because the wxSmith_2_6.cbp project file has not marked the wxsheaders.h to use it pre-compiled.

Why not just mark them as precompiled yourself? (and adjust priorities, see below)

yes i did it that way, thanks again !

I only wanted to post my comment about, that the project file in CVS could be optimised for that specific feature too 

[mandrav]

* i changed the "Priority Weight" Slider of the precomp.h to 100%, but it didn't change anything

As pointed out by Urxae, priority should be less than the default (50). Possibly 0 to ensure that it's compiled first.
Is it actually displaying the percent (%) sign? Because that would be wrong. Priority is a number ranging from 0 to 100, with lowest number meaning higher priority...

[tiwag]

...Is it actually displaying the percent (%) sign?

no %  sign there ! everything is OK 

Priority is a number ranging from 0 to 100, with lowest number meaning higher priority...

somehow i intuitively thought - higher number - higher priority - but this is obviously too simple 
i understand now  , and it works as intended 


thanks to all for your rapid help, tips & tricks !

[mandrav]

I added an explanation string regarding the priority setting, in the file properties dialog.

[tiwag]

I added an explanation string regarding the priority setting, in the file properties dialog.

there is another bug in this dialog
the scale title shows here by me : "  0          0        100 "     instead of      " 0       50      100 "

edit:
i understand, the middle number is the actual set value.
i'm somewhat over-worked and tired today - sorry for my lot of stupid questions which i was posting today -

[mandrav]

I added an explanation string regarding the priority setting, in the file properties dialog.

there is another bug in this dialog
the scale title shows here by me : "  0          0        100 "     instead of      " 0       50      100 "

This appearence is windows-only so I can't verify it now. But from what I remember, the middle number is the actual setting so if you move the slider it will change too...

[tiwag]

... from what I remember, the middle number is the actual setting so if you move the slider it will change too...

maybe it would be a lot clearer, if the dialog would show

Code

" Priority:    high                    xx                 low  "
"                 |   |   |   |   |   |   |   |   |   |   |    "

and xx displays the number from 0 ... 100 according to the actual setting of the slider


edit:
btw Yiannis - which tool are you using for editing the xrc dialogs ?