User changeable controls

[Wolfgang]

I have a popup panel that lets users adjust the 'theme', e.g. color, control style (3D, classic).... As you have noticed not every aspect can be changed for an existing control, so my solution was to build all panels programmatically on startup, not using any GUI files. Then, after the user has finished a new look I discard and rebuild all currently displayed panels. For this you will also need to track the z plane order of each visible panel. It's some effort, but in the end it also allows to load and save predefined themes

[gdargaud]

As I understand it, it's more than just the Z-plane order, I also need to maintain the control numbers, otherwise movectrl.fp won't work from one run to the next. So how can I do a DiscardCtrl/NewCtrl sequence while keeping the control number ? Is that even possible ?

Unless they overlab or the tab order is important (active controls), the Z-plane order shouldn't be important or am I missing something ?

[Wolfgang]

... the z-plane order of a panel is only interesting for a multi-panel configuration - if a user decides to change a theme the order of the panels, and also their minimise state etc., should remain untouched.

I cannot comment on movectrl because I have never used it; what I do is to obtain all controls of a panel programmatically using

GetPanelAttribute ( panel_handle, ATTR_PANEL_FIRST_CTRL / ATTR_NEXT_CTRL, control_id ).

[RobertoBozzolo]

---

gdargaud ha scritto:

I have found the bug but not completely worked around yet. It's the sscanf (geometryString...) on line 1235 of movectrl.c. It doesn't test if the line is absent in the ini file, and will leave garbage (uninit) values in the dimensions.

It's not a linux bug, I have it on Windows. It triggers if you save a config, then run it again with new controls on your interface. The 2nd time fails to find a dimension.

I added the following and it now mostly works:

    if (geometryString[0]=='\0') goto Error;

---

Hello Guillaume,

I have tested with movedemo project and was not able to get that -90 error you find. I tried saving a configuration and then changing the zplane order of controls: attributes are applied to the wrong controls and the effect, particularly on dimensioning, is quite impressive but no error is raised. I have them deleted some control and added a few ones but again got no error. Strange indeed but I had no time to deep into the cause of it.

Regarding your last question, one possible solution can be to manipulate the control IDs when making them movable. I haven't the source code on this PC but if you look at the function that actually reads from the parameters file you'll see the last parameter that specify whether to retrieve the control ID from disk or to pass it directly: the parameter is forced to read ID from disk but you can try experimenting to directly pass IDs to the function.