I am working on a winforms client server application that will load one of many forms that would be used to enter data or retrieve data or search for data. I want to put buttons on the left side of the screen to select which form is loaded on the right, and buttons at the top for the usual New, Open, delete etc.
I began working on this by making an MDI form that would popup a child window that allows to user to pick the application they want to use. Then when they select it, it would load the appropriate form on the right and update the text and functions of the buttons on the left. I was using panels to load the forms into for the button form (which I called the Navigator) and the application form. I had to use events to make changes to the different button forms when the form on the right was changed. A friend of mine said that I was probably going about this in the wrong way. He said there is probably a better design pattern or methodology or controls that already do that for me.
I dont know how to even search for something like this on the web.
Can someone give me some direction on this?
I can do the research if I am pointed in the right direction.
Maybe there is a control that already does all this?
Thank You.
We use a similar pattern. MDI parent with menus for objects and tasks. MDI Child forms (about 30) for each object/task. Left "nav" button in three groups: 1:1 (calling up l related objects), 1:N (display lists of related objects - inspections, equipment, etc.), N:N:X (other complex relationships or tasks). The body has a tab control to group data. At least one tab is a datagridview that is reused for the 1:N lists.
Left nav button sets are dependent on the object being managed. We add the buttons dynamically but in most case they are hard coded - we just don't use the toolbox to place the buttons on the child forms. Each button set is in a Panel - I would probably use a FlowPanel if I were to start over.
We build a "model" form on one of the more complex objects, built all the data binding logic, and then used that form as a basis for the other objects. We didn't use inheritance as supplied by Visual Studio/VB.Net.
We do our own control data "binding." We use ADO.Net and SQL Server. Our child forms only display one record and do not support the typical record navigation seen in the wizard generated forms - this works fine in our case as we navigate sideways through our data. e.g. Application, Authority to Construct, Permit - then inspections, renewals etc. all related to one Facility. (we're a regulator agency)
We use VB.Net as a lot of the business logic was developed in VB6. I'd still use VB.Net today vs C# - much easier to use for business logic and more maintainable IMO.
One issue to consider - some have out the long knives for WinForms (and VB.Net.) I can't see Microsoft depreciating WinForms but there are those advocating that. Many cannot appreciate the simplicity (albeit limited flexibility) of the WinForms that allows us to concentrate on the business being done. I keep looking at WPF but simply cannot see the usefulness of all the UI power it provides. WPF proponents will push MVVM but that is just more complexity that is not needed for small scale development or production (20 users with desktops o a LAN) environments. WPF does not lead itself to our sideways navigation.
I think the left toolbar for selecting the form is a good pattern, but make it collapsible (hide) so the user could use all the desktop space.
As for MDI personally I don't like it because fell a bit outdated and cluttered. But again look for a balance of form and function.
For the top toolbar I would make it part of each form so it would be easy to program the logic. It an unnecesary complication put them on the master form.
As a recomendation you could look, Designing Web Interfaces even it's more focussed to web could give some pointers in user interaction.
For more informacion search ui patterns, user interaction design.
Related
Well ... at the risk of sounding like I really don't know anything about programming, I have a question about controls in Silverlight 5.
I have an OOB App that I am working with, but I need to add the User Menus (File, Edit, etc.) that are normally seen at the top of all apps. There used to be a control in VS (the Menu control) that was easily configurable. What is the control used to create the User Menus in Silverlight 5? The Context Menu is not what I am asking about. That is the right mouse click menu ... so that's not the answer ...
Please, understand my problem. It's been since Silverlight 2 since I worked in Silverlight. I appreciate any information you kind folks would be willing to provide.
There is no such thing available directly from Microsoft (meaning it's neither built-in or present in the Silverlight Toolkit).
You will have to use third-party controls such as DevExpress or Telerik.
EDIT: Some more advice in response to your comment.
Another possibility is to create UIs from scratch. There are two forms of UIs that I found inspiring lately, both of which don't use any ribbons or drop-down menues at all. The first is to use "Windows 8"-like dashboards instead of traditional menues, the other is the Windows Azure Management Portal (a web application).
I don't use traditional UI frameworks for menues myself, but mostly because I don't like those approaches and I'm picky with how user interfaces should work and look like.
But obviously you have to make a serious time investment to go new ways. And it will heavily depend on your application what approach makes sense.
Here's one simple approach that could work in a number of cases, I used it for a database application (I call it the Windows-Phone-7/8 approach):
The screen is divided into the "page" area and information bars. The information bars contain no menues, just who's logged on, a back-button, a home-button, and context-sensitive buttons depending on what's in the view. So basically it behaves like a web browser and you navigate through the app by clicking on "links" (buttons that take you elsewhere).
There's only one page area, so no windows and no popups. I've gone to the extreme of making even dialog windows to be pages.
Now you need menues. You do that with "dashboards", ie. pages that present some overview stuff and buttons that lead to the other areas of your application.
Although you could have action buttons like save or delete on the page itself, I put them in the bottom bar (but they are still dependent on the page your on) - that is exactly how it works in Windows Phone 7/8.
One last advice: The real effort is usually not in the menus anyway. Beside your application logic itself, it's a lot of little things like login screen, error handling and how to present error messages (look at the windows azure management portal for how they did that really nicely) and gracefully failing on session timeout. There's also a lot of nuisance on how you manage your data (ria-services, etc.).
So as long as you don't need fancy data grid grouping, rich-text edit or excel-like pivot controls, a toolkit might not help you as much as you'd hope - because they give you only the controls, not the entire UI.
I am building a rather large WP7 application and having a lot of fun with it. It is Pivot based and has quite a lot of pivot pages. I dynamically add and remove pivot pages based on what "mode" of the application the user has selected to keep the application look and feel as simple as possible. All is going quite well so far my app is fast responsive, not a memory or resource hog and performs background loading on demand when needed.
The Model layer contains all my business logic that represents what the application is all about. It is clean and separate from the the view-model and view layers.
The View-Model layer is an abstraction of the model to the extent that it needs to interact with the view and also contains the session-ness and workflow aspects of the application in general. It contains objects which represent the Model in a way the View needs to interact with. The view model persists the state of the application in isolated storage and supports tomb-stoning.
The View layer contains a lot of elements pivots, user controls, styles, resources etc in both xaml and the corresponding code behind. I do like Blend and the Xaml designer within visual studio 2010 however I find myself still coding/configuring the view objects within the code behind due to the nature in which they interact with each other. The code behind of the view objects is becoming quite large but still only reflects the state of the view and not the state of the application. I have made use of user controls quite a lot as this lets me build reusable components across many pivot pages however the user controls are not Blend friendly. What I am worried about is that my view might becoming more complex than it needs to be and losing the ability to coordinate the user interface design with tools like expression blend.
By customising the view this way and making use of reusable controls I have reduced my Xaml considerably and don't suffer from bloated Xaml files that other developers have mentioned but lost ability to co-ordinate with Blend. Is there are happy medium to be found? Should I be looking at designing custom controls?
[Edit]
Thanks for your reply. I think it boils down to either a lot of Xaml with a designer or break it down into user controls with more code behind. Since I moved into user controls my mindset has moved back to doing things by hand rather than with a designer (better the devil you know right!). My thoughts are should I make my user controls into skin-able custom controls or just keep going how I am and avoid using the designer. Its a bit of potato-potardo but I don't want to get into bad habits.
Custom Controls (or Templated Controls) are not directly related to your question as far as I can see. Custom controls are just controls that add new properties, events and methods to an existing control and are still capable of being 'templated' by a designer.
Creating UI in code does make it harder to design the application using Blend (and even the VS designer) because the only way to see the interface is by running the application.
A lot of the logic that creates the UI could possibly be replaced by using the Visual State Manager. Use states of the controls to design them for specific modes of the view. Only when you need extra/new states you will have to create a Custom Control.
As your question is a bit wide, feel free to add comments or extend your question so I can add more details or remove this answer when it is utter nonsense :)
I'm trying to learn how to design an application which has several different user inferfaces. its an application where a doctor can view patient records, write prescriptions and so on. when designing this one(including the login) I have created seperate user controls for login, prescription writing, medical history browing and set all of their visibility to hidden and then I've put all of them in a single stack panel on the main application window. I'm thinking to display the appropriate usercontrols using the help of code-behind files.
I would like to know is this a valid way of creating wpf applications, or how you would do in desining applications with multiple interfaces (I'm plaining to use some animations on them, such as fade in and hide when closed a user control ).
Thank you.
For a simple project this is perfectly fine.
However as the number of views grow, you might want to design a system for managing this stackpanel.
There is a library designed to handle these kind of situations, you can find it here: http://compositewpf.codeplex.com/ look at the stuff called RegionManager
I'm writing an application that is supposed to show and hide the content of the main window stack panel based on the user choice. For example, the user clicks on the button that displays the list of the customers, then click on the button that displays the ordering form. The customers content should be hidden and the ordering form should be visible. Moreover, if there are contents with related information (like customers and their data) I want to be able to change the data in one window and it should automatically refresh the data in the other window when the user decides to open it. Is there a good way to do it in MVVM?
Thanks for any suggestions.
Because this question is so generic, the answer must be as well, and the answer is that this is exactly what MVVM is for - modeling data and binding it as needed. In fact, I would argue that a majority of MVVM examples you find online will be some flavor of an answer to your question, most likely using good ol' Northwind.
It sounds like you need to really take a good look at how you want to do your design before you jump in and start coding.
You might want to check out Prism (or as it is really named Composite Application Guidance). You can build really complex and modular designs with it.
You might be interested in the MVVM sample applications of the WPF Application Framework (WAF).
Writer: Shows how the Views (UserControls) can be switched (Edit mode; Print Preview mode).
BookLibrary: Shows how data modified in one View is automatically updated in other Views.
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.