Is it bad practice to instantiate a Form from a UserControl? - c#

I am building an application using the .NET CF Framework and I had a situation where I wanted to present the user with a custom Dialog Box.
My solution was to create a simple Form with radio buttons for choices and a button. When clicked the button saves the selected radio button value to a public property and closes the Form.
The UserControl, after calling ShowDialog on the Form, inspects the public property to learn what option the user picked.
This worked perfectly. I'm just wondering if this is bad practice and if i'm going to get myself in trouble, somehow by doing this. It seems odd that a UserControl should be creating a Form.
Is there a better way to go about creating a custom Dialog Box from within a UserControl?

Absolutely nothing wrong with that. It is essentially the same as calling MessageBox.Show() from a UserControl.
And yes, accessing the result as a public property is the way to do it.
I'm guessing that this will be a dialog? You should consider using the DialogResult if you have multiple 'exit' options - OK, Cancel, etc.

Short answer: No, it shouldn't give you any problems.
Long answer: As your application grows, doing things like opening a Form directly from a UserControl might give you some spaghetti-like code. If you write an application larger than a few thousands lines of code, your Form and UserControl code behind files should typically be quite empty. They should not contain any business logic, and preferably not any UI logic either. Look at patterns such as Passive View how to achieve this.

Related

How to programmatically add buttons to a window after Instantiation à la Revit API's TaskDialog class

I apologize if the question isn't as accurate to what I want, but I'm fairly new to coding any type of window/form without a visual element or robust IDE (currently don't have access to Visual Studio, but want to begin work on a GUI while I wait as I have a bulk of the driving code done). I've had a difficult time finding out if/how this is possible due to the wording of my queries so far being too similar to other topics, like enabling/disabling buttons.
What I want is to emulate the programmatic functionality of adding buttons to a window present in the Revit API TaskDialog class. For those unfamiliar, this is a sample of how one creates a TaskDialog with a basic message and two buttons in C#:
TaskDialog dialog = new TaskDialog("Sample");
dialog.MainContent = "This is an example of how a TaskDialog is coded in the Revit API";
dialog.CommonButtons = TaskDialogCommonButtons.OK | TaskDialogCommonButtons.Close;
dialog.DefaultButton = TaskDialogResult.Close; // optional, will default to first button in box if unassigned
TaskDialogResult response = test.Show();
This type of framework would then be used on a window/form/user control that's used by multiple different modules, each with slightly different UI needs. Most modules will need a list box and Confirm/OK and Cancel buttons as a basis, but some will need additional buttons for additional functionality within the window.
If this functionality is better done in WinForms, I'm open to moving my GUI to that platform, I have interacted with both in the past and am somewhat familiar with the flow of each, just not the more advanced topics yet. This said, the data binding is an important feature for me, so wpf is preferred.
Any input would be greatly appreciated!
Edit
So, after some more digging around, I think I have a better understanding of how to ask my question:
What I want is the ability to programmatically add buttons (not RadioButtons like in this solution) to a window (wpf or winforms) by setting a variable in using the constructed window instance in the main code, passing it values from an enum with [Flags]. I want to have defined, common buttons (e.g. OK, Cancel, Close, etc) whose information and enum for adding to my window are in a module. I can then access these buttons through their enum, as Revit API allows with the TaskDialogCommonButtons enum, and assign them to a property of the window (in my example that would be the TaskDialog.CommonButtons property). This would then tell the window to show these buttons and none of the other buttons contained within the enum.
Unfortunately, the only results I get are how to data bind RadioButtons (not regular Buttons) that are then explicitly created within, or hard coded into, the xaml or codebehind of a window class and not dynamically added after the custom window class has been instantiated from the main code. This is clearly possible, otherwise the Revit API would not work in the way it does, but I can't seem to find anything relating to how or why it works and how to duplicate it.
Is simply a matter of including all of these buttons as hidden in the window class and using the enum to set the window instance's button visibility to show/true, thereby granting UI access? Or is it actually possible to add buttons programmatically from the driving code (not the codebehind of the window) using an enum?

More views of a form in c#

Let's say I have two "views". Each view has it's own button, which makes other view to appear. All should be managed in one window. So how do I achieve this? Im looking for something like viewController in iOS...
I tried to use one filled, docked panel - but than all classes are active, so it doesn't seem like a good solution. I also tried user classes (like this), it works, but it's complicated and I have big deal sending data between these classes.
There is no such thing as "views" of a form. The concept of what a UIViewController can do in iOS is different than building a properly functioning form in C#. You need to learn some new skills now and approach this from a different perspective.
The basic principle is to build a form with controls (either manually or through code or both), change the properties of those controls manually or through code and use the methods they support. You can do what you want, but it's going to take learning some new things.
Try checking this out:
https://msdn.microsoft.com/en-us/library/360kwx3z(v=vs.90).aspx
It's not 100% clear what you are trying to do, but it sounds like you should look into User Controls or Composite Controls.

Bubbling Events from UserControl using MVVM in WPF..?

First of all, I want to let everyone know that I'm very new to the MVVM concept, and have looked pretty extensively for some explanation of what I want to do, but to no avail.
In the program I'm working on, I have a UserControl with a few buttons on it, which need to control the navigation of the main window. I have 3 different "pages" I want to be able to switch between in my main window. Instead of pages, I decided (for whatever reason, correct me if this is not the best approach) to use a UserControl for each page, and switch the visibility to the correct one. I need the data to persist while switching, so I don't believe that creating new instances of the Usercontrols will work.
My question is: How can I bubble the events from my "NavBarView" to the main window in a way that will allow me to switch the visibility, but in a MVVM way? I know I may be completely going about this the wrong way, and I'm happy to take any suggestions on a better way of achieving this navigation.
I have to use WPF, so WinForms is not an option. Too much transparency and custom controls for WinForms.
I would make the "NavBar" part of the main window if possible and use that to control the sub controls in the forms. I would be careful nesting User Controls. If you can avoid it I would (key indication is are you going to reuse it somewhere else). I took over a project a while back that had a main window with 3 separate highly coupled user controls that had to all work together and it was a nightmare. The only way I could get it to work somewhat safely was to have them all set their data context to the same view model. If I had to do it from scratch - would have taken a completely different approach with a single view.

WPF application in a one window

I would like to make an application in a one window using XAML.
It should be like a slideshow with next and back button. One idea is to make 4 panels and have just one enable at the time. Is there any other way to do this? Like dynamic loading of other XAML?
is it the BackgroundWorker mandatory to use with WPF (hence is DirectX rendered there's almost no GUI lags) ?
You can do it with Pages that you can show in a window. Just create a window for every page and change the root tag to Page.
It should be used if you want to perform a long running, non-UI related task, to prevent locking the UI.
I think this could be achieved fairly easily with a VirtualizingStackPanel.
1.You can use ItemTemplate and load any one you wish on your click event.
2.BackgroundWorker is always a better choice to use.
I found out other soulution: Tab Control
IMO better - more flexible

Developing wizard UI - WPF

All in WPF:
Developing a wizard application, user has to answer a number of simple questions before brought to the main app. The main app is then prefilled with the information obtained from the wizard.
I started with a Window which I then planned to add usercontrols to. The main window would have the user control in the first row, then Next and Previous buttons to control moving between the controls in the second row. This way I could easily control the logic to switch between screens like:
WizardControl1.IsVisible = false;
WizardControl2.IsVisible = true;
But for some reason, user controls do not have setter for IsVisible. Hurray.
So then I thought I would just use seperate windows for each section of the wizard. The problem with this approach is that now when stepping between, the window opens in random positions, and by steppign through the wizard with next, the next window pops up randomly which is really distracting and frustrating.
So how can I develop a wizard properly? I don't get why this is so hard...not exactly rocket science... replacing text and controls and storing input after pressing next/previous!
Thanks
Check this link:
http://www.codeproject.com/KB/WPF/InternationalizedWizard.aspx
This is the article about building wizard in WPF by Josh Smith, it's seems to be nice pattern.
I found it's helpful for me, hope you'll too.
There is also an open source Avalon Wizard control on codeplex.
I'd probably aproach this using data binding and template selectors. Have the wizard form bind to a "WizardData" class, which exposes a list of "WizardPage" base classes.
The WizardData class can expose properties defining the correct info on the forms, and display a control for the main page that uses a template selector to determine the proper control to display based on the actual type of the particular wizard page.
It sounds like more work than it is, really. It also gives you the benefit of good separation between code and UI (all "work" is done by the WizardData and WizardPage classes), and the ability to test logic independent of the UI.
It's also a very WPF/MVVM way of approaching the problem.
I recognize this does not directly address your question, but I thought I'd mention it as a possible alternative. I've used Actipro's Wizard control with pretty good results, and when I have needed support, they have been very responsive. I am not affiliated with them in any way; I just like not having to write the plumbing to manage a wizard.
The property is called "Visibility".
I find that I do better when I dynamically add and removing controls rather than hide them.
I was looking for a Wizard solution too. I have the need to stick with stock WPF components so I implemented the wizard using a standard form and a tab control.
I only hide the tabs at runtime so there available in the IDE. At runtime just use Back, Next, Finish... to navigate thru the tab items
works good

Categories