WPF Dataform navigation buttons

WPF Dataform navigation buttons

Old forum URL: forums.lhotka.net/forums/t/5733.aspx


emathias posted on Tuesday, November 04, 2008

I'm creating the standard form entry with add/save/delete/cancel buttons and data navigation buttons. Is there a XAML only way to implement record navigation, perhaps through ApplicationCommand? I tried binding my list through the CollectionViewSource, but seem to be having problems updating an object and having it reflected in the collection (the IsDirty is still true).

ProjectTracker doesn't have an example that uses navigation. Can anyone point me in the correct direction?

emathias replied on Wednesday, November 05, 2008

Did some more research on this after I asked the above question.  ApplicationCommand does not provide record navigation enumerations.

Does the CSLA data provider provide access to the underlying list, so that it could be provided to the CollectionViewSource in code-behind?  That would pretty much do the trick, as I could declare all the bindings in XAML, but instantiate the CollectionViewSource in code accessing the name of the csla data provider.

Or is there a totally different way to attack data navigation?

Curelom replied on Wednesday, November 05, 2008

Yes.  The data provider has a Data property that you would unbox as CollectionViewSource.

Curelom replied on Wednesday, November 05, 2008

One other note.

You can find the Navigation Commands under the NavigationCommands class, not ApplicationCommands

Other classes with useful commands are EditingCommands, ComponentCommands, MediaCommands

RockfordLhotka replied on Wednesday, November 05, 2008

Have you had luck with the WPF navigation infrastructure?

I have found it to be nothing but trouble, but I suspect I'm missing something, because it can't be as useless as it seems to be...

My specific problems are around state management. The navigation infrastructure seems to run each page in its own AppDomain, causing loss of state between pages. And using the Back button navigates back to pages where the underlying business object has been lost. And it seems impossible to navigate directly to a specific page instance (that might or might not be in history), so you can easily end up with numerous instances of "the same page", which is very confusing to a user.

I abandoned use of this technology a long time ago due to these (seemingly insurmountable) issues. I know numerous other people (including Billy Hollis) who've written their own navigation component to overcome these issues and get control over transitions and other aspects.

In CSLA .NET for Silverlight we created a Navigator component. I kind of suspect I'll back-port that concept into CSLA .NET for Windows at some point, because it is a light-weight way to handle many of these issues as well (though it would be slightly different in WPF of course).

thaehn replied on Wednesday, November 05, 2008

Rocky,

Take a look at this:

http://dotnet.org.za/rudi/archive/2008/03/27/keeping-track-of-open-windows-in-wpf.aspx

Another interesting take on it is actually in WinForms, but could be applied to WPF:

http://www.codeproject.com/KB/miscctrl/WinFormsHistory.aspx

 

and finally another idea in Silverlight:

 

http://nerddawg.blogspot.com/2008_06_01_archive.html

 

emathias replied on Wednesday, November 05, 2008

Rocky,

The minimal amount I've used the navigation, it seems to work okay. I'm still in the process of teaching myself WPF so I'm probably no judge. I watched Beth Massi's videos on the topic; she might be a good source to ask if you know her, which you likely do.

I will say this. I was totally unprepared for the learning curve on WPF. Wow.

Copyright (c) Marimer LLC