8 replies to this topic

[TheNut]

I am racing through this rather menial task of hooking up a game UI in C++ and I can't help but think how I wish it had reflection to speed up development. For those of you not familiar with XAML, the entire XAML engine in WPF runs off reflection. You can construct any control type and assign any properties, behaviours, converters, and data bindings from an XML sheet and it really helps streamline development. I looked into reflection support in C++11 and noticed it was originally planned, but for reasons not explained on Wikipedia it was removed .

I am curious about your thoughts on this. Is reflection something you would use in C++ or do you prefer other avenues? Scripting is an alternative, but it's not without its drawbacks (learning curve, bindings, maintenance, etc.). From my position, I just want to minimize development effort.

[Reedbeta]

I've thought sometimes of building a very, very simple UI description language that would get translated into C++ and compiled as part of the project. I could then write "lambdas" in C++ syntax and have the translator generate all the boilerplate - setup, message handlers, callbacks, etc. Something like:

dialogbox title="A Dialog Appears"
    button title="Click Me!" action={ g_pRenderer->ActivateCoolMode(); }
    textbox title="Your Name:" get={ return pPlayer->m_strName; } set={ pPlayer->m_strName = value; }
end

This wouldn't involve any reflection and it would require recompiling when you wanted to change the UI, but it'd be better than having to do everything yourself.

[TheNut]

An interesting approach, although it could be non-ending to support complex scenarios. For example, what if you wanted the title text to be localized? You would need to change that so it fetches the text string from a dictionary. Or if you want to change the text of a label based on an observable value in a model object, you need to setup some sort of event handler for that. In a similar scenario, you may need to convert the input first before sending it to the label. More often then not, I find UI logic non-ending in requirements, which is why I alleviate the problem by assigning behaviours to controls, often they are reusable too. A single behaviour would be responsible for binding localized strings to the control, another behaviour will execute some logic behind the scenes, and so on.

<Button Name="BtnPingServer">
    <interaction:Interaction.Behaviors>
       <behaviours:LocalizedButtonCaptionBehaviour Key="text.ping" />
       <behaviours:PingServerBehaviour IP="{Binding Model.Server.IP} " />
    </interaction:Interaction.Behaviors>
</Button>

In my current predicament, I have to instantiate these behaviours manually. It's the closest I've come to a near XAML solution.

[Reedbeta]

Yeah, when I had that idea I was thinking of development UI where you just need something quick and dirty to live-edit your shadow map settings or whatever. I'm sure it would fall over as soon as you tried to do something complex and shippable-quality with it.

Do you know any good introductions to XAML/WPF? I don't have any experience with it, but I keep hearing people say positive things about it. I tried reading some of the MSDN docs and couldn't really make heads or tails of it, though. They didn't give me enough context to understand what everything was for.

[TheNut]

Silverlight implements a clean version of WPF, which is what I recommend to anyone learning this stuff. Silverlight.net use to be a good source to start out, followed by the MSDN docs once you got the knack of it (I know that's prolly not what you want to hear :). A lot has changed over the years though and I'm not sure how much these websites have kept up. As I mentioned earlier, XAML is really just an XML doc that relies heavily on reflection to construct instances of objects. A lot of the powerful things you do in XAML is not necessarily native to WPF. For example, the behaviours I mentioned above is actually a custom component. It's not something you just run into WPF expecting to be there (although the original concept was coined by Microsoft). Same goes for any sort of MVC or fancy dynamic runtime user interfaces.

Perhaps the best order of execution would be to learn WPF layouts -> basic controls -> styles & resources -> custom controls (there are two kinds, UserControl and Control, both significantly different) -> storyboards (if you're into animations) -> MVC / MVVM / MEF -> dependency properties -> data binding -> converters. After this, it's just a matter of playing around with it until you get proficient and discover new ways to design UI.

[Stainless]

It depends on the application for me.

For tools and applications where functionality is more important than look and feel, using a generic solution is the way to go. GUI designers are ten a penny and finding one that does everything you want is feasible.

For games though, I have never, ever, (and that's in 30 years of games coding) found a generic solution that is usable. I always hit problems with all generic solutions and end up coding a new one per game.

Might be me being picky, but when I get an idea in my head about what I want on the screen, that's what I get even if I have to write a complete new GUI.

When it comes to reflection, I don't think the powers that be will ever allow it into c++. With C# you have full support for reflection and I have used it in the past to reverse engineer, and bug fix third party dll's.

I don't think that's something that c++ developers really want.

[alphadog]

Exactly how is reflection used with XAML? (Googling, of course, leads to lots of posts on "mirror" reflection, not "code" reflection.)

Because, not knowing about it, and reading your post, I'm thinking what you are looking for is found in functional programming or maybe aspect-oriented programming?

[TheNut]

You probably won't find anything because the mechanics behind XAML and WPF are closed to the public. XAML itself is just a declarative language based on XML. Internally, WPF uses reflection to instantiate objects defined in a XAML sheet at runtime that you can then retrieve and interact with in code.

<xml>
<Image Name="ImgControl" Source="somewhere/hello_world.jpg" />

Basically does the following for you:

System.Windows.Controls.Image image = new System.Windows.Controls.Image();
image.Source = "somewhere/hello_world.jpg"

Although this is a very simple example and the C++ equivalent system I wrote has no problems loading a wide variety of control types or custom ones you may need to write. The real problem comes from giving these controls logic. The more you can do in a declarative language like XAML, the less you have to do in code.

<Image Source="{Binding Model.Instance.ImageUrl}">
	 <interaction:Interaction.Behaviors>
  	    <behaviours:MyCustomBehaviour... />
</Image>

All of a sudden you have pages of code to setup bindings, observers, and behaviours for each user control. It's trivial stuff, but really lengthy and kills brain cells. There are alternatives such as scripting languages and probably even functional languages (albeit I never touched any of them except for a tad of prolog), but it's one of those things that got me thinking what if C++ had reflection. Especially since there were plans to add it in C++11, but it fell off the list for some reason.

[alphadog]

Thanks. I generally know how to use reflection to support instanciating objects from a declarative markup or DSL. Just wanted to make sure that where you were going with your question.

So, I guess my question is: what can't you do, in the context of something like supporting an XAML-like declarative language, with templates and other C++ features, where reflection would solve the issue?

I also remembered these articles. Had to look them up as I read them months ago:
http://www.altdevblo...1-introduction/
http://www.altdevblo...-splinter-cell/