Ok, it’s done for now. Time to move on to other things. I really need to finish my texture path tool and, especially, Render Elements before I get back to work.
I learned a few really interesting things making this. One was how to dynamically generate GUI elements. Unfortunately, this can’t be done through a .res file. So, all dialog elements are hard coded into the .cpp file. The way I’ve done it is ok. I’m sure there are better ways. First, I count all the lights in the document, determining the number of dialog rows needed. Then, I go from top to bottom in the object manager, getting all light values and assigning them to the matching rows. I collect the lights’ BaseLinks in a BaseContainer, indexed by row, so index 27, for example, belongs to row 27. When a user interacts with the dialog, all I need to do is figure out what row he’s working with (there’s a ghetto hack I use to do this), then update that light accordingly. Instead of going through the entire document again to find that light, since I have it stored by index in a BaseContainer, I can quickly and easily grab it and update its values.
The other part that was interesting was how to get two different dialogs to work with the same data. I know there are better ways to do it, but I ended up kind of hacking it together (who cares? it works, right?). What I ended up doing was this:
Lister Dialog is the “master” for the light values. Any interaction with the lister supersedes interaction with the object manager. Then, if the dialog detects that it has been defocused (the user is interacting with a different part of the application) control is returned to Cinema, and the dialog is refreshed any time a message is sent from Cinema saying that something has changed. With lots of lights and objects in the scene, the user will probably notice a performance hit, so I would recommend closing the dialog window unless it is really needed. In other words, it should not be docked into the standard layout.