This question already has answers here:
From Windows Forms to WPF [closed]
(3 answers)
Closed 8 years ago.
I have a large, dated looking windows form project. I want to rework it in my spare time, one form at a time, with beautiful wpf. Is this even possible?
I'm thinking I would have to create a separate project, compile it as a library, add a reference to it in the first project, and call the new window vs the old window?
Or would I have to make windows with hosted elements?
Perhaps the most practical approach is to simple redo the whole thing in one go?
Yes, you could do this. As you say, you could host the WPF elements in Windows forms, allowing you to change one page at a time.
You could also do it the other way, creating a WPF project and hosting the windows forms elements. The good part of that is that you have a normal WPF app when you are done (at the cost of some "startup time" to host the forms stuff).
If you can't release it piecemeal, I would just re write the whole thing, as "One page at a time" doesn't give you any benefit. If you can, your approach seems reasonable.
Related
This question already has answers here:
How to create an Explorer-like folder browser control?
(3 answers)
Closed 5 years ago.
Not sure if this is off topic or not, if it is i will gladly delete.
I am converting one of my companies utility programs to C#.NET in winforms it is written in vb6, DEFINITELY NOT .NET as it is 15 years old. and in the UI it has a tool which looks like this
it acts like a folder browser put stays on the UI unlike a folder browser dialog which is a popup. is there a .NET tool which does the same thing or do i have to use a folder browser dialog. ideally i would like to keep it on the screen because i think it looks better to keep it on the screen rather than a separate box. if anyone knows if this is actually a tool in C#.NET winforms or not that would be great
Yes these controls are no longer avaiable in .net, you can create one yourself relatively easily, here is a MSDN link describing what you want
https://msdn.microsoft.com/en-us/library/ms171645(v=vs.110).aspx
This question already has answers here:
Window vs Page vs UserControl for WPF navigation?
(5 answers)
Closed 8 years ago.
I wondered if someone could help me. I'm new to WPF and am currently writing a desktop application, but I cannot seem to get my head around what to use when redirecting someone to a new section of the application.
My options appear to be
Window
Page
UserControl
but I don't understand what the difference between them is, and when I should use each one.
Could someone explain the differences for me, and give an example of what situations/applications you may use each one for?
I'm not sure there is a right answer here, but let me try and guide you. The Window class was created to allow you to have a true window. So, if you need to open a dialog, put it in a Window. Generally you will have at least one Window to house the main form.
A Page was built to be used with the NavigationWindow class. This allows you to build Page classes that are marked up like everything else, but just navigate to them under the covers. This is good if you have a single-paged application where the users just go back and forth between pages (i.e. a wizard).
A UserControl is a way to house reusable markup. These can be housed inside of any ContentControl. These can be swapped out of a "content pane" for example on the main window, like Outlook.
Using that, I hope it helps guide you in the right direction on when to use which. They each have their own uses and are not necessarily exclusive.
I have a .NET application that was written in C# and VB.NET using WinForms. We want to slowly migrate this to something new, in many iterations. The new code will be entirely C# and WPF. We would like to utilize Prism.
As far as I know, we can't integrate the old WinForm app in Prism.
I am considering making my old app show the new app in certain instances. For example, when you press a tab in the old app, the new app opens on top of the old app, with the same tabs. Over time, only the new app would be necessary.
How can I do this?
Like my comment above if you HAVE to do this hack I would start creating WPF Controls and ViewModels and integrate then in WinForms. So your slowly replacing Forms in your Winforms app with WPF Control, Pages, and Windows. Here is a tutorial to get you started
Keep in mind you should be creating a WPF during the side at the same time. That way when your like 85% done you can just concentrate on the WPF app.
I have a process which I break into multiple processes and even when using threading it takes a very long time to complete.
I'd like to give the user an indication of the status of the execution in a cute way (for each process % complete). Maybe betting on the right horse will ease the pain :)
I found this project long ago: A Guided Tour of WPF (XAML)
I have two questions:
This article was written in 2007. Is there better way to achieve this graphic effect?
I have not understood yet, how the application is started, so I'd like to know if I can integrate such "window" in my window application?
Adam Robinson pointed out that the second question is not clear:
The application generates a window as in the picture below - I like to know if it possible to insert it in my "normal" windows application.
This article was written in 2007, is there better way to achieve this graphic effect?
WPF is the current "best" (or at least most feature-rich) way to develop a Windows Application for the desktop.
I have not understood yet, how the application is started, so I'd like to know if I can
integrate such "window" in my window application?
Make your application a WPF Application. This will automatically give you an application, Window class, and everything else you need to get started. Making a WPF application is just like any other application, except that you need to start the message pump, create the application, setup your startup window, etc. The "WPF Application" template in Visual Studio does all of that for you...
Until you understand what all is happening, I'd recommend starting with that, and customizing from there.
If you choose to stick with a win form for the main app, you can still host the desired window/control via an ElementHostControl. (hosts wpf inside winform).
Blessings,
Jeff
I'm writing a WinForms based application for Windows Mobile, targeting the CompactFramework 2.0 and coding in C#.
My application has a menu which the user can select severeral job functions from.
My question is this:
For the job specific screens, should I load a UserControl into a panel in the main form, or is it better to open a new form on top of the main form?
They both seem to meet my needs, and I don't know if there is a "right" answer here.
Is one method more correct than the other?
Forms are Controls (just look at the inheritance chain), and a Form itself doesn't have a whole lot of overhead in and of itself. It creates a native Window, but that's about it.
What should drive your decision is how you use and display your UI elements in your solution. Forms are conducive to many UI architectures, and they're what most developers are familiar with. The designer supports them well, and creating, showing, hiding and closing Forms is a well documented, often used paradigm that works just fine. Yes, you have the load penalty whenever a Form is created as it creates all of its contained controls, but you're going to pay that even if it's a UserControl. The child controls have to be created in either case.
One might argue that Forms require that you recreate them every time, but that's not true. If you use ShowDialog or Hide instead of Close, you can reuse your Forms and pay the price once. The advantage here is that the Form holds your Controls in teh collection and manages all of that for you, so you have little to worry about with the GC and remembering what roots you have alive.
The UserControl paradigm is more complex - you have to manage loading and unloading controls yourself to keep memory pressure low. Complexity also increases cost - cost to maintain, cost to support, and likely cost to develop. However there are some clear advantages to UserControls in some scenarios too. If you use an MVC/MVP pattern and some form of framework that handlesyour Views, a USerControl makes a really good View with the Form becoming the Workspace (the SCSF for the desktop is a classic example of this, and so is the OpenNETCF.IoC framework for the CF).
So which is "better"? It depends on how and where you're using the elements, how your team is already doing development, and how you've architected the solution you're plugging in to. In short, the is no one right answer.
In my experience, depending on your hardware, loading controls far outperforms launching distinct forms. Our devices (Motorola WT4090 with 32meg) have no hardware acceleration, and drawing complete forms seems to really tax them. There is as much as 4-6 second delay any time a form is launched; controls, however, are almost instantaneous.
Maybe the best answer is to create a series of user controls and experiment with loading them onto the main form. It should be a fairly easy matter to then try to create a series of forms that have just the user control to see if you can improve performance.
If you don't see any performance benefit either way, it seems that it would just be a matter of preference.
Use Forms. It's the way the other applications behave. It's the way the user expexts your application to work.
Look at the pre-installed "Contacts" application: On startup you get a contact list. Once you select a contact, a new form is being opened on top of the current window. It's showing all the contact's details. Selecting "edit" from the menu will open yet another form, allowing you to edit the contact. The "Tasks" applicatoin behaves just the same way.
So the user knows: Clicking somewhere will open up a new form, and closing that form will get me back to the last form. You should work with that knowlegde rather than against it. When you use a single form, the user might repeatedly close it while he actually wanted to get back to tha last form.
From a performance point of view I find that forms open fast enough (<1 sec) on my WM 5 and my WM 6 devices.
And while it's possible to achieve form-like behaviour with UserControls, it seems more straitforward to use forms when you need form-like behavior.
So my bottom-line is: Use Forms!
P.S.: There's a good article on CodeProject on : How to create MDI Application in Compact framework
Depends on the complexity of the form/Control. Going the UserControl route will provide better performance as you will not have all of the form create functionality to also deal with.
My advice is to create a new Windows Form for every different logical action. If you need a form that is logically independent, then is better to have a separate Windows Form for it.
To speed things up you could construct all your forms in application's start up. This way you will have a delay when your application is launching (most users will be OK with this), but afterwards everything will run faster.