I've been dabbling in WPF for a couple of months now and I've managed to grasp most of what's about and why/when it's used but I'm still struggling to see the value of the PageFunction class.
Can someone give me a simple, but concrete example of when a PageFunction might be the correct tool for the job?
Mainly, it seems to be a pattern to formalize branching in task based UI.
Let's say you have a form with a checkmark for an optional feature, but this feature requires additional information which is too complicated to fit on the same page.
Using this pattern allows delegating information collection to another component.
Moreover, there is kind of a strategy pattern applied, since you could have various subsystems able to collect the same information, all of them inheriting the PageFunction(of T), so that the code actually calling those does not need to know any detail about it.
Those are just some ideas, I have not exactly looked into it.
PageFunction in a page = Dialog box in desktop application (without Page).
You can use a PageFunction every time you use a dialog box in a desktop application and that you want to develop a webnavigation-like behavior to your program.
The main thing page functions enable is implementing workflows with sub-tasks and managing the return stack.
If you just rely on page-to-page navigation, it's hard to pause the current navigation path, do something else, and then come back and continue. PageFunctions enable that through the concept of Returning and unwinding the navigation stack.
I provided some real world examples of this here: http://www.paulstovell.com/wpf-navigation
Related
I have built out a couple of keyboards for a touch aware app we are building in work. Since we use a controller that is aware of when the app is in touch screen mode I thought it would be nice if, in design mode, we could associate a control with a keyboard type and have the controller look after the calling of the keyboard.
One of the things I do not want to do is to sub class each type of control just to add this property as I feel it is a very heavy for small gain. I had thought of using the tag property but it is not available in all controls due to use.
I was wondering if there is a way of attaching a property to a control on design time for the purpose of adding this meta data. So to recap I would like to be able to give each control a value that would be read by the controller to decide what keyboard to show.
Yes, the designer supports this. Good examples of existing components that do this are ErrorProvider and HelpProvider. Note how they add properties to existing control types.
You'll want to implement your own component, it needs to implement the IExtenderProvider interface. The MSDN Library article for it has a good example that should help you getting it right.
I find that the winform tool tips behave very erratically. They seem to randomly decide to do nothing, show up or disappear when I perform the same hovering/clicking/etc actions.
Is there some pattern that I'm missing? Do I just not understand the UI technique to bring up a tooltip? Is this a common problem? Do people actually expect tool tips to work this way?
Tooltips display automatically. That's a bit of a problem, the native Windows control has counter-measures in place to avoid displaying tips too often, potentially wearing out the user with info that has been shown frequently enough. Not exactly sure how that rate limiting is implemented, accumulated time is a factor (like 60 seconds), possibly also the number of times it was displayed.
The SDK docs do not document the implementation details. There is also no message available to forcibly reset the rate limiter. I do think that passing another control in the Show() method resets it.
All and all, it does mean that the ToolTip control is really only suitable to act as a traditional tool tip. It doesn't work well as a 'dynamic label'. which is your alternative, a Label control with BackColor = Info. Albeit it not quite the same because you cannot easily make it a top-level window.
We were building out the next version of an in-house thick-client application using WPF/Prism (Composite Application Library). As we were nearly done with the client our team was put under new management and shortly thereafter:
We were then directed to drop the Prism framework to keep things simple. This includes not using any type of Inversion of Control.
We were directed to build out the WPF application without using MVVM or similar; and more along the lines of a traditional WinForm application. The idea is that if a developer sees a control in Visual Studio’s designer view, then (s)he should be able to click on the control and see exactly what it's doing without having to traverse through a view-model (or similar).
We have now been tasked with building out the WPF application using one primary Window, use a Frame Control to contain the content, and use a Ribbon outside of the frame for the menu items. Reason we were provided to use Frame Control:
a. We will show a view in the Frame with a Page (not a user control) and then load the page in the Frame.
b. When a new view is to be shown in the Frame, the current view (Page) will be closed/disposed and the new view (Page) will take its place in the Frame.
c. When a developer looks at the Page in design view, (s)he will be able to click on any control and see exactly what is being done.
Given the restrictions of 1 and 2 above, we’d like to present another method of building out the application that:
Can be presented as an alternative to using the “Frame Methodology” (item 3 above) but still provides the same type of functionality.
Does not use MVVM (see #1 and #2 above).
Provided the direction we’ve been given, any suggestions as to an alternative we can present? I’d request that the responses be kept on the professional level and thank you in advance.
I'd personally try to argue to use Martin Fowler's Presentation Model. (That's a joke, btw...)
Basically, you're being given a restriction that says "Use WPF, but don't use any of the features that make WPF usable." It really sounds like your requirements are such that you would be much better off explaining, reasonably, the advantages of patterns like MVVM.
It sounds like the weird requirements are really boiling down to this:
The idea is that if a developer sees a control in Visual Studio’s designer view, then (s)he should be able to click on the control and see exactly what it's doing
If that's the main issue, and the reason you're avoiding MVVM and other similar patterns, I would seriously take the time to educate the management. Looking at a Command, by name, instead of an event, by name (which is what you see in the designer) is really no more difficult.
However, in a large scale application, the separation of concerns is key. Even a properly designed Windows Forms application requires a clean separation of concerns - but with event based programming, this becomes much more difficult, especially from the designer. If you try to develop a large scale, clean, application using an event approach, you'll have event handlers, but those event handlers will all eventually need to delegate their work to a separate component.
This is actually adding an extra level of effort, from an understandability and maintenance point of view, on top of what you get with MVVM. With MVVM, you only look to the ViewModel, which is very discoverable.
BTW - The "rationale" for using a Page instead of a UserControl doesn't make any sense. You can do exactly the same thing you're describing with UserControls... The only reason to use a Frame and Page is if you want to take advantage of navigation, in which case, you can't dispose the old pages directly (or they get regenerated constantly). Also, the navigation tools probably wouldn't be used with a ribbon - the two conceptual models are quite different.
There are criticisms of MVVM which may be applicable to your project; however having unreasonable dictates of programming methodology is always a recipe for disaster.
One of the reasons that we have frameworks and spending time building layers and separation is to avoid the coding mess that always results when you can "simply click on the button in visual studio to see the code that is being executed".
There may not be a way of achieving what you've been asked to do without something similar to MVVM, because anything that has an architecture may well be labelled as being too similar.
However I have been using a system for many years that provides simple inter-object plumbing currently called Emesary you may want to read my C# .NET Emesary walkthrough.
But basically it allows my buttons to be implemented thus:
private void addButton_Click(object sender, RoutedEventArgs e)
{
GlobalTransmitter.NotifyAll(new Notification(NotificationType.CreateRecipe));
}
This may be an answer to your problem. It's under hyped, small and so simple but it just works well.
I've achieved a solution to the second question by using a Window, a user control for the ribbon bar (the user control contains the listview), and another user control for the Frame part. This second user control obvious is built using other user controls using a very simple view class. All views and controls are connected using Emesary.
As a school project I had to develop a WPF client which allowed for multiple people to make use of it at the same time. And I used Pages. My verdict: Save yourself a huge amount of effort, and use UserControls instead.
Sometimes the Page Navigator (which you'll use to scroll through) tends to bug out and cause you a lot of problems. Maybe it was my crappy coding, but who knows?
Though I must say, the control being called "Pages" is somewhat misleading... I went "Eureka!" when I found them, and swore at them thereafter.
I totally agree with #2 (MS bigs take note!). It would be cool if you could double-click a Control and it would take you straight to its command (or event if its command is lacking). However till then, make sure that you organize your Views and ViewModels in separate folders.
Having a dual screen (or a very wide one) will allow you to have two instances of VS open on the project, one focused around the View and the other around the ViewModel (my personal choice was having Expression Blend on the View).
Although not a very big application, I managed to convert my project to proper MVVM (ie. ViewModel for every UI element, RelayCommands and Mediator) in a matter of days, so once you understand it it's not too complicated to implement. Plus, there are tools out there (such as Josh Smith's RelayCommand and Marlon Grech's Mediator - totally free, by the way) which make MVVM half as difficult, and twice as powerful.
Using WPF without MVVM is like trying to eat rice without a fork. You'd be better off using WinForms if you're not going to take advantage of what WPF has to offer. My 2 cents.
I wish I could say your management is totally wrong.. but I cannot say that as it will not be the most accurate truth. I guess that the main reason to the changes you described is either because the new manager is not comfortable with the concept of MVVM being the new messiah of UI development or/and another reason could be the cost of educated sophisticated developers vs. cheap developers which can be instructed to get the things done as fast as possible, a concept which is widely known as lean development.
So, putting all I wrote so far under "not what you asked for", here is what I suggest:
you can still use object oriented pure approach, meaning you can have a model object which already have method to show UI information. so every object will be a window derived object, that way you will loose on SOC but you still going to be OOP/OOD.
But LOL, The next phase will bring you to seperation of model from view in order to not repeat the same code in many derrived windows which relay on the same data... so your management will endorse MVC/MVP as good solution .. and the distance from it to MVVM is kinda of short if they want WPF.
Conclusion: you will have to teach your manager why it is better to go for MVVM, unless the project is very short.
Using the Composite Application Guidance tools from Microsoft, It seems as if there is no mechanism to allow you to query your modules ViewModels and ask if any of them have unsaved data. This is a problem because, and I'm guilty of this as well, you cannot stop the application from terminating when there is unsaved data...
I had thought about creating an interface called IApplicationEvents and have an event on there called ApplicationExiting. The thought being that each module can subscribe to the event and, when fired, can send back a "Cancel=true" or "Cancel=false" to say whether or not to allow the application exiting.
Curious to find out what others may have done in this instance, and to see what possible solutions there are in the community to solve this issue.
Thx.
There are a lot of choices here.
First off, I wanted to clarify a little nomenclature... typically your Views or ViewModels contained within your Module assemblies are the things with unsaved changes, not the Module itself. The Module is responsible for instantiating any views necessary at the start and contributing back to the shell during Initialize and that's typically it, so when you attack this problem, you'll want to focus on your views/viewmodels and not the Module classes.
Options off the top of my head:
Adopt a complimentary framework like Caliburn that has support for application events like this (as well as some MDI events like ViewClosing, that kind of thing). It has builtin support for Prism (http://caliburn.codeplex.com/)
Use a composite command. Your views or viewmodels will register themselves with a composite command elsewhere (CloseCommand, which you declare statically for your application) and every open view will have its CanExecute and Execute methods fired so that you can both vote in the closing of the application and also react to it, should it happen anyway. CompositeCommands are a feature of Prism. (See: Commanding Quickstart)
I think those are probably the most elegant. There's a few more options but these live in the best harmony with existing conventions.
Hope this helps.
A while ago I created a drag-over check box list which allows you to check many check boxes in a single gesture. Do you think it is viable and usable on the web where people might not know how to use it. The default behaviour still works for the individual check boxes.
1 - The idea
The idea is nice and can probably be used in professional applications where you have direct contact with users and can explain them how things work, but not necessarily on public websites where users don't want to RTFM and are just looking for familiar behaviours. Unless it was just a sample exercise or a control meant to be included it in a control pack, it violates the YAGNI principle ;)
2 - The implementation
You certainly noticed that the implementation is buggy (at least on IE7 and FF3.1B2). Sometimes, a gesture above all checkboxes will select all of them but one or two. Moving the mouse over the div's above or below the list will stop the drag (I know it's a "feature", but it's not very user friendly). I Checked the source code and to be honnest, while it looks pretty neat, I just didn't want to deal with it because it is plain javascript. Don't you know that...
3 - Possible improvements
...you can write less and do more with a javascript library, typically jQuery. I would completely rewrite this control as a jQuery plugin. It will provide you with a lot of tools to make your code much easier to write, maintain and extend. Just try it, you'll love it. This is from a technical point of view. From a user point of view, try to make you control as familiar as possible, like what Angela suggested, windows explorer : a nice selection rectangle, the ability to use shit + click, or something like that. Finally, remember that for many windows checklistbox users, "selected" and "checked" are two different things.
The demo definitely needs a few enhancements to make it even a little bit useful (although I am not sure if it would be enough):
Allow the dragging to start somewhere that is not a check box.
Allow selection by dragging over the labels as well.
This problem seems similar to the action of selecting multiple files in a file explorer like Windows Explorer. Maybe it can work like the action of selecting multiple files by dragging a rectangle shape around the items to be selected (select one corner, drag to the other corner)? This has the advantage of being similar to an interface element that people may already be familiar with.
For some reason I can't open your link (it says my ip address was blocked). But I think what you're looking for is what I already did in jquery, I uploaded a plugin which I basically ported from crossbrowser.com's dragcheck functionality, it was to be found at http://plugins.jquery.com/project/dragCheck but currently the jquery plugin site is being revamped and my plugin has disappeared. I'm trying to see if they're going to put it back up or if I have to create a new project again...
Anyways until we get that worked out you can see a demo here: http://jsbin.com/ibihi