.NET (Core and Framework)

Can't implement real-world UI using XAML.

23-Jun-06 4:24

What is this[^]?

nicknotyet21-Jun-06 11:22

21-Jun-06 11:22

Here's my scenario:

I have a piece of UI that accepts that takes a value (happens to be a property on a custom object) in an edit control. When the user commits the change, the form controls are disabled and the value is applied to an underlying object, which takes a couple of seconds. When the underlying object completes the assignment of the value it fires an event indicating that the change is complete. When the event is received, the UI is enabled and the user can proceed. Should be a piece of cake.

Note: Perhaps the user experience could be designed a little better, but that is a separate issue, for now it is what it is.

After spending a couple of weeks messing around with XAML, I can't see how this can be done in XAML by a non-coding (UI person), it seems like I have to implement handlers in code behind or start building my own custom controls.

Explanation:

1) The event object is not of type Routed Event.
2) If the event was of type RoutedEventArgs, I would have to lose information that is passed in the existing event.
3) The underlying object is not a UIElement, so it can't raise that event anyway, have to subclass and create a new custom control.
4) If I implement a data binding object to catch the custom event, I have no way to "catch" the custom event or even the standard PropertyChanged notification in a useful way in XAML.
5) If I try to implement a trigger on the PropertyChange notification, I can only do so in style that cannot operate on child or parent objects (thus the form can't use a trigger and setter on propeties of the textbox)
6) Event triggers can only operate on Routed Events defined for the object in question - custom control again
7) Event triggers can only operate on the control raising the event.
8) Event triggers call handlers which are implemented in code (behind or inline).
9) yada, yada, yada

In summary, my form cannot respond to events or property changes in child objects, only the controls themselves can.
Additionally, controls only respond to predefined events, requiring sub-classing for additonal events/properties.
Finally the only events at my disposal are of type Routed Events so a limited amount of information can be provided.

Granted, today I do not have any kind of Markup language for my UI folks to use that can readily transfer to Visual Studio, but even with XAML, a programmer is still required to implement the code behind and wire the layout together. The idea that UI folks can develop applications in XAML while coders just work on DataSources and Validation objects seems to be a myth, or at least a Nirvana that NET 3.0 doesn't acheive.

Am I missing something. Seems like I am learning a whole new language and shifting to a new development paradigm just so I can import UI layout from a designer tool.

Josh Smith22-Jun-06 4:29

22-Jun-06 4:29

I feel your pain. I, too, am torturing myself with the hazy and poorly documented world of WPF. Smile | :)

IMO, the behavior you described (disabling the UI until a custom event fires) sounds like something that should not be in the XAML. From my experience with WPF so far, it seems that a layout and appearance settings should live in XAML, but any specialized behavior should be in the code-behind. Francois, the turtlenecked artiste, should not have to see the implementational details of how an app behaves.

That's just my opinion, though.

Josh

nicknotyet22-Jun-06 8:21

22-Jun-06 8:21

Agreed, I don't want Francois the artiste to know anything about my application, but it would be nice if Alex the useability/design guy were able to do build out working prototypes to show to customers.

I guess I bought into the myth that non-coders would be able to do app. development, but it doesn't seem the case unless they're doing real fluffy stuff that doesn't interact with any of our code. Unfortunately my boss bought into that myth too.

I think there is a lot to like about WPF, its just XAML that I'm having trouble with. XAML does suggest an ability to react to property changes and events, and that you should be able to write an application with it, it just doesn't really cut it for rich-client development IMHO. I'm sure that people at insurance companies writing input screens that just collect data and drop it in a DB will be quite happy with it, especially with the binding and validation hooks.

Dustin Metzgar22-Jun-06 8:32

22-Jun-06 8:32

nicknotyet wrote:
I'm sure that people at insurance companies writing input screens that just collect data and drop it in a DB will be quite happy with it, especially with the binding and validation hooks.

Having worked at an insurance company, I can tell you it's not that easy. Smile | :)

Their applications are just as demanding as anyone else's.

Logifusion[^]

nicknotyet22-Jun-06 11:28

22-Jun-06 11:28

Yes, that was kind of a gross generalization, sorry about that.

Blush | :O

You got the idea though.

Smile | :)

Josh Smith22-Jun-06 11:24

22-Jun-06 11:24

My take on the XAML/code split is a little different than yours. What I filtered out of the MS advertising mumbo-jumbo is that application devs and graphic designers can work separately, most of the time. Instead of having a GD come up with a visual theme/layout for the app and then say to the dev, "Make it look like this.", the dev can give the GD a layout and say "Make this look good."

I never picked up a notion of MS saying "With XAML, anyone can create enterprise apps!" That's been tried, always with the same obvious outcome. To me, their message (to the business world) has been "With XAML, you won't depend on your aesthetically challenged developers to make things look good."

Maybe we've been reading different MS ads, though... Smile | :)

Cheers,
Josh

nicknotyet22-Jun-06 11:27

22-Jun-06 11:27

Like I said, I bought into a myth (or rather, it was imposed upon me). Your take is consistent with the product, so I believe you and confirms my impression of XAML.

Dustin Metzgar22-Jun-06 4:42

22-Jun-06 4:42

If you have the time (yeah right), you might want to do an article search on CP for MyXAML. It's something Marc Clifton is involved with very heavily. It's similar to Microsoft's idea, just from a different approach.

Logifusion[^]

XAML / Grid

Andre xxxxxxx21-Jun-06 5:19

Andre xxxxxxx

21-Jun-06 5:19

Is the Grid-tag just good to define the layout/alignment of controls, or can be used as a true grid control?

Does it allow scrolling with a fixed header? Can I navigate through the cells with the arrow keys?

If I want an array of 20x20 edit boxes, do I have to define each edit box or can I use the ColumnDefinition/RowDefinition to get a column/row of controls?

Does the grid itself has any events to notify the parent that cell x,y has changed, is not beeing edit etc.?

Links with information about the grid would be great too.

Thanks Andre

Dustin Metzgar21-Jun-06 5:44

21-Jun-06 5:44

You might not get much help this early in the game. Not many people have been experimenting with WPF that much. However, I do suggest you start here: http://windowssdk.msdn.microsoft.com/en-us/system.windows.controls.grid(VS.80).aspx[^]

Logifusion[^]

nicknotyet21-Jun-06 6:09

21-Jun-06 6:09

I found MS to be pretty responsive, not as collaborative or quick as CP.

http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=119&SiteID=1

Andre xxxxxxx21-Jun-06 6:27

Andre xxxxxxx

21-Jun-06 6:27

Thanks, from what I've read so far the grid is not a true grid control, although Microsoft calls it so. It just defines the layout of the child controls like a table.

Dustin Metzgar wrote:
You might not get much help this early in the game.

Isn't Avalon under development since 5 years? Also after all the hype Microsoft already made around WinFX/WPF I'd expected a little bit more than a set of common controls that we already had on Win95.

I'll guess we have to wait for 3rd party controls again Sniff | :^)

Dustin Metzgar21-Jun-06 6:38

21-Jun-06 6:38

Actually, I just read in the forum posted above that they don't have a date/time picker. I guess I can understand why it's lacking in the features department because the backend of it is the most important. They're now pushing the graphics processing off to the video card, which is a big step in the right direction IMO. You might not have a date picker, but you can place 3D objects in your windows. Roll eyes | :rolleyes:

Don't worry. In a couple more years, we might actually have a workable system. Smile | :)

Logifusion[^]

Andre xxxxxxx21-Jun-06 6:48

Andre xxxxxxx

21-Jun-06 6:48

Dustin Metzgar wrote:
Don't worry. In a couple more years, we might actually have a workable system.

I like the idea of using markup to declare the UI, but so far I'm not impressed at all. The designer always ends up with invalid XAML and if I get a WPF app running it eats a lot of memory just for an other set of controls which we already have in Windows Forms and the Windows common controls D'Oh! | :doh:

And the Grid-tag is basically nothing else than the Table-tag, just that the child controls can be layered D'Oh! | :doh:

Is it possible to create custom controls using XAML? Can I invent my own tags and put it into XAML?

Dustin Metzgar21-Jun-06 6:56

Re: XAML / Grid [modified]

21-Jun-06 6:56

ABuenger wrote:
Is it possible to create custom controls using XAML? Can I invent my own tags and put it into XAML?

Yes, you can definitely write your own controls: http://windowssdk.msdn.microsoft.com/en-us/ms745025(VS.80).aspx[^]

I'm not sure about writing your own tags though. There's an xsd out there that xaml files are validated against. I imagine if they let you add your own tags, it would cause errors with the validation. It looks like the custom control they make in the article does not have its own tags.

Logifusion[^]

Josh Smith21-Jun-06 7:16

21-Jun-06 7:16

You can add your own tags into a XAML file. You need to import your class's namespace via xmlns:myNameSpace="clr-namespace:MyNameSpaceBlah" in a Window or Page tag. Then you can include your own types in XAML by writing:

<myNameSpace:MyType />

I think CP needs more .NET 3.0 space! Perhaps part of the reason that many CPians are exploring .NET 3.0 (assuming that is actually the case) is because CP hasn't launched forums for those topics yet...

Josh

-- modified at 13:16 Wednesday 21st June, 2006

nicknotyet21-Jun-06 7:15