I've Wikied a code snippet to Dialog Configurations such that when starting an application the dialogs will reappear at the same position and dimension you left them in. Hopefully that can be useful to others.
The previous version only stored dialog positions. This new version also stores the dimension and whether the dialog is visible and rolled up.
Storing Dialog Configurations
Moderators: CEGUI MVP, CEGUI Team
Updated to v0.5.0.
The .xml configuration file has a new format which is incompatible with the old version. The simplest solution is to empty these files and have the program generate new data. Hopefully this will not cause too many problems.
The .xsd no longer seems to be used to validate the saved configuration. Will have to find out why.
The .xml configuration file has a new format which is incompatible with the old version. The simplest solution is to empty these files and have the program generate new data. Hopefully this will not cause too many problems.
The .xsd no longer seems to be used to validate the saved configuration. Will have to find out why.
New versions also saves the configuration of MultiColumnList.
Added the ability to specify which attributes to monitor. For Dialogs (FrameWindow) this includes one or many of: Position, Visible, and RolledUp. For MultiColumnList this includes one or many of: ColumnSequence, ColumnWidths, SortedColumn, and AscendingSort.
Also modified the loadConfigurations() function to silently ignore any errors within the XML configuration file (even the error that the file does not exist). The worse that happens is that the Dialogs and MultiColumnLists will revert to their original values.
Added a full fledged example. There's a lot of code in that example but those are mostly to make the example work. The DialogConfigurations class only requires two lines (a call to loadConfigurations() and a call to saveConfigurations()). If you do not want to manually write the XML configuration file then add one line per dialog and MultiColumnList you want to monitor.
Added the ability to specify which attributes to monitor. For Dialogs (FrameWindow) this includes one or many of: Position, Visible, and RolledUp. For MultiColumnList this includes one or many of: ColumnSequence, ColumnWidths, SortedColumn, and AscendingSort.
Also modified the loadConfigurations() function to silently ignore any errors within the XML configuration file (even the error that the file does not exist). The worse that happens is that the Dialogs and MultiColumnLists will revert to their original values.
Added a full fledged example. There's a lot of code in that example but those are mostly to make the example work. The DialogConfigurations class only requires two lines (a call to loadConfigurations() and a call to saveConfigurations()). If you do not want to manually write the XML configuration file then add one line per dialog and MultiColumnList you want to monitor.
@Rackle,
Nice job!
I have an observation.. I do not load all the windows at once. They are loaded on the fly as the user needs them (once loaded, they stay loaded). From what I can tell, the current implementation loads the saved dialog data once and attempts to set all the defaults at that time. It would be nice to have the ability to call the class and say
setConfiguration( <supply window name or pointer> ) so that it can be called at anytime.
Another idea would be to have another implementation that would use class inheritance. I say this because one usually writes a class implementation about a window. For example, someone may have a configuration.layout and have a class called CConfiguration to manipute the window, it's data, etc. So, I could see something like:
BTW, you may want to rename it from DialogConfiguration to WindowProfile and submit it as an enhancement to CEGUI. It would be something everyone would use. Then, if we can, we convence CE to make it part of the CEGUI::Window class so that any user can do something like:
Nice job!
I have an observation.. I do not load all the windows at once. They are loaded on the fly as the user needs them (once loaded, they stay loaded). From what I can tell, the current implementation loads the saved dialog data once and attempts to set all the defaults at that time. It would be nice to have the ability to call the class and say
setConfiguration( <supply window name or pointer> ) so that it can be called at anytime.
Another idea would be to have another implementation that would use class inheritance. I say this because one usually writes a class implementation about a window. For example, someone may have a configuration.layout and have a class called CConfiguration to manipute the window, it's data, etc. So, I could see something like:
Code: Select all
class CConfiguration : private CDialogConfiguration
{
// Class now loads its own dialog configuration from a profile
..
}
BTW, you may want to rename it from DialogConfiguration to WindowProfile and submit it as an enhancement to CEGUI. It would be something everyone would use. Then, if we can, we convence CE to make it part of the CEGUI::Window class so that any user can do something like:
Code: Select all
CEGUI::FrameWindow *mFW;
...
mFW.loadWindowProfile( "<file.profile>" );
...
mFW.saveWindowProfile( "<file.profile>" );
>> I do not load all the windows at once
Does winMgr.getWindow(name) from DialogConfigurations::elementStart() throw an exception in that situation? Maybe that should be improved upon with a call to ??isWindowPresent()?? and if it is then its attributes are updated.
>> It would be nice to have the ability to call the class and say
setConfiguration
Currently there are accessor functions to the saved data: getDialogSavedPosition(), getDialogSavedVisible(), getDialogSavedRolledup(). They could be replaced with a function that handles all three at once. It probably should check which attributes are monitored and only set those.
>> Another idea would be to have another implementation that would use class inheritance
This goes in the same vein. Maybe elementStart() should only parse the xml file and another function should set the configuration of the windows, such as setDialogConfiguration(const CEGUI::String& dialog = "") where passing an empty string loads the configuration of every dialog and passing a specific dialog loads (or reloads) only that dialog's configuration.
>> submit it as an enhancement to CEGUI
Nope, I disagree. Cegui is handling all the low level stuff whereas all my Wikied classes build upon the low level stuff to implement higher level features. These are biased by my own need. Besides they are coded in such a way that they integrate fairly easily within any code.
Does winMgr.getWindow(name) from DialogConfigurations::elementStart() throw an exception in that situation? Maybe that should be improved upon with a call to ??isWindowPresent()?? and if it is then its attributes are updated.
>> It would be nice to have the ability to call the class and say
setConfiguration
Currently there are accessor functions to the saved data: getDialogSavedPosition(), getDialogSavedVisible(), getDialogSavedRolledup(). They could be replaced with a function that handles all three at once. It probably should check which attributes are monitored and only set those.
>> Another idea would be to have another implementation that would use class inheritance
This goes in the same vein. Maybe elementStart() should only parse the xml file and another function should set the configuration of the windows, such as setDialogConfiguration(const CEGUI::String& dialog = "") where passing an empty string loads the configuration of every dialog and passing a specific dialog loads (or reloads) only that dialog's configuration.
>> submit it as an enhancement to CEGUI
Nope, I disagree. Cegui is handling all the low level stuff whereas all my Wikied classes build upon the low level stuff to implement higher level features. These are biased by my own need. Besides they are coded in such a way that they integrate fairly easily within any code.
Van wrote:I do not load all the windows at once. They are loaded on the fly as the user needs them (once loaded, they stay loaded). From what I can tell, the current implementation loads the saved dialog data once and attempts to set all the defaults at that time. It would be nice to have the ability to call the class and say
setConfiguration( <supply window name or pointer> ) so that it can be called at anytime.
I added applyDialogConfiguration() and applyMultiColumnListConfiguration(), which take a specific dialog/MultiColumnList name or "" to apply the saved configurations to every monitored widget.
loadConfigurations() now takes a third parameter, which instructs that function to automatically apply the configurations to the loaded dialogs/MultiColumnLists. Passing false allows you to control when the configurations are applied.
Bug fix or new feature (I haven't decided which yet). When loading the configuration file the monitored attributes are sniffed; whichever attributes are specified for a dialog/MultiColumnList are taken as the only ones we're interested in. Calling addDialog() or addMultiColumnList() after loadConfigurations() and specifying attributes to be monitored will override the sniffed attributes.
Changed the comments within the .h such that they now appear as a tooltip within Visual Studio's auto completion listbox.
Rackle wrote:>> I do not load all the windows at once
Does winMgr.getWindow(name) from DialogConfigurations::elementStart() throw an exception in that situation?
That version silently caught exceptions; there we be no visible error. However the log file does contain an entry.
Return to “Offtopic Discussion”
Who is online
Users browsing this forum: No registered users and 9 guests