I'm working on a VSTO application (Excel Addin), on this application I have a window with some labels, buttons, and a TreeView. The TreeView can be populated with a huge amount of TreeNode items.
When it's populated with around a million items it takes about 40 seconds to close the window.
while closing the window for the rest of the application.
While closing - the rest of the application remaining unresponsive.
My questions:
Is there a way to close the window and remain responsive?
Is there a way to make it faster to close?
I'm afraid the virtualization of items in TreeView control is only supported in WPF platform.
WinForms must clean system resources for all million items so it takes a while.
Related
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.
I created a WPF application that opens a second window with a window style of none. I have a thread that updates data on the chromeless window and I handle the left button down by calling DragMove to allow the window to be moved around. One monitor has 150% font scaling while the other has 200%.
If I drag the chromeless window to my second monitor, the size changes to be bigger or smaller and the updates from the background thread no longer update the UI. If I drag it back to the original monitor, the size restores and the updates resume.
If I change the style to a ToolWindow, everything works correctly; the size changes while the window is split between the monitors but corrects once moved completely and the UI updates continue. There is apparently something going on relative to moving a window around between monitors when it has a titlebar versus when it doesn't have one.
I have also noticed that without a titlebar, if after moving the window to the new monitor, I shake it causing the other windows to minimize, the window will then resize and updates will resume.
Has anyone seen this or know what I might try? If I can't find a fix then I assume I have to resort to some p-invoke magic to hide the titlebar of the tool window.
I have come across a strange problem.
Basically my app has a primary and a secondary window, the latter is shown on the second monitor. The secondary window has a marquee text animation going 24/7. For the secondary window, I had created a seperate thread with its own Dispatcher, so that the primary window's UI thread could not affect it.
Now I found out, that whenever I moved a modal window on the primary window with the mouse, the movement was sluggish and the marquee text animation became jerky. So I figure, that despite the separtae UI threads, the rendering thread is still the same for the entire process.
My next step was to move the second window to it's very own executable (a seperate Visual Studio project). But even with both windows living in their own processes, still the marque text animation becomes jerky when I move a modal window around in the primary window?!?
How can one application affect another application's rendering so drasticaly?
How to overcome this issue?
I'm using Win 7 x64, Core i5, nVidia GTX 670, .NET 4.5.1.
Edit:
I tried creating a seperate application with Windows Forms, that had a single Label control moving like a marquee, albeit with a regular timer (interval 15ms).
In my main WPF application I launched the primary window without the secondary window and still, moving a modal window inside the primary window causes the marquee in WinForm app to lag and become jerky :S
So I have this old PowerBuilder MDI application (medium enterprise app with about 40 windows), and I'm embarking on designing my very first WPF MVVM C# application to replace the aging PowerBuilder app. I've got plenty of C# & .NET experience, but this is my first WPF & MVVM app.
After reading many forum postings after searching for WPF & MDI alternative, I've come to the conclusion that the MDI isn't supported, and that the most commonly proposed substitute is to use the TabControl and dynamically generate the content of each tab page upon demand using a WPF User Control. I had initially been sold on this, and was actually excited by my initial prototype interface with a tabbed Ribbon bar at the top of the app, and the TabControl with the tabs of the app underneath that. However, I have hit a BIG brick wall.
Take a look at the following screen shot of one of the central multi-tab windows from my old application: http://www.creativedatatech.com/downloads/screenshot.jpg
As you can see, the app has a toolbar across the top and the left side, and the example MDI child window (Case Edit Window) that is open has a LOT of tab pages (18 of them), and the users really like being able to quickly click on a tab page to get directly to that information to work on it. Moreover, the users have grown accustomed to being able to open multiple Cases at once and either put them side by side (large monitors), or flip back and forth, possibly copying & pasting between them.
The problem here is that I cannot envision how I am going to incorporate all this multi-tab user experience for the Case Edit Window into a single tab of the top level WPF TabControl. Will the users end up seeing a row of tabs for the WPF TabControl, with one tab for each Case Edit Window that is open, and then inside each "Case Edit" tab page, a further nested set of 18 tab pages?? This seems confusing and a big mess of nested tabs. Add to that the tabs of the Ribbon control at the top of the app, and I think my users will be running after me to lynch me!
After investing two straight weeks reading up on WPF and MVVM, I am left with the sinking feeling that WPF really isn't going to fly well for enterprise apps such as mine.
Surely this can't be true! Does anyone have any comments on how I should go about shaping this app to accomplish what I'm trying to do here? I've already looked at WPF "pages", but I can't have the users serially navigate through all the individual pages to get to the content that they need to work on, and they need to be able to quickly (and visually) navigate to the Case Edit Window content that they need.
I think your problem is not so much WPF, but rather that GUI paradigms have moved away from the MDI that your current app uses. There is nothing stopping you implementing MDI in WPF, but what would be the point if your app ends up looking like it does now?
You really need to think about how to layout your app in a modern way. Perhaps you could keep your tabs for the different cases, but replace the multiple tabs in each child window with a master/detail view, much like Dev Studio does for its Options dialog?
We had this same dilemma, we decided on screen tabs at the bottom with tabs that relate to that screen at the top - and contextual ribbon items.
The tabs in the screens actually just scroll the window to the desired point so all information is sectioned off and available on each screen by scrolling or clicking the tab at the top.
Looks like this
I am using Wpf 4.0. I have a situation where I need to generate dynamic control on a tab control where around 20 tab are generated on run time. These controls are a lots so the control adding process takes time around 1 minute. Is there any way to add control asynchronously.
Thanks!