(Another) enhancement for compiler interface GUI (+patch)

[thomas]

You should now be able to upload .patch files as well.

[MortenMacFly]

First of all: Great it has been accepted. Thanks!

1. you can only clear the list if an item is selected (contra-intuitive)
2. the four buttons are a little too wide now, we may have to play with margins
3. you used a wxMessageBox which you shouldn't

ad 1.)
I actually thought and realised the same, but I thought it's my fault... ;-)
ad 2.)
I tried reducing from 8 to 5 as you suggested and it indeed looks better. I just did a copy&paste, not thinking about cosmetic things.
ad 3.)
The method was initially a copy&paste from OnRemoveLibClick. The one who implemented the wxMessageBox there is to blame... :lol: :lol: :lol:. Anyway: At work I do have a dual-monitor system. But I never realised this issue because I always do the coding on the first (primary) monitor. But interesting to know anyway. Is this something that should be reported to the wxWidgets team?
Morten.

[thomas]

Is this something that should be reported to the wxWidgets team?

There is nothing they can do about it, it is due to what wxMessageBox does... it simply calls the MessageBox (or whatever it's called in GTK) function provided by the OS, so the message shows up somewhere. A message dialog on the other hand, has to be shown explicitely, so it can be placed first (AnnoyingDialogs do it automatically).

All other dialogs are (provided you enabled the setting) placed by Code::Blocks before they are shown -- with three notable exceptions:
1. wxProgressDialogs show instantly when they are created, so they show on the wrong display first and are placed correctly on the next vertical refresh (no, don't laugh, seriously!).
2. wxFileDialog and wxDirDialog under Windows don't work properly because Windows is so super smart as to remember the last position where these were opened. Thus, if you open Code::Blocks on the secondary screen, open a file selector, move the main window to the primary screen and open another file selector, it will show on the wrong screen, even though you explicitely placed it differently.
3. A few rare dialogs may actually have slipped through our fingers yet 

The actual placement works quite reliably under Windows, but it is really pathetic under GTK. That is mainly because the guy who wrote that code has no clue about GTK or X programming at all...

Maybe someone like Der Meister or Yop could help out?