I have a bunch of Forms that I embed in tabpages(some are embedded two and three layers deep) that I now suspect are giving me trouble. I have been told that User Control's are the better approach.
Now I am wondering how I
canaccomplish this as quick as
possible.
Is it as simple as copy and paste?
Has anyone ever done something like
this?
I have about 40 forms that I embedd that would need to be moved and not a lot of time to do it so any help is greatly appreciated.
EDIT 1
This is how I embed forms:
public static void ShowFormInContainerControl(Control ctl, Form frm)
{
frm.TopLevel = false;
frm.FormBorderStyle = FormBorderStyle.None;
frm.Dock = DockStyle.Fill;
frm.Visible = true;
ctl.Controls.Add(frm);
}
public static void DockControl(this Control control, UserControl userControl)
{
userControl.Dock = DockStyle.Fill;
control.Controls.Clear();
control.Controls.Add(userControl);
}
Not sure if it's the "best", but this is probably the most efficient. Change the classes to inherit from UserControl instead of Form. Then fix the compiler errors if/when you get any (see NOTE 2 below).
NOTE 1: If you're not using version control, start using it before doing something drastic like this. You'll want to be able to go back if something goes too far south.
NOTE 2: If you use any particular events or properties of Form that aren't implemented in UserControl, you'll have to think of a solution. Some properties (Icon for example) you can safely just ignore (= delete the line from the designer file).
NOTE 3: If you use the forms as an actual form somewhere, you'll want to also have a form that uses the newly created UserControl. You're most likely to get in trouble here with naming, so keep a sharp eye.
Related
My question is what is the ideal way to initialize child window in WPF, MVVM way?
I have a WPF window , let's call it as ParentWindow having its view Model class - ParentWindowViewModel. On click of a button on the ParentWindow UI , I launch a new WPF window - ChildWindow like below
ChildWindow r = new ChildWindow ();
r.ShowDialog();
r.WindowStartupLocation = WindowStartupLocation.CenterScreen;
Now, the ChildWindow has its own viewModel like - ChildWindowViewModel. The Child Window has the datacontext set in its xaml as
<Window.DataContext>
<viewModel:ChildWindowViewModel/>
</Window.DataContext>
On Click of button in the ParentWindow, When i Launch the Child Window, I need to pass certain values to the Child Window, which will be used to initialize the Child Window. Without these values the child window cannot be initialized.Every time I click the button to Launch the child window, the values being passed to child window will differ based on some other selected items in the Parent Window.
I would do something like this (without error checking):
in ParentWindow.xaml.cs
private void Some_Event_In_Parent_Window()
{
ParentWindowViewModel pvm = DataContext as ParentWindowViewModel;
ChildWindow cw = new ChildWindow(pvm.Element1, pvm.Element2);
}
int ChildWindow.xaml.cs
public ChildWindow(bool elem1, string elem2)
{
InitializeComponents();
DataContext = new ChildWindowViewModel(elem1, elem2);
}
If you are dealing with minimal elements that need to be transferred between windows/VM's, and it is mainly about sending some form of "state" or "value", then there isnt too much issue with initializing the Viewmodel in the code behind. Remember that the <viewmodel:ChildWindowViewModel/> is equivalent to DataContext = new ChildWindowViewModel() in your code behind. While yes, you can create spaghetti code, or confusing dependencies by not adhering to patterns; you can also over engineer the crap of something that did not require the effort and can be just as confusing.
I find that there is an obsession with keeping your code behind empty (i have the same obsession). Remember, that the Code behind is there for a reason, and you CAN use it. Sometimes it isnt worth over-complicating your code base by implementing some big pattern if you have a single one off requirement that can be handled in code behind with some added comments.
Aside from Event Handlers, I utilize the Code Behind for these main use cases:
There is an adjustment needed to the UI that is too complicated to handle in the XAML alone. Example: I need a weird string concatenation and logic of some inputted text fields.
There is some minimal state or data needed to be transferred between Views. (Like your requirement)
There is some sort of logic that needs to happen that is UI specific and not related to the underlying data or ViewModel. (This is rare, and almost always a small one off).
In terms of "is this ideal" for MVVM; it depends on your definition of ideal.
Can this be handled by some other design pattern? Probably...? But is it worth it.
Does implementing said pattern add bloat or overhead that only solves a small problem? Maybe. That is for you to decide.
Are you going to be repeating this implementation more than once? If so you may have some bad design to rethink.
Does implementing this solution of using Code behind solve your issue in a speedy way, that is moderately maintainable and readable? If so, then I wouldnt see a problem.
Ideal is not always defined by rules. It is also specific to your needs and requirements.
It isnt always easy to determine where your use case should be handled. View, ViewModel, maybe a Service, or a Singleton state class.
If your use case is this one window, Code behind is fine (In my opinion). If you are doing this for 20 windows, you may want a Service to maintain the state somehow. Think of it more - if your code is SOLID and DRY
I'm a fresher with WPF, MVVM. Now, I have been investigating MVVM Light. I got some confused. I appreciate any help from all of you. Thanks in advance for taking a look at this post.
Can we absolutely remove code behind of View (such as: Invoking InitializeComponent() somewhere inside .xaml --> Does not need view.xaml.cs anymore in some simple case).
I have many views insight my project, how many locator is necessary?
I intend to make separate locator for each view. And I wonder that if I register all locators in app.xml, are all of views initialized and registered right after user run the application? If Yes, Is it not good for performance?
Main question:
I have a scenario:
I have many forms: such as :
MainForm: which is the 1st form invoked by application.
ImportForm: which is invoked when User click Import (from MainForm)
Assumption that: I did finish all stuff related to binding (such as button Import --> RelayCommand(OnImport))
What is the best practice for me to implement this scenario?
1. Just implement to init and show ImportForm like below:
public void OnImport()
{
ImportForm importForm = new ImportForm();
importForm.ShowDialog();
}
It's simple, but I wonder if this way follow the MVVM's paradigm?
So, I did some researching and do another way like:
public void OnImport()
{
//// Just send message
Messenger.Default.Send(
new NotificationMessage(this, "OnImport"));
}
In Code Behind: MainForm.xaml.cs
public MainForm()
{
InitializeComponent();
Messenger.Default.Register<NotificationMessage>(this, (nm) =>
{
if (nm.Sender == this.DataContext)
{
if (nm.Notification == "OnImport")
{
ImportForm importForm = new ImportForm();
importForm.ShowDialog();
}
}
});
}
By this way, I must write some code inside code behind --> Is it a problem?
Both above solutions can finish mentioned scenario correctly, but I confused which one is better or is there any actually right solution out there?
Thanks again for your patience with the long question.
No, you cannot. InitializeComponent() paints UI on the screen. The purpose of MVVM is to separate logic that does not related to View and store it in a ViewModel. It does not tend or aim to remove code-behind.
It depends on you. You can create one Locator for all ViewModels or one Locator per one ViewModel. Anyway, I found that Locator does not scale well and hard to manage in a larger project. It creates dependency between View, Locators and ViewModels. I personal prefer to use DI framework instead of Locator even if it is a small project.
You can do both, depends on your requirement. (a) If clicking the button on the main form does nothing more than show a dialog then I would use Click event because it is View related. It has nothing to do with any logic, so keep it in the code behind is the best solution for me. (b) By the way, if clicking the button does something, for example, connect to a database then show a dialog if a condition is true. In this case, I would use Messenger to keep View and ViewModel separate from each other.
I have a very strange issue that I'm finding it extremely hard to debug, thus I once more turn to the SO community. :-)
First a bit on my setup (note! I'm new to silverlight, just learning by doing, so my entire premise might be wrong!):
I have some root nodes (forms) under which are some leaves (questions).
Now, I simply want to show / hide the questions depending on which form is currently selected - fairly easy.
I do the following:
A number of controls are added to a LayoutControl (I'm using the DeveloperExpress components)
When you select another form, the created controls are saved in a list on the previously selected form
When you select a form, the list of controls is iterated through, and each element is added to my layoutcontrol again
When I save the elements in the list on a Form I make sure to first .Remove() them from their parent to make sure there are no issues with that.
And, this works.
If I have 1 or controls.
If I have MORE than that, everything is added as usual, no exception is thrown - but Silverlight apparently does an infinite loop somehow? No matter if I run it in IE or Chrome, it just crashes the browser! (Or, I guess, the browser plugin).
I've tried pausing the debugger during this to see where the problem is, but it just stops in "external code".
I don't think a code sample will do much good, but here's the two methods that save and load the elements: (Note: AddControl is a method I've defined - it wraps the element in another control to provide a bit of functionality. Likewise .MyChildren removes the control from the wrapper using .Remove() and returns it)
private void LoadElementsFromCurrentForm()
{
foreach (var child in _currentForm.Elements)
{
layoutControl1.AddControl(child);
}
}
private void SetElementsOnCurrentForm()
{
_currentForm.Elements.Clear();
foreach (var child in layoutControl1.MyChildren)
{
_currentForm.Elements.Add(child);
}
}
How do I even go about debugging this!?
I don't know if it matters, but all these controls have a unique name as well.
Regards
Søren
To take full advantage of Silverlight you should try to use XAML to do the markup of design.
If you want to make a list of questions use e Listbox or ItemsControl.
Then you can style each item in the list to "look right".
If you bind the listbox to ObservableCollection you just add or remove in the list and the gui will be updated according to whats in your list.
Take a look at MVVM which works really good with Silverlight.
How can I hide one panel in Visual Studio 2008 Form Designer like a layer in PS? Otherwise, can someone recommend another better method to design multiple "screens" that must be clicked through by the user?
What you describe is a wizard, and you might want to investigate the approach from Eric J.
However, when I have cases where I want to have multiple panels in the same space within my UI and I want to switch between them in the designer, I like to use a TabControl and hide the tabs on the TabControl. This makes the UI easier to manage at design time and the code is pretty simple to switch between the tabs at run time.
I made a custom control that derives from TabControl called HiddenTabsControl that is very simple. The class only overrides the WndProc and lets the TabControl base class handle everything else. All you need to do is:
Add a New Item to your project
Choose Custom Control,
Name it something like HiddenTabsControl.
Change the base Class to TabControl, remove the Constructor and the OnPaint override that Visual Studio added.
Copy this override for WndProc into the class:
protected override void WndProc(ref Message m)
{
// Hide tabs by trapping the TCM_ADJUSTRECT message
if (m.Msg == 0x1328 && !DesignMode)
{
m.Result = (IntPtr)1;
}
else
{
base.WndProc(ref m);
}
}
Now you can change tabs in the designer and design the UI easily and in the code you can handle events to change tabs as needed. Changing the Selected tab is easily done with:
this.hiddenTabsControl.SelectedTab = this.tabPageYouWantVisible;
One side effect of removing the tabs is the space that the tabs occupy when the control is constructed. Removing them will make the space the HiddenTabsControl occupies change by shrinking it. I usually set the Anchor of the HiddenTabsControl to bottom to keep it from shrinking.
I used this Wizard code in a recent project and it worked well.
It provides the basic experience you are after.
Another less elegant, but quick hack, approach is to simply not add the panel to the parent form until runtime. In doing that, the designer has no idea where the panel belongs prior to compilation, and it won't be displayed.
For example, find the block of code where you add controls to the parent form:
//this->Controls->Add(this->panel_X);
this->Controls->Add(this->tabControl);
this->Controls->Add(this->menuStrip_topMenu);
Comment or remove the statement, then find the handle to the event that occurs when the form is loaded:
this->Load += gcnew System::EventHandler(this, &MainForm::MainForm_Load);
Then in the definition of the event handler, add the control to the form:
System::Void MainForm_Load(System::Object^ sender, System::EventArgs^ e) {
...
...
this->Controls->Add(this->panel_X);
}
I haven't experienced any unwanted side effects by doing this, but if anyone has a good reason to not I'd be interested in hearing it.
Seriously, it seems like every time I want to make my UI elements talk to each other, I end up coding a new, custom, IValueConverter :(. Someone tell me that I'm doing it wrong, please!
Examples:
I wanted a button to be enabled only if my textbox contained a valid URI. Great, time to code up a UriIsValidConverter!
Oh oops, I also wanted to disable it while I'm processing something. I guess now I need to code up a UriIsValidAndBoolIsFalseMultiConverter!
I want to display a list of files in a certain directory (specified by a textbox) inside a listbox. I guess I need a DirectoryPathToFileList converter!
Oh hey, I want icons for each of those files in the listview. Time for a FileInfoToBitmap converter!
I want my status to be red if my status-string contains "Error", and green otherwise. Yay, I get to code up a StatusStringToSolidColorBrushConverter!
I'm really thinking this isn't that much better than the old Windows Forms method of just wiring up everything manually using TextChanged events (or whatever). Which I guess is still an option. Is that what people actually do, perhaps, and I'm trying too hard to make everything fit into the databinding paradigm?
So yeah, please tell me if this is really how WPF coding is---or if I'm doing it wrong, and if so, what I should be doing.
Your approach is perfectly valid (though I would use a multibinding for the second example, rather than a such a specialised converter), though by placing all your logic into the XAML you are producing very high coupling between the way the application looks and the way that it behaves, because of this you may want to look into the MVVM pattern to separate those things out.
Under the MVVM pattern your XAML (the view) just contains very simple data bindings into a ViewModel which handles all the logic and updates the view through the INotifyPropertyChanged interface. The code for your third example may look something like:
public class DirectoryManagerViewModel : INotifyPropertyChanged
{
private string _directory;
public string Directory
{
get { reutrn _directory; }
set
{
if (_directory != value)
{
_directory = value;
OnPropertyChanged("Directory");
if (IsValidDirectory(value))
{
PopulateFiles();
}
}
}
}
public ObservableCollection<FileViewModel> Files { get; private set; }
private bool IsValidDirectory(string directory)
{
//return if the directory exists etc.
}
private bool PopulateFiles()
{
//Populate Files with files in directory
}
}
Where FileViewModel is another view model which contains the name and the icon for a file.
The advantage of this approach is that the ViewModels can be reused with other views and other technologies such as ASP.NET or Winforms so you are not locked into the WPF stack. (alos if you work in an environment where there are designers responsible for the look and developers responsible for the behaviour, this helps define those boundaries)
At the end of the day though this logic does need to go somewhere and while there are better and worse ways to architect your application you are still going to be writing code that takes a string and converts it into a series of filenames and icons somewhere.
First, you might want to start by reading about the Model-View-ViewModel pattern (MVVM). Josh Smith had a fantastic article in MSDN Magazine recently. MVVM and WPF go perfectly together. Done right, you won't need IValueConverters so much. The way that you are going about it now is causing a very tight coupling between your visualization and your application actions. MVVM is designed to decouple these elements.
In this context, your view model will track state for you. Your button will be enabled if the CanExecute method on a certain ICommand in your view model returns true. This same concept can handle disabling the button when processing something.
You want to display a list of files in a certain directory that is specified inside a listbox? Have a DirectoryViewModel view model that will handle providing the list of files to the view by binding to the view model. The display of the files can be specified with a DataTemplate specified in XAML with no code behind. This same concept can handle providing the icons to the view whose display can be specified in the template.
You want your status to be red if a status message contains "Error" and green otherwise? Let a view model handle determining the state and let the view bind to that state and now you only need an IStateConverter to convert the state to red or green appropriately (this is one of many ways to handle this problem in the MVVM context).
Get in the habit of keep data and state separate from your view and your applications will be loosely coupled, easier to design and maintain, and easier to test.
Don't know if you are wrong, just making it a lot harder than it has to be!
I use MVVM, so where you are writing customer converters, I provide a bindable property on the view model that tells the view what to do. For example:
To display a list of files, I provide a collection that contains that list.
If I want icons the object in that collection has a icon property
If I want a status to be red or green I provide a StatusColorbrush property.
By moving this logic into the view model, I get:
much simpler Xaml.
can test my view logic without the view.
This approach uses one of the strong points of WPF, it's binding capabilities.