I have a winform application with data grid rows with some icons.
When the user clicks on one of the icons, a WPF window opens.
I have created this WPF window using Prism i.e. it has shell and regions mapped to view.
The issues I am facing is:
When I tried to close the WPF window, I get the exception "Cannot set Visibility or call Show, ShowDialog, or WindowInteropHelper.EnsureHandle after a Window has closed."
I understand that we can resolve the issue by hiding the window instead of closing it.
However, this makes my ViewModel and Services representing the older WPF window.
I have kept the static counter in the ViewModels and observed that every time, I open the WPF window, static count increases which means my old view models are not getting destroyed.
I would like how to handle this scenario correctly so that when I close the window everything related to the window should be disposed off.
I tried to do container.dispose in ShellViewModel, however, still it did not work.
There are two aspects here. Firstly, you can use either RegionMemberLifetimeAttribute on your view model or implement IRegionMemberLifetime to make Prism create a new instance each time.
Secondly, you have to create your own RegionBehavior (or take it from this Github Issue) to make Prism dispose view models.
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...
Is the stuff that is displayed when you create a GUI with WinForms or WPF still based on the native controls like Common Controls or any of the system provided Window Classes or is everything that is displayed "custom" drawn by the framework?
Note: I'm not talking about stuff like a file dialog, but GUI that was actually implemented with WinForms or WPF.
And yes, this is purely out of interest.
User HighCore commented:
WPF Uses an "HWND" for the Window objects, but then all other objects
(Controls) inside the Window are WPF objects not related to Win32 in
any way, wheareas AFAIK, winforms uses a separate HWND for each UI
element.
And indeed, using Spy++, we can observe the following when we create a test app with a simple dialog/window and a button on it:
MFC/native:
The app window is a Window (HWND) with the Window Class of #32770 (Dialog) (I used a "Dialog based" app.)
The Button is a separate Window (Class: Button)
Windows Forms:
The app window has the Window Class WindowsForms10.Window.8.app.0.2bf8098_r20_ad1 (oh my)
The Button is a separate Window (Class: WindowsForms10.BUTTON.app.0.2bf8098_r20_ad1)
WPF
There's only one top level Window, although for good measure I added a ComboBox, a ListBox, and a Menu to this window in the UI designer.
The Class of the only Window is: HwndWrapper[WpfApplication1.exe;;9b1aec0f-1b88-419c-8730-858906314cd9]
The Window Class names are actually quite interesting: With the MFC/native one you get the classes known for years and documented on MSDN. With Windows Forms, it does appear that it always uses the same class names. And with WPF it seems the name of a Class of a Window also incorporates the executable/process name.
So apparently MS thinks that using more than one Window per window isn't necessary anymore. I think I need to open a second question for that.
Windows Forms uses native controls for some UI elements. WPF draws everything on its own.
In a Silverlight application that doesn't run in a browser, is it possible to create a new top-level window? Or at least a child window?
I found some solution using the ChildWindow class, but even though my project is configured for Silverlight 4, that class can not be found.
I have a UserControl (XAML file) that I want to show as a new window. Using a tab control is not really an option unfortunately as the user has to be able to arrange windows to see more than one at once.
Any suggestions?
ChildWindow is part of the SDK, you need to add the System.Windows.Controls.dll to access the ChildWindow type.
I'm not sure you can get the ChildWindow to do what you are expecting. A ChildWindow is designed to present a window in a modal manner. However this modal behaviour is really a function of the ChildWindow template. It is possible to re-template to remove the modal behaviour. However I've never tried to manipulate multiple child windows. You could give it a go, the big question would be what happens if you close Child windows in a different order in which they were created?
In order to use a ChildWindow to present your UserControl it would probably be best for you to derive from ChildWindow, instead of UserControl. You may even find it would ultimately be better for you create base class between your specific Xaml and ChildWindow where you would put code that is common to all your windows.
I might be worth you noting the Silverlight 5 will support multiple windows.
I'm creating a HUD window for inspecting biz entities in my WinForms application.
I wanted to have a completely different style of window (minimize the content area and showing only the TitleBar, no system buttons, etc) so I created a WPF application for this.
The problem is that I want this Window to 'live' inside my WinForms application. I can't just add the WPF as an OwnedForm or set the main Form as the Owner of the WPF window.
So, how can achive this?
EDIT: Thanks to pst I found the answer. Here is the snippet:
System.Windows.Forms.Integration.ElementHost.EnableModelessKeyboardInterop(_inspector);
WindowInteropHelper inspectorHelper = new WindowInteropHelper(_inspector);
inspectorHelper.Owner = this.Handle;
_inspector.Show();
A WPF Window has a Win32-window handle/context.
See WindowInteropHelper. You can use this with Win32 (or perhaps there is WinForms support?) to set the owner window of the WPF Window. Be aware the handle does not exist until the "source initialized" (?) event.
However, using just WinForms, you may be able to customize the titlebar as much as you need (you can overwrite the drawing itself via Win32, and I think you lose all the control boxes without going this far).
There are lots of google results on this topic if you use the correct keywords.
I'm adding C# WPF dialogs to an existing C++ MFC app, using a C++/CLI interface layer. I've got things working, except I'm having a problem with modality. For example:
MFC app shows a WPF dialog using ShowDialog. Works as expected.
That WPF dialog shows a MFC dialog using DoModal. The WPF dialog is hidden behind the base C++ app, and is not disabled unless I manually change IsEnabled. Not ideal, but it works.
Now, that MFC dialog is closed. Now for some reason the base MFC app is enabled, when it should still be disabled due to the WPF dialog not having been closed. That's bad, as it now allows the user to do crazy things while the WPF dialog is still open.
I have a feeling that it would work better if I could set parent dialogs correctly. But so far I havent been able to set an MFC dialog's parent as a WPF dialog, or vice versa. And, I don't even know if that'd fix it.
Any ideas?
When opening a CDialog, the trick is to use a WindowsInteropHelper to get the parent WPF dialog's HWND. Then, you can use CWnd::Attach to wrap that HWND in a CWnd class to pass to the CDialog's constructor.
The problem I had was that I already had the CDialog constructed., but not yet displayed. The various versions of SetParent can only be used if your target child window already has a valid handle. I had to write a new function in my CDialog class to set m_wndParent, which is what it uses as the parent when it finally creates the dialog. Then everything works great!
Somehow creating WPF dialogs from MFC dialogs "just works". It's magic.
When showing the WPF dialog, are you using the HwndSource class to wrap the WPF window? If so, you may be able to ::SetParent the WPF window as well as use the HwndSource.Handle property to set the sub-child's parent.