When i open a window it first has false title(still not updated) after several seconds title updates, is there any function or a practical solution to wait for this so then i could send a message somewhere when this happens...
What i have is a cbt hook that gets wparam when window activates, i need to wait for this wparam to become real title(not the fake one)
I can put a sleep for every activation but that would slow everything down.
Provided your target window is following the standard method to update its caption, you can add a hook to catch the precise moment when the caption has changed.
To do this, you will need to add a windows message return hook with SetWindowsHookEx, passing it a CallWndRetProc handler from your code to receive notices upon completion of windows messages by the target window's message handler.
SetWindowsHookEx() # MSDN
CallWndRetProc # MSDN
The windows message you need to trap is WM_SETTEXT, which is sent to trigger the change in the default text/caption for a window.
WM_SETTEXT # MSDN
If you would like to test this in isolation, WM_SETTEXT is an implicit message sent upon calling SetWindowText to change the window text/caption.
SetWindowText() # MSDN
Also, you might also be able to get rid of your cbt hook, as WM_ACTIVATE, WM_MOUSEACTIVATE, and WM_SETFOCUS can be trapped with the same hook used to trap WM_SETTEXT. These messages cover various levels of activation activity and type for windows.
WM_ACTIVATE # MSDN
WM_MOUSEACTIVATE # MSDN
WM_SETFOCUS # MSDN
Last, if the target window is a window you create and control in your own process, you could simply intercept those windows messages instead of using hooks. If it is impossible to use your available frameworks to intercept those messages, SetClassLongPtr is also another alternative, which may be used to implement a subclass for that type of window to allow you to intercept window messages. If you use this method, you would delegate all calls to the original windows message handler, and only act during a return from the original procedure upon receiving a message of interest.
SetClassLongPtr() # MSDN
WindowProc # MSDN
Here's how I would do it in c#:
Set up a listener for the textchanged event.
this.something.TextChanged += new System.EventHandler(something_TextChanged);
Then setup the code that will do whatever you need when the text changes
void something_TextChanged(object sender, System.EventArgs e)
{
// your code
}
Related
One of the window classes in my cross-platform library is a generic drawing area, accessible through an interface like
struct AreaHandler {
void (*Draw)(AreaHandler *, Area *, DrawParams *);
void (*MouseEvent)(AreaHandler *, Area *, MouseEventParams *);
BOOL (*KeyEvent)(AreaHandler *, Area *, KeyEventParams *);
};
If the KeyEvent() method returns TRUE, the key is considered "handled" and not passed to the system.
For instance, if the user presses the Tab key and KeyEvent() returns TRUE, tabbing between controls should be inhibited and the Area will eat the tab key. But if KeyEvent() returns FALSE, the Tab key should be given to the system, and the system will tab to the next control. Same for F10: if KeyEvent() returns TRUE, the system won't see the F10 and won't activate the menubar.
My current design works like this:
In the message pump, verify that the current focused window is an Area
If it isn't, IsDialogMessage(), TranslateMessage(), and DispatchMessage().
If it is, and the message is not a keyboard message, IsDialogMessage() and DispatchMessage().
Send a special message to the Area to handle the keyboard event, returning whether or not it was handled.
If it was handled, discard the original message.
Otherwise, IsDialogMessage() and DispatchMessage(). The Area window procedure will then simply send the messages to DefWindowProc().
This design works, and handles all cases cleanly, but it means I can't use the Area control in anything that doesn't use my standard message pump. In this case, I refer to dialog boxes.
For the common dialogs, I have to disable every top-level window myself to make sure no messages on my Area can come in. This is both inelegant and doesn't let the dialog manager handle the owner window properly.
For custom dialogs, this means if I want modality, I have to implement modality myself, again disabling every window manually and not allowing an owner/owned relationship.
This is unattractive. I could get rid of a lot of code and be able to do things "the right way" by being able to use the standard dialog modal message pump. But I'm not sure how to do that while keeping the input behavior I want (handle messages as they are retrieved from the pump, choosing whether to send them to IsDialogMessage(), TranslateMessage(), and DefWindowProc() as needed).
I know about WM_GETDLGCODE. That won't work in two ways. If I process the message in WM_GETDLGCODE and handle the event there, I'm going to get an extra window message later I won't know what to do with. Unless there is a way to know tha the message was the one I got before? If I ask for all messages and then process the messages, it'll be too late to give the message back to WM_GETDLGCODE. This means that if the Tab key is pressed, I won't be able to do tab navigation anymore, even if the key event wasn't handled.
And then what about WM_CHAR messages? The standard dialog message pump likeliy has a TranslateMessage() in it, so I'm bound to get those. Is there a reliable way that I can map a WM_CHAR to its source WM_KEYDOWN, assuming the relationship is 1:1? That way I can either discard the message or pass it to DefWindowProc() like I did earlier. But this 1:1 relationship doesn't sound right to me; what about IME?
Would message filters be a solution? I read this post but I'm not sure if the valid use of a message filter stated here is the same as mine.
This is not MFC; I do not have PreTranslateMessage().
Thanks.
The Whole GUI is loaded. After clicked on certain button, the GUI is not responsive: any buttons are no response. If I switch to other app and switch back, the GUI is OK immediately.
Behind the clicked button, it is a handle sending requests to back end. I debugged app, and data has always been returned.
Since the app is huge and I'm not familiar with it, I cannot extract a simple model of sending requests and processing data.I wonder possible causes, since I have no idea now.
Best regards,
-----Add More-----
The back end request sending is in a threadpool thread; when getting data, no UI controls are updated directly. Only presenters (view model) are updated, which are binding to UI control.
I think as sa-ddam213 have suggested and I too believe that you are executing a code block in background Thread or Task.
I think problem is that
- On button click, start execution in background.
- You have kept a flag for checking if background process is running for CanExecute() for the Button's Command.
- UI checks CanExecute() for the Button's Command for a while then does not as mentioned in another question here - Is Josh Smith's implementation of the RelayCommand flawed?.
- Process returns in background.
- UI does not knows the background process is completed and as it has stopped checking the CanExecute() for the Button's Command, UI will not come to know itself.. (you need to tell it)
- Therefore UI is not responding but when user will click somewhere in the application or do an in-out as you said, it will back again.
Solution
- By using InvalidateRequerySuggested method you can invoke the command requery on UI thread so UI will recheck the CanExecute() for each Control and/or Button Command.
// Forcing the CommandManager to raise the RequerySuggested event
CommandManager.InvalidateRequerySuggested();
The InvalidateRequerySuggested method forces the CommandManager to raise the RequerySuggested event. The RequerySuggested event informs a command source to query the command it is associated with to determine whether or not the command can execute.
For more refer:
- How does CommandManager.RequerySuggested work?
- MSDN - CommandManager
- MSDN - CommandManager.InvalidateRequerySuggested Method
Its just a wild guess but try dropping the priority of the logic inside your click event
Example
private void Button_Click(object sender, RoutedEventArgs e)
{
Dispatcher.BeginInvoke(DispatcherPriority.Background, (Action)delegate
{
// all your code here.
});
}
According to MSDN
Dispose will be called automatically if the form is shown using the
Show method. If another method such as ShowDialog is used, or the form
is never shown at all, you must call Dispose yourself within your
application.
What happens if I launch a form via
System.Windows.Forms.Application.Run(form);?
Closing the form allows execution to continue. If I call form.ShowDialogue() after the block it throws up an ObjectDisposedException. To be sure, do I need to call form.Dispose() when launching a form via Application.Run() or is there any advantage or disadvantage to doing so?
The ApplicationContext class controls the lifetime of the UI thread. Its ExitThread() method initiates a shutdown that exits the internal message loop. When you use the Application.Run(Form) overload then Winforms creates an ApplicationContext with the ApplicationContext(Form) constructor. Which subscribes the form's HandleDestroyed event, the event handler calls ExitThread().
So the lifetime is purely based on whether the native Windows window for the form is alive. The two common ways to destroy that window is the user clicking the window's Close button or your app calling the Close or Dispose methods. Either way, the form is automatically disposed. The form object is dead after this, trying to revive it throws ODE.
Shortly after posting I found the answer in another area of MSDN
The Dispose method of the Form class will be called prior to the
return of this method.
Is it possible to prevent the WPF CommandManager from executing it's attached CanExecute delegates?
I have an Unhandled Exception Handler routine that displays an error window for the user. I have a situation at the moment where an exception is being thrown as part of a CanExecute chain. This invokes the exception handler, which displays the window. At this point, CommandManager kicks in and requeries the CanExecute, throwing another exception, invoking the handler, showing another window, requerying CanExecute, throwing another exception... etc. etc. etc.
I somehow need to prevent this rerunning of CanExecute. I have tried to simply ignore subsequent errors in the handler, but this means that the exception information in the error window is blank.
The best resource is the to look off is from the ICommand Interface which has the CanExecuteChanged Event. Operations which subscribe to that event will be notified to disable itself.
It is unclear what your structure is setup as, but I would surmise that the originating operation could fire this event upon starting the process, then when it is done fire the event again to announce that other command processed can run.
Example of the originating command operation to notify others to inspect status before turning on their commands:
private void DoTheCommand()
{
_isProcessingCabExecute = false; // Turn off all related for this
// command (is Execute).
_opCommand.RaiseCanExecuteChanged(); // Inform all subscribed to check status
// and disable where possible.
// The operation
_isProcessingCabExecute = true; // All done turn it back on
_opCommand.RaiseCanExecuteChanged(); // Resume operations.
}
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.