I'm currently developing an application in C# that will have two layouts: simple and advanced.
The simple layout would have 4 objects (2 buttons and 2 text controls) and the advanced layout would have 8 objects.
What would be the best way to do this? Having two forms? Or set the button.visible to true/false (and for each object?).
If you follow a UI pattern that allows for separation of model, view and controller (e.g. MVVM or MVC), you will find it is very straightforward to have two separate forms that can be evolved over time as needed, with only minimal changes to the rest of your code.
Trying to make a single form work for two different presentations tends to get complex over time (compared to the alternative of just making two forms that share the same model and controller) as user requirements evolve.
UPDATE
Based on your comment... you can also do MVC with WinForms
http://www.codeproject.com/Articles/383153/The-Model-View-Controller-MVC-Pattern-with-Csharp
I would propose a third option, having two user controls that share the same form. Then all you have to do is set the appropriate user control visible. And you get the benefit of being able to share any code between the two.
Related
ı have been serching this for a while but I couldn't come up with a conclusion. What is UserControl? For me we can do everything with creating new windows forms instead of User Control. I know there is a reason to use but it is not clear right now. If someone illuminates the mystery that would be great.
A user control is basically a grouping of other existing control, intended as a reusable component (i.e. composite control). If you need to place the same group of controls on different windows you'd rather group them in a user control, adding things like data validation for instance, and then reuse this control whenever you need it.
Here is some more reading.
UserControls allow you to reuse your code. For example if you need a small component that displays two values (code and description), with UserControls you can design it only one time and then reuse it in other forms.
Also, you can add your custom properties\methods to the UserControl; in this way you can define simple (or even more complex) functions associated to the GUI control.
Hope this helps.
imagine you have a GridView with some new methods you create, and which you want to use on several pages. There you go. A UserControl is useful. That's just one example
As the others have explained a UserControl groups 'real' Controls and the logic that makes them work together as one component.
Imagine an application where the user can decide wether it runs in MDI mode or with separate windows or with tabbed pages. You can add the UCs of your application to any of these easily.
Think of a MP3 player with various controls, buttons, labels and sliders and user drawn-gauges. If it's in a UC you can re-use it directly. If it is all on a window, how do you re-use it?
So UCs are about flexibilty and re-using visual components.
I am crating a program (in c#, using visual studios 2010) that will have 3 different windows. each of them needs to be accessible from one another (by the toolstrip/menustrip) and they refer to the same information (Same variables, databases ect...
My question, is what is the best way to crate and design these different interfaces?
I can think of two ways, but both of them have some disadvanteges.
The first way I thought of is to make a "Hide/show" void that will hide turn the visible of all of the components in the first Area to false, and will Turn all the wanted components Visible to true.
the problem, is that it's stupid and messy.
the second way I thought of - is using a second form.
Disadvanteges - all the variable transfer is quite a mess, and mainly - I don't want different forms to pop up. I want it all under one program.
I guess there is an efficient and smarter way to do this.
I hope I was clear enough in this matter.
Thank you,
Barak.
You can create a master form (like master page in asp.net) and inherit all three forms from this master form.
I'm working on a windows 8 metro-style app, using developer preview for an academic project at university. We have to use MVVM pattern.
In the main Page we have a metro-style main menu with buttons. Each button leads to an application facility (ie. 'Show my Library', 'Show Favourites', ...) which should belong to a different View, according to MVVM pattern.
In your opinion should we create a new 'metro-style Page' for each View or expect a 'Scenario' for each use case refreshing the main Page, like those present in many example apps?
In other terms, using MVVM should there be a 1:1 match between 'plain old WPF Windows' and 'brand new metro-style Pages'?
The thing with MVVM is that there are no hard rules as to what constitutes a View other than the fact that it is the means by which the user can view the ViewModel data.
A View need not be a Page, but can be a Control. Thus you can have one page, on which many View controls are displayed, if you wish. Quite often I have my Views as controls, even if they are to be the sole item displayed on a page, as it allows me to embed them in other pages more easily at a later date.
The MVVM pattern is purely a means of separating the UI from the business/code logic. A ViewModel class doesn't care how it's data is displayed, it just provides the binding points, properties etc., for the data to be displayed and trigger points for code function.
Some people will insist that there is never any code in the code behind files, but I think that a more pragmatic approach is required. Code that controls visual aspects of the View is fine, and there are occaisions when what appears to be business logic intrudes.
For example when implementing drag and drop functionality code will be required in the code behind. This is really just a visual aspect so no problem there, but if the business model dictates that only certain items, or a maximum number of items are dropped in a given location then the ViewModel will need to provide some data binding points that the View can use to implement this. By doing so you could argue that the View code behind now implements some business logic.
So back to your original question. I would try to implement the application such that it behaves as is expected for a windows 8 metro-stryle application. This will obviously have a bearing on how you code, but it should still be possible to stick to the MVVM pattern when doing so.
I've been designing a pretty complicated avionics application. The thing is, it has many menu buttons to be clicked (12 to be exact) and each one of them perform a different action. For instance, one could be a login panel and the other one a PDF reader. How could I organize this programmatically?
Currently, I've been setting each item in a panel and setting it to visible or invisible, according to the active or clicked item.
How would you guys do this?
Thanks in advance!
You might consider a FlowLayoutPanel, although I'm not sure how flexible it would be in meeting your requirements. If you set your panels up with docking properties, you should be able to manage.
I would also recommend using a UserControl to separate code and functionality. If panels need to communicate, implement the observer/observable pattern instead of subscribing to events between user controls.
Like IAbstract says, you should consider separating the different UI elements as UserControls. You can then do things like use a factory to construct them and add them to your window as required.
I've found this sort of approach, used with a Model-View-Presenter type pattern, works really well for WinForms apps with dynamic user interfaces.
I'm working on moving a client/server application created with C# and WinForms into the SOA/WPF/Silverlight world. One of the big hurdles is the design of the UI. My current UI is MDI driven and users rely heavily on child windows, having many open at the same time and toggling back and forth between them.
What might be the best way to recreate the UI functionality in an MDI-less environment? (I've no desire to create MDI functionality on my own in WPF). Tabs? A list panel that toggles different controls?
Look at 37signals and how nice their web UIs are (mostly HTML + AJAX). It's a good example of web applications that work. One of the things to remember are to make sure you don't break the web paradigm. If users want to see two things side by side, they should be able to duplicate the window and let the web browser do the windowing.
For WPF, there are a lot of new visualization paradigms. You can find some examples on the sites for various control toolkit providers: Xceed, Telerik, Infragistics. They have demo programs for the different ways they help you organize screens in an application.
When developing complex composite applications in WPF, you could also start at the Patterns and Practices Prism site. It's an InProgress set of practices for planning and developing complex composite (smart client style) applications in WPF.
I think the answer is really going to be up to your users -- I'd set up some prototypes with multiple paradigms and let them provide some input. The last thing you want to do is introduce a new UI paradigm without having any end-user input.
Tabs are really popular now, but don't allow side-by-side viewing, so if that is a requirement you may want to go with more of an outlook-style setup, with multiple panels that can be activated, hidden and resized.
One thing that you might want to do is to code your app as a composite UI, where each view is built independently from its container (be it a child window, tab or accordion, etc.), and is just "dropped in" in the designer. That will protect you from when the users change their minds about the navigation paradigm in the future.
multiple top level windows are easy to implement and have all the advantages of MDI - that's what MS selected for the newer versions of Office
Did you try GOA WinForms?