is it possible to get snoop to profile WPF Windows launched from WinForms app?
Yes it is. Snoop can easily be used with WPF Windows launched from a WinForms app. Specifically, Snoop will:
Offer to let you select any process that loads PresentationFramework.dll and that doesn't contain "devenv" in its name.
Actually let you to snoop or magnify any process that meets the conditions in #1 and also has at least one active PresentationSource (such as an open Window or an ElementHost) in its default AppDomain.
Note that when Snoop first attaches to a process it displays Application.MainWindow, or if that isn't set, the first PresentationSource registered that is still showing. This doesn't stop you from snooping other WPF content, however: Just place the mouse over the WPF content you want to snoop and hit Ctrl+Shift.
Nitpick: What Snoop does isn't actually called "profiling." "Profiling" means measuring what methods are called and how much time is spent in them. So to be very precise the answer is "no," but I doubt you were really asking about profiling.
Related
I have a problem that appears to be new to Windows 10.
I want to create a form that is visible to the user, but with no task bar icon and that does not appear in Alt+Tab.
This is perfectly doable if one is happy to sacrifice the normal styling of a window by following the accepted solutions here for either WPF or Windows Forms.
The general advice for both WPF and Windows Forms is:
Set ShowInTaskbar to false
Enable the ToolWindow styling (either through setting the border style in WinForms or the WindowStyle in WPF)
However, this has a new, practical problem in Windows 10 when using Virtual Desktops: the moment you do the above, the WPF or WinForms window will appear in every virtual desktop. See my example application with a red background:
This affects both the Task View switching screen and the actual desktop itself. No matter where you go, the form is there!
Is there any way to show a form - or even just a bitmap - on Windows without anything appearing in the taskbar, without anything appearing in Alt+Tab and without duplicating the window on every virtual desktop?
I have spent two days researching every possible option, trying every example online, reading MSDN documentation on window styles etc. but all resort to the same method, either through P/Invoke calls or directly, but either way the result is the same.
I'm not sure that's the right way to say it, but what I want is to for my wpf main window to have it's own bar that will behave like a taskbar, and any children windows that will be open from the main one will be placed in that bar in a similar way like the taskbar works in windows - a rectangle showing the window name for example, on click it opens you the window, if you click minimize it will minimize it to the bar, and with some option, to get it out of the main window and move it to the real windows taskbar, with another option for putting it back in. The problem is I don't know if this is even possible, and I don't know the name of such an element, so if anyone can give me any tips I'll be really thankful.
I worked on an application years ago (.NET 3.0: first WPF release!) that did exactly that. We ran into a lot of issues getting it to work, but we were pretty successful in the end. One thing we didn't support was moving it to the Windows taskbar.
The best option would be to set an attached property on each Window. This would register a Window with your custom taskbar, so if you wanted to move the Window out of your custom bar, you'd set the property to false. Setting the property to true would add it to the collection of application windows, as well as register event handlers to track the state of the Window.
One of the major pain points for us was getting the Window animations correct. If you're not running in XP, this probably less of an issue, as the animations in Vista (or is it 7?) and above aren't really showing where a Window is going on minimize. In the end, we had to do a lot of low level Win32 (p/Invoke) work for this.
Take a look at AvalonDock and WPF MDI:
http://avalondock.codeplex.com/
http://wpfmdi.codeplex.com/
I am having an issue with repaint of my WPF control.
The WPF control is added as an ElementHost.Child for a Windows form.
When Windows 7 goes into powersave mode and is brought back to normal (by moving the mouse or key press on keyboard), the rest of Windows form controls are repainted, however the WPF part is not repainted(and the Win 7 background is visible in that area).
On Minimize and maximise of the application, the WPF part is repainted.
Anyone has any idea about this problem?
The solution for this issue was provided in MSDN magazine a while back. It shows how you can make your WPF applications "power-aware" i.e. respond to power notifications. It's an amazing article and a "must-read".
Check this link: Make Your WPF Apps Power-Aware
You can browse the source code online or download it from here: Code for PowerAware
Technologies used:
WPF
.Net Framework 3.0
Windows Vista / Windows XP
Generally, in windows forms calling .Invalidate() on a Control will cause it to repaint itself (via setting the entire control's validation rect to "dirty" and then letting it invoke its own paint event asynchronously. -- If you just invoke the Paint method in winforms without Invalidating first, you will only be able to redraw the portion that was previously marked as dirty -- as windows uses the Dirty Rectangles approach to save on redraw time.)
Hopefully you can either call .Invalidate() on your WPF host control or just call .Invalidate() on the form itself (e.g. "this.Invalidate();")
Enabling double buffering on your form might also help, but I am unsure of this -- it's worth the experiment though.
#Hasan above gave you part of the answer -- how to hook into the windows message pump which and receive windows power event notifications -- but by itself will not cause your window to be repainted (at least from what I can tell) -- it's more of a notification that says "hey, you're about to have that problem you hate. Sucks to be you."
So this is probably as simple as hooking into Hasan's message pump stuff and then calling "this.Invalidate();" any time a power event notification is received. Though that solution may be a little bit overkill.
If that's not enough you may have to tell the WPF control itself to Invalidate... which it can't do, because it doesn't have that method. The documentation suggests that .InvalidateVisual() is the equivalent, but my experience has lead me to believe otherwise. Other than invalidating at the winform's level, I can't help you. If you find the answer, please post it!
I have a very strange issue in my WPF project. The main window contains several wpf controls and winforms RichTextbox(don't ask me why) within WindowsFormsHost element.
Richtextbox contains text. In some cases Richtextbox is not properly rendered when loading window (the right part is white like somebody uses erase tool and clears a rectangle).
This situation is not so common (~20 users / 30 000) and it probably depends on hw. It occurs on XP machines. I have tried to force sw rendering, but it didn't help.
Application is built in .net 3.5 SP1.
Any idea?
The problem was caused by user's unusuall dpi settings in Window. Strange, but with normal values, it works
I need to provide a Windows Forms control to a native application (Visual Studio).
So I create a control and provide its handle.
Then, when I check the native window using Spy++, I see that my control is wrapped in additional 'control' with window class = "Static" and title "This is a static!". I have several problems with it:
Resize events sent to my control by a hosting window have to be re-sent to the "Static" so it also gets resized (otherwise my control get partially hidden within the static's size).
The static does not have WS_EX_CONTROLPARENT, which causes KB149501 to appear (in short, whole application hangs on lost focus).
If I apply WS_EX_CONTROLPARENT, listbox within the static stops redrawing.
I think I have been doing something wrong, but I am not sure what. Google does not help, since static is a C# keyword as well so it occurs quite often in WinForms results.
I mostly solved the redrawing problem using DoubleBuffered=True, so probably this is it.
I still think I am doing something wrong, but at least it works now.