How to set pixelz using XNA and C#
-
Send me all your codez. It's urgentz Just joking :) I do have a little problem, which is not at all unsolvable, but I just don't like to bend and tweak things just to make them fit. And, hopefully, I will not have to provide endless code listings. It's more a matter of making certain that some events happen in the right order. For a while I have been writing a GUI for XNA and now I have started on the actual game client which is supposed to use it. As expected, there have been numerous smaller and larger bugs and missing features, so that I'm not getting ahead very quickly right now. But the GUI is really getting ahead and is more up to its job every day. Last I added themes for the GUI. Among other things, the theme contains styles for controls. The styles come in two flavors: Control styles and named styles. Control styles are applied to all controls of a type. Named styles are additionally applied to all controls which explicitly request that style by name. The theme is loaded from XAML and the styles actually are simple data objects with all properties as nullable types. This allows you to incrementally apply a control style and then a named style by changing only those properties of the controls which are not null in the style. And here is where the problem begins. This would be the best sequence: 1) An instance of a control is created. All its properties are set to defaults in the constructor. 2) Apply the control style according to the type of the control. Overwrite only those properties which are not null in the style. 3) Apply a named style, if any is set, again only overwriting the properties which are not null in the style 4) Controls and forms are also loaded from XAML. If there are any properties set in the markup, they should be set last to give them the highest priority and enable them to override defaults or styles. This is how it really is: 1) An instance of a control is created. All its properties are set to defaults in the constructor. 2) Controls are instantiated when loading from XAML and the properties from the markup are set right after that. They now have the second lowest priority, not the highest as I would like. 3) Later, when the control is inserted into the GUI, further initialisation is done. At this point the control gets its reference to the loaded theme and now can find and apply its control style and its named style (if any). As I see it, there is only one way to be faster than the XAML loader: The styles must be applied in the constructor already. The
-
Send me all your codez. It's urgentz Just joking :) I do have a little problem, which is not at all unsolvable, but I just don't like to bend and tweak things just to make them fit. And, hopefully, I will not have to provide endless code listings. It's more a matter of making certain that some events happen in the right order. For a while I have been writing a GUI for XNA and now I have started on the actual game client which is supposed to use it. As expected, there have been numerous smaller and larger bugs and missing features, so that I'm not getting ahead very quickly right now. But the GUI is really getting ahead and is more up to its job every day. Last I added themes for the GUI. Among other things, the theme contains styles for controls. The styles come in two flavors: Control styles and named styles. Control styles are applied to all controls of a type. Named styles are additionally applied to all controls which explicitly request that style by name. The theme is loaded from XAML and the styles actually are simple data objects with all properties as nullable types. This allows you to incrementally apply a control style and then a named style by changing only those properties of the controls which are not null in the style. And here is where the problem begins. This would be the best sequence: 1) An instance of a control is created. All its properties are set to defaults in the constructor. 2) Apply the control style according to the type of the control. Overwrite only those properties which are not null in the style. 3) Apply a named style, if any is set, again only overwriting the properties which are not null in the style 4) Controls and forms are also loaded from XAML. If there are any properties set in the markup, they should be set last to give them the highest priority and enable them to override defaults or styles. This is how it really is: 1) An instance of a control is created. All its properties are set to defaults in the constructor. 2) Controls are instantiated when loading from XAML and the properties from the markup are set right after that. They now have the second lowest priority, not the highest as I would like. 3) Later, when the control is inserted into the GUI, further initialisation is done. At this point the control gets its reference to the loaded theme and now can find and apply its control style and its named style (if any). As I see it, there is only one way to be faster than the XAML loader: The styles must be applied in the constructor already. The
Access it through a singleton. desired objects will register to the singleton in their ctor. There might be other ways, if you simplify your question I might know. For instance when I derive from usercontrol in wpf the answer is to make the control an agregate of a new control and in that way you can better control the auto generated xaml. In other words wrap it with another control is often the way. Is that a hack? Yes, but surely the best way. I may not understand your question I'm just letting you know what comes to mind.
-
Access it through a singleton. desired objects will register to the singleton in their ctor. There might be other ways, if you simplify your question I might know. For instance when I derive from usercontrol in wpf the answer is to make the control an agregate of a new control and in that way you can better control the auto generated xaml. In other words wrap it with another control is often the way. Is that a hack? Yes, but surely the best way. I may not understand your question I'm just letting you know what comes to mind.
A reply! Great! Have some points alone for that.
rj45 wrote:
Access it through a singleton.
That's what I also thought. But that's where it really gets complicated. The required object for initialisation would be the user interface object itself. It loads graphics assets, loads configurations, loads themes and styles, sets up the input devices, starts and controls the input thread, starts and controls the rendering thread and also starts and controls the UI thread. This single object holds everything together and new controls would need a reference to it in its constructor to get acces to the current theme and also some other initialisations. Making this object a singleton would be problematic, but up to now it's also the only way I see.
rj45 wrote:
For instance when I derive from usercontrol in wpf the answer is to make the control an agregate of a new control and in that way you can better control the auto generated xaml. In other words wrap it with another control is often the way. Is that a hack? Yes, but surely the best way.
The controls I have up to now form a class hierarchy. Some also use child controls like buttons ore scrollbars internally, so I'm already 'wrapping' them. This also makes it possible to extend this hierarchy as needed.
rj45 wrote:
I may not understand your question I'm just letting you know what comes to mind.
That's quite ok. The whole thing has reached some complexity and it's hard to describe the problem at hand without getting into this complexity. I probably already could write a book about it :)
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse.