GUI and UniGUI coding

This thread is to document my learnings as I brave the arcane world which is EoC POG GUI development. Specifically with respect to UniGUI.

Of course if anyone has information that they would like to contribute, then please drop it in here.

Otherwise stay tuned for specific info over the next few days.

Cheers,
Joco.

General EoC GUI Concepts

All controls are considered windows. Buttons, listboxes, scrollbars, text areas etc are all windows.

Windows accept events. You can link/wire pog functions to many of these events. Such functions must be exported functions with no parameters. This means you need to gain a handle to the control firing the event through code. The standard approach is usually along the lines of:
Layout
You lay your controls out using frame co-ordinates. However you can also use use windows as a means to group controls into logical chunks. The radio buttons take this a stage further in that they use the window they are grouped to drive their selection behaviour. So each group of radio buttons must be in there in there own layout window to which they are parented.

There are some specialist layout windows provided. Such as the splitter window. See the POG GUI help file for further details.

Of course if anyone has information that they would like to contribute, then please drop it in here.

Drink lots of coffee. And when you start pulling your hair out go for a walk.

Seriously; go slow and work item by item. When I built the GUI's for the Sandbox I tried to put everything on the screen at once my first try (reasoning that I could test multiple things at one time). Of course I ended up with a jumbled mess which took a week to sort out. If I had to do it all over again I'd place a button... get it right... then move on to the next.

When creating lists that need to be updated, put a parent window under them that you can delete. This causes all child windows to delete and avoids some bugs. The windows are simple and they create and destroy very quickly. The location finder code has several good examples.

See this note written in the Location Finder code:


Globals are used to communicate between all the event functions. To keep from flooding the save game files with useless global handles, use the GA_NoSave flag when creating globals. For Example:

Another approach to the global variables that is worth considering is attaching data directly to the control/window using the Object package.
I would presume that when the control is removed the associated attributes get auto cleaned for you. The global var approach will require you to explicitly clean things up.

Yes, that is a good point. And it fits well with your example. The standard way to handle lists of items (such as a list of cargo objects the player will pick from) is to attach the object directly to the button. Then inside the button event function, you can retrieve the object