I am trying to create a subclass of VScroll control and intercepting the WM_VSCROLL message to do some stuff. On msdn, and countless articles/forums, WM_VSCROLL is supposed to be 0x115, even in the windows header file that's what it is. However waiting on 0x115 doesn't bring anything. I realized it's coming through as 0x2115 instead, even this article is using it as 0x2115. Any reason/explanation as to why it's coming as 0x2115 instead? Is it because it's a WinForms control?
Thanks
Yes, this is pretty standard in Windows GUI class libraries, Winforms is no exception. The native Windows control, ScrollBar in your case, send notifications to their parent. After all, they were designed to make their parent act on the notification, not themselves. Or in other words, you expect the parent window to scroll.
That however is not very compatible with the notion of a control class whose behavior you can modify by overriding its message handling and generation. Or for that matter the idea of events in .NET, anybody can subscribe to the Scroll event, not just the parent.
That buys a lot of goodness, but something must be done to get the WM_VSCROLL message from the parent back to the control. Which is what the Winforms plumbing takes care of. It sends the message back but alters the message number to indicate that it was a reflected message, not the original. It adds 0x2000. The value of the (fake) WM_REFLECT message in the Winforms source code.
Related
I have an audio recording app in Windows Phone 7.
The app allows a user to play the recorded sounds.
I try to stick to MVVM guidelines where it is possible.
I have a play/stop button in a list of all recordings. Each recording has its own ViewModel, which, besides all, also controls the look of the corresponding play/stop button.
The button has a custom visual state defined in its' style.
The Visual State is bound to the ViewModel's property using the approach, shown here:
http://tdanemar.wordpress.com/2009/11/15/using-the-visualstatemanager-with-the-model-view-viewmodel-pattern-in-wpf-or-silverlight/
Having implemented this approach, whenever I want to change the look of the play/stop button, I need to set the public string property (named "PlayStopVisualState") in my ViewModel to either "PlayingState" or "Normal", and that will assign an appropriate visual state to my button.
The problem is that when user presses the play button, a SoundEffectInstance is created in a background thread, which plays the sound. The thread then waits for the playing to end. When the recording playing is over (I have to track it in the same background thread, or create another for just tracking SoundEffectInstance.State) I set the PlayStopVisualState property back to "Normal", but I get a cross-thread reference exception. Isn't MVVM specifically designed to allow developers to manipulate logical variables in a view model, and not having to worry about how the changes to them are reflected in a View?
I know that I need to do the adjustment of the PlayStopVisualState property in a Dispatcher thread in order for the problem to disappear, but this is just no right. It, from my point of view, defeats the whole purpose of MVVM, leaving only the organizational advantage.
Or am I doing something wrong? Thanks.
UPDATE:
I have worked around the problem by using
Deployment.Current.Dispatcher
but it seems to me as a very "ugly" solution, given that I almost all over have MVVM pattern followed.
Using the Dispatcher to reflect a UI-bound value is the correct way to do it, yes.
What you're forgetting is that your ViewModel is created on the UI thread. So any change to the ViewModel from a background thread, would a cross-thread operation.
You should consider if a background thread is really needed. , or if you could just schedule your action on the UI thread directly.
Scenario:
The VB 6 form has a InteropControl (WinForms).
The InteropControl has a ElementHost
The ElementHost has my WPF control
Everything seems to be working except that Application.Current seems to be null when I need it. All I really want to do is hook into the unhandled exception event before the first form is fully displayed.
In this scenario is a WPF Application object ever created?
If so, when it is created?
If not, what causes messages to be pumped?
What would happen if I started the Application object on a background thread?
First I will explain how message loops work in interop scenarios, then I will answer your questions and give a few recommendations.
Message loop implementations in your scenario
Your scenario involves three separate technologies: VB 6, WinForms, and WPF. Each of these technologies is implemented on top of Win32. Each has its own GetMessage()/DispatchMessage() loop to pump Win32 window messages.
Here is where each GetMessage()/DispatchMessage() loop is implemented:
VB 6 implements it internally
WinForms implements it in System.Windows.Forms.Application
WPF implements it in System.Windows.Threading.Dispatcher
WPF Application object is optional
Your question assumes that WPF implements the message loop in the Application object. This is not the case. In WPF, all essential functions that WinForms handled in the Application object have been moved to other objects such as Dispatcher, HwndSource, InputManager, KeyboardDevice, MouseDevice, etc.
In WPF the Application object is completely optional. You can construct a complete WPF application with a complex UI without ever creating an Application object. An application object is only useful if you need one of the services it provides, for example:
A common ResourceDictionary
Mapping WM_APPACTIVATE message into Activated and Deactivated events
Mapping WM_QUERYENDSESSION message into OnSessionEnding event
Lifecycle management (Startup/Run/Shutdown/Exit)
Automatic shutdown when the last window or main window closes
Default icon for WPF windows
Remembering the first window opened (MainWindow)
Common registration for NavigationService events (Navigated, etc)
StartupUri
The Application class also provides several useful static members such as FindResource, GetResourceStream and LoadComponent that don't require an Application object to exist.
When you call Application.Run(), all it does is:
Install the mechanism to handle WM_APPACTIVATE and WM_QUERYENDSESSION, and
Execute Dispatcher.Run()
All of the actual message loop functionality is in Dispatcher.Run().
Registering for unhandled exceptions in WPF message loop
The Application.DispatcherUnhandledException event you were trying to use is a simple wrapper around the Dispatcher.UnhandledException event. I think they included it in the Application object because WinForms programmers expected it to be there, but your question shows that this may have backfired.
To register for unhandled exceptions from WPF's Dispatcher, all you have to do is:
Dispatcher.Current.UnhandledException += ...;
Unlike Application.Current, Dispatcher.Current cannot be null: If you access Dispatcher.Current from a thread that doesn't yet have a Dispatcher, one will be created automatically.
Once you have subscribed to Dispatcher.UnhandledException, any unhandled exception from a Dispatcher message loop on the current thread will cause your event handler to be called. Note that this only applies to unhandled exceptions when Dispatcher.Run() is pumping messages: When another technology such as VB 6 or WinForms is pumping messages, that technology's exception handling mechanism will be used instead.
WPF message loop also optional
Not only can WPF run without creating an Application object, it can also function without Dispatcher.Run(), as long as another technology is pumping Win32 window messages. This is done by creating a dummy window and/or subclassing a WPF window to install a message hook. Thus no matter what message loop is pumping messages, WPF will work as expected.
In fact, when you use ElementHost, the WPF Dispatcher is not used for message pumping unless you use one of the following methods:
Window.ShowDialog
Dispatcher.Invoke
Dispatcher.Run (or equivalently, Application.Run)
DispatcherOperation.Wait
Because of this, your WPF exception handler will probably not be called. Instead you will need to install your exception handler at the VB 6 or WinForms level.
Answers to your questions
In this scenario is a WPF Application object ever created?
No.
If not, what causes messages to be pumped?
VB 6 is pumping the messages.
What would happen if I started the Application object on a background thread?
Very little:
If you have application resources these would be created on the background thread, possibly leading to exceptions when they are used on the main thread.
If you add a handler to Application.Current.DispatcherUnhandledException it would only apply to the background thread. In other words, the handler will never be called unless you create windows on the background thread.
Your Application.Startup will be called from the background thread, which is probably a bad thing. Ditto for StartupUri.
Recommendation
From what you are asking it sounds like you are getting an unhandled exception during the loading of your WPF control and you want to catch that exception. In this case, the best plan is probably to wrap your WPF control inside a simple ContentControl whose constructor uses code like this to construct the child:
Dispatcher.Current.UnhandledException += handler;
Disptacher.Current.BeginInvoke(DispatcherPriority.ApplicationIdle, new Action(() =>
{
Content = CreateChildControl();
Dispatcher.Current.Invoke(DispatcherPriority.ApplicationIdle, new Action(() => {});
});
How it works: The BeginInvoke delays construction of the child until VB 6 and/or InteropControl have completed all processing. The Invoke call after the child control is created invokes an empty action at low priority, causing all pending DispatcherOperations to complete.
The net result is that any exceptions that were thrown within or just after the constructor are now passed to your exception handler.
In WPF, the Application object is not directly responsible for the message pump, it is the Dispatcher. When you start a WPF app, Application.Run() is called at startup, which calls Dispatcher.Run().
In your interop scenario, Application.Current will return null since it is never created. Message pumping is handled by VB, since it creates the main window. If you rely on it in your code you can either:
Create a new Application object:
if (Application.Current != null)
{
new Application();
}
Application is a singleton, so it will be automatically stored in Application.Current.
Avoid relying on it whenever possible (which I think is the recommended way). You should note that many of the services this class provides (e.g. the Exit event) will not be available in your scenario anyhow. If all you need is the unhandled exception event, you can use Dispatcher.CurrentDispatcher.UnhandledException.
I found some of my winform application controls, such as DataGridView and ToolStrips, are referred to by UserPreferenceChangedEventHandlers. I have no idea what setting of the controls will generate such references and why such references keep my control alive in memory. How can I remove such references from that event? Thanks.
It is the delegate type for the SystemEvents.UserPreferenceChanged event. This event fires when Windows broadcasts the WM_SETTINGCHANGE message. Which typically happens when the user uses a control panel applet and changes a system setting.
Several controls register an event handler for this event, DataGridView, DateTimePicker, MonthCalendar, ProgressBar, PropertyGrid, RichTextBox, ToolStrip, NumericUpDown. They typically are interested in font or cue changes and anything that would affect the layout.
SystemEvents.UserPreferenceChanged is a static event. Registering a handler and forgetting to unregister it causes a memory leak, it prevents the control from being garbage collected. The listed controls ensure this doesn't happen, they unregister the event handler in either the OnHandleDestroyed() or the Dispose() method.
You'll get in trouble when neither of those two methods run. That will happen when you remove the control from the container's Controls collection and forget to Dispose() it. While forgetting to call Dispose() is not normally a problem, it is a hard requirement for controls. It is easy to forget too, controls are normally automatically disposed by the Form. But that only happens for controls in the Controls collection.
Also be sure to call Dispose() on forms that you display with the ShowDialog() method, after you obtained the dialog results. The using statement is the best way to handle that.
One more excruciating detail is important about the UserPreferenceChanged event, it is often the one that deadlocks your app when you create controls on a worker thread. Typically when the workstation is locked (press Win+L). Which cannot come to a good end when you use the controls I listed, the SystemEvents class tries to raise the event on the UI thread but of course cannot do this correctly when more than one thread has created them.
Also the kind of bug that can have a lasting effect, a splash screen for example can get the SystemEvents class to guess wrong about which thread is your UI thread. After which it then permanently raises the event on the wrong thread. Very ugly to diagnose, the deadlock is well hidden.
I hope this makes sense.
I have created several WPF User Controls. The lowest level item is 'PostItNote.xaml'. Next, I have a 'NotesGroup.xaml' file that has an ItemsControl bound to a List of PostItNotes. Above that, I have a 'ProgrammerControl.xaml' file. Each ProgrammerControl has a grid with four different NotesGroup user controls on it (and each NotesGroup contains 0-many PostItNotes.
Then, I have my main window. It also has an ItemsControl, bound to a list of Programmers.
So, you end up with a high level visual view of a list of programmers, each programmer has four groups of tickets, each group of tickets has many PostItNotes.
The trouble I'm having, is that I want to respond to a mouse click event in my mainWindow's code behind file.
I can add a MouseClick event into my PostItNote.xaml.vb file and that is getting called when the user clicks a PostItNote, and I can re-raise the event; but I can't seem to get the NotesGroup to listen for that event. I'm not sure if that's even the correct approach.
When the user clicks the PostItNote, I'm going to do a bunch of business-logic type stuff that the PostItNote control doesn't have a reference to/doesn't know about it.
Can anyone point me in the right direction?
You have a couple choices:
Use the PreviewXXX events which are fired during the "tunneling" phase of WPF event routing. The parent controls can always preview the events going down through them to children.
Use the more advanced approach to hooking up events leveraging the AddHandler method to which you can pass a parameter called "handledEventsToo" which basically means you want to know when the event happened "within" you even if some descendent element handled the event itself.
I am going to take a flyer here. You probably don't want to be handling the event that high up; not really anyway. You are catching the event at the lower levels, which is unavoidable. Consider invoking a routed command from the PostItNote click event handler.
The routed commands bubble up and tunnel down through the tree. You can have an architecture where a high-level handler can listen to a logical event (Opening a postit note perhaps?). The handler for this doesn't need to care where the command originates from. It might be from you clicking something, it might be from clicking on a toolbar button. Both are valid scenarios.
It sounds like you are creating some kind of custom UI, am I right? You want the application to respond to the users interactions. That is what the RoutedCommands are for.
Background: I have a little video playing app with a UI inspired by the venerable Sasami2k, just updated to use VMR9 (i.e. Direct3D9 with DirectShow) and be less unstable. Currently, it's a C++ app using raw Win32, through necessity: none of the various toolkits are worth a damn. WPF, in particular, was not possible, due to its airspace restrictions.
OK, so, now that D3DImage exists it might be viable to mix and match D3D/VMR9/DirectShow and WPF. Given past frustrations with Win32's inextensibility, this seems like a good thing.
But y'know, I'm falling at the first hurdle here.
With Win32 I have created (very easily) a borderless window that's resizable, resizes proportionately, snaps to the screen edges, and takes up the whole screen (including taskbar area) when maximized. It's a video app, so these are all pretty desirable properties.
OK, so, how to do the same with WPF?
In Win32, I use:
WM_GETMINMAXINFO to control the maximize behaviour
WM_NCHITTEST to control the resize borders
WM_MOVING to control the snap-to-screen-edges
WM_SIZING to control the resize aspect ratio
However, looking at WPF it seems that the various events arrive too late, unless I'm misunderstanding the documentation?
For example, I don't know when I'm mid-move, as LocationChanged says it fires only once the window has moved (which is too late).
Similarly, it appears that StateChanged only fires once the window has been restored/maximized (when I need the information prior to the maximize, to tell the system the correct maximize size).
And I seem to be completely overlooking where the system tells me about resizes. Likewise the hit testing.
So, uh, am I missing something here, or do I have no choice but to drop back to hooking the wndproc of this thing anyway? Can I do what I want without hooking the WndProc?
If I have to use the WndProc I might as well stick with my existing codebase; I want to have simpler, cleaner UI code, and moving away from the WndProc is fundamental to this.
If I do have to hook the WndProc, I have to wonder--why? Win32 has got the sizing/sized, moving/moved, poschanging/poschanged window messages, and they're all useful. Why wouldn't WPF replicate the same set of events? It seems like an unnecessary gap in functionality.
Plus, it means that WPF is tied to a specific USER32-dependent implementation. This means that MS can't (in Windows 7 or 8, say) invert the display layer to make WPF "native" and emulate HWNDs and WndProcs for legacy apps--even though this is precisely what MS should be doing.
OK, to answer my own question, I was missing Adorners (never came back in any of the searches I did, so it doesn't seem that they're as widely known as they perhaps should be).
They seem rather more complex than the WndProc overrides, unfortunately, but I think it should be possible to manhandle them into doing what I want.
And I seem to be completely overlooking where the system tells me about resizes. Likewise the hit testing.
For the resizing you're indeed missing the SizeChanged event.
AFAIK there is sadly no OnSizeChanging, OnLocationChanging and OnStateChanging event on a Window in .NET
I saw that one, but as far as I can tell it only fires after the size has changed, whereas I need the event to fire during the resize. Unless I'm misreading the docs and it
actually fires continuously?
It does not fire continuously but you can probably use the ResizeBegin and ResizeEnd events and be able to do that.
Aren't they WinForms events?
Hmm, you're right.
In code you can set the WindowStyle property to "None" and WindowsState to "Maximized"
Im not sure what the Xaml would look like.
Can you perhaps override the ArrangeOverride and/or MeasureOverride to make up for those missing resize events? Measure is the first pass, and occurs when a layout needs to adjust for a new size, so it's kind of like a size changing event.