Topic: Coding new windows in the new GUI system

[Ves]

Hi all,

Let me just start by praising the new GUI system. The way that it works and very easy lets us setup the layout of a window is amazing, saving both alot of time and lines of code!

I am coding a new window in the Extended version, and as far as I understand, all the GUI features are fully ported over, so that it should be 1:1 with the Standard version.

With this new window (I had it originally coded with the old GUI, but I am rebuilding it from the bottom up) things have mostly been running on rails, apart from one feature, which I consider is essential to how my window is supposed to work:

I want a combobox and a textinput to be located at the same position, one hiding while the other is displayed (which is determined by another combobox).
However, there are no way at all that I can get them to display and hide properly.

What happens is that the object which is hidden at the initial opening of the window will not display properly when called for. I have tried to use the .set_visible(), I have tried to .remove_all() and then .add_component() the correct component. I can get either to show up at the same location (it happens automatically, because I let the two objects share its own aligned container, which I have in turn add_component()-ed in its correct place), but the faulty one will show up as an all mangled version.
The combobox have all buttons on top of each other, and if I code it in reverse, so that it is the textinput that is the nondefault, it shows up only as a small tiny dot.

If I, as an experiment, turns on and off another combobox, it behaves similarly, only it also have lost its position info.
If I try it with a regular checkbox button (square_state), it keeps its text and appearence, but it looses its position data (ie drawn as the first object in the table, behind existing objects), and also its length of the text going next to the button was dotted at the end like: "reverse_sor..." instead of "reverse_sort_order" as it should have been.

So either I have made some grave mistakes in my definitions, or there is a bug in the new GUI system, where an object cannot be initiated as hidden.
Can you guys help me with this?

[Dwachs]

Invisible elements are not taken into account when computing sizes etc. So if you change visibility, then some elements might not have correct position and size, and also size could be too small.

Does it help to call reset_min_windowsize() after the visibility is toggled? or call resize(coord(0,0)). Then sizes and positions of all elements are recomputed.

[Ves]

Thank you for your assistance!
How do I get to call those functions from within a gui_aligned_container?

[prissi]

I would strongly sugegst to do the main even handling in the dialog, not int he containers.

However,their may be an easier solution to you problem. A comobox has already a textinput, and new texts can be entered (like in the depot and other places when renaming lines. So just make it a combobox with one (editable) entry.

[Ves]

Oh, okay.
But how would you then code this kind of window?

A window containing four main tabs. Inside each tab there are a very complicated gui layout with specific functions, each requiring 4-5000 lines of code.

I assumed it would be ok to code the content of the specific tabs inside a gui_aligned_container, only having the parent window contain the main tab itself.

[prissi]

Usually I would make a new component (like gui_schedule recently) which is a class derivated from gui_aligned_container. That is fine. You have to send a message to the window (i.e. call call_listner with a special parameter) to initiate the resize of the tab. Because this does not know that its content changed.

[Ves]

Thank you, yes I have indeed made the setup like your gui_schedule, where I have derivated it like you did:

Code: [Select]

class gui_vehicle_manager_t :
public gui_aligned_container_t,
public gui_action_creator_t,
public action_listener_t
{

}
I have looked at the gui_schedule, but I dont seem to get the hang of it. I cant work out what parameter to send (I just want the window to resize, at the moment), and I dont understand how the parent window will recieve the value which is sent. In the gui_schedule_t::action_triggered there are only the actual buttons.
Can you elaborate, or perhaps point me in the right direction where I can read more about this?

[prissi]

On revert schedule, entries may have been removed. Hence gui_schedule calls action with the parameter 0. The main dialoge then in init uses vehicle_manager.action_listerner( this) and in the action_triggered() routine the main dialkoge checks for comp=&vehicle_manager and if p.i==0 (or whatever value you decided) calls reset_min_windowsize()

[Ves]

Thank you very much, this worked!
And also, the resize(scr_coord(0,0)) does indeed update the combobox/textinput switch, although I might investigate the method you described, Prissi, with retaining the combobox.