I have WPF Application where I have One main form and other user controls are shown in the main form as child form. I have to show Busy bar when I make Async call to data base. What is the best way to declare Busy bar object and then used in every child user control. Should I need to declare busy bar object in the main Form and then Used it the child user control or The App file is best, or is there any good way.
It depends on whether your "busy bar" is a control that appears inside other controls or windows, or a popup window in its own right.
If it's a control, you cannot (easily) use a single control instance in multiple places in the application. A WPF control instance is part of a visual and logical tree. It cannot be part of two visual trees. You can create a BusyBar control class, and declare multiple instances of that in the various places you need it: to do this, use the User Control (WPF) or Custom Control (WPF) template in Visual Studio.
If it's a window, you can create it during application startup but leave it hidden. Then you can show it from code when required (using the Show or ShowDialog method). That said, it's not clear why you'd need this to be a singleton anyway. Creating windows is cheap, especially compared to calls across a network to a database. Again, declaring a class, and creating and showing instances of the class when required, would be the more usual approach. You could easily create a static method to encapsulate the "create-bind-show-wait-hide" cycle so as not to pollute your app code with the details.
Related
I'm writing a fairly large WPF application that is following the MVVM structure. I would like to run my UI in basically 2 modes. The first being the normal day-to-day operational mode. The second is one that I've been wondering about for a while now...I would like to be able to run it in a "configure" mode where the user will see the UI in more or less the same fashion as the normal mode, except that a popup window would appear when they hover over (or maybe click) a control. This popup would allow the user to change certain bindings related to that control. I don't want to expose every property (or every control).
For example:
There is a TextBlock that has a binding to a pressure signal, now that user wants to change this binding to a temperature signal. They could start the UI in config mode, navigate to the screen with the TextBlock, select it, and see the Text property in a popup which they can then change to the new temp signal. This is a simplified exampe, but basically what I'm looking to do.
Is this possible? Remember the UI would have to write to the the View (XAML). Any help is appreciated.
P.S.
This would be a very useful but rarely used feature. It would be ok to maybe have 2 projects which ustalize the same View but different ViewModels and Models...at least that's what I've been thinking might be needed. Even if the normal mode UI would have to be recompiled after using the configure mode UI.
Every popup window should have its own VM (or they could share if it turns out to be an overkill due to small number of properties per popup) and communicate with the main VM via the message bus.
Store your bindings as User Settings and when the message arrives from the popup window VM, carrying the new binding as a payload, main VM would get that payload and save the appropriate user setting by simply calling Settings.Default.Save();
Based on your description, no reason to make it more complicated than that IMO...
I'm trying to build an app in winforms with something similiar to masterpages in asp.net - a menu on top and when choosing an option from the menu the entire screen on the bottom will change while the menu remains (there are 10-15 screens in the future app, some are quite similar, some are not).
What is the best way of doing this? Should I use different forms for each screen or use a panel or something else?
If I use a panel or something how do I manage to use the designer with so many panels taking space on the screen?
Try with the MDIParent Form's. View the Example
http://www.codeproject.com/Articles/12514/Multi-Document-Interface-MDI-tab-page-browsing-wit
If it is just keeping the same menu and opening/closing parts of the UI you could simply add and remove instances of usercontrols to the main form.
If you need more features such as docking (like Visual Studio) look at this
Another option is to use Form inheritance
Which one to select depends on what you want to reuse and the features you need.
One option would be to make your application an MDI window and then load entire forms, maximized, into the parent window.
Then, you would be able to treat each form as its own self-contained item, since it really would be exactly that.
Is it not an option for you to use WPF? A WPF browser application fits the paradigm you are describing quite well.
I'm writing a Windows application in WPF. I based my UI in a single menu and a tab control to display different documents or application forms. Since the menu as well as other things are fixed throughout the application, I need a way to display the contents of each TabItem. I have found two:
write a user control for each form, or
using a frame to display the content of each form.
The question
Is there any other single way for doing this. How do they compare in terms of clean code? I mean, in .net forms I only need load the form from the menu.
I know, I should go for any pattern like MVVM, but for this very first time I want to use the default approach.
I go with Frames and host Pages (not user controls). I like Pages over User Controls as the event model seems to have more hooks.
Is there a difference between window and user control? It seems to me that these two are exactly the same. So which one should I use and when?
(I tried googling this phrase and I couldn't find anything)
A Window is as the name suggests a window, it can be closed, minimized, resized etc. This should be quite intuitive.
A UserControl on the other hand is a composite component/module which can be placed inside other controls and is itself made up of controls (possibly even other UserControls), the main use for UserControls is reusability, encapsulation and loose coupling, some applications can be broken up into a set of UserControls of which each one provides a certain functionality.[citation needed]
We make user control if we want to reuse it. As name says User Control it means some control like grid,combo box like that.If i need same grid on 3-4 windows then i will prefer to make it as User Control.If it is not reusable i will define my grid in the required window.At last you paste your user control on some window.
Conclusion :- If you want to reuse the control then make it as a user control otherwise define it in required window.
A window is managed by the OS and is placed on the desktop.
A UserControl is managed by wpf and is placed in a Window or in another UserControl.
Applcations could be created by have a single Window and displaying lots of UserControls in that Window.
wpf window is a Win32 window, but user control is just something of wpf, not a Win32 window.
I presume you refer to the windows forms. Usually they are classified as user controls and custom controls - same stands for web forms as well. For more information you can refer to these links control vs user control in winforms and over view of user controls and custom contorls.
I am working on a little WinForm app and have been trying to find the answers to a few questions i have without any luck. Im a ASP.NET developer so WinForms development is new to me.
Here is my main question:
How do I create a menu system that once selected the contents will render in the Main form of the selected item. If its a GridView I want to the GridView to render inside the main application so they can navigate away without having to deal with the modal popup. I do not want to popup forms unless i explicitly say so. I guess the equivalent to this would be using a Master page in ASP.NET.
Make sense?
The closest thing to Master pages in winforms would be MDI (multiple document interface), which is a hideous Windows 3.1-era abortion of a user interface. Why this option is even still around, and why anyone still uses it, is beyond me.
The second closest thing (and something more acceptable as a UI) is just to have one main form in your application, and implement the different pieces of functionality your app requires as separate user controls which are displayed on the form and hidden as the context requires.
A weirder method, but one that might also work for you, is to use forms inheritance - design one "master" form with the menus and controls that you want to always be present, and then have each form in your app inherit from that master form. This would not appear to the user to be much different from my second option above, so I wouldn't bother with it.
There really isn't anything similar to Master pages in WinForms.
The closest to what you want to use would be a TabControl selecting a different tab will display that tab over the other tabs. If you don't like the tab look you could extend the TabControl to not show the tabs or hack it together by placing the TabControl inside a panel just large enough to show the content but not the Tabs and change tabs programatically in your menu control.