Develop Reference

How do I know that a MDI child form has visually changed?

I have MDI WinForms application written in C#. Normally only one MDI child form is visible and all others are in background. Child forms content may occasionally change in background (for example, web browser control may be displaying a page that is dynamically changing every N seconds, chart controls are being filled with data as time goes on).
I want to show small previews of child forms when user hovers a mouse over or clicks on a special button in a toolbar of the main form. I can successfully use PrintWindow function as described here to make screenshots of child MDI forms. This works even for non-active child forms. The only problem is that taking every screenshot may take significant time (about 100-120 ms), probably because of the complex structure of the forms, so that if I make screenshots right before I want to show the previews then this creates a noticeable delay, especially when there are a lot of child forms (e.g. 10-15).
I want to optimize this and re-create screenshots only when it is really needed. Here is what I mean. Initially would I create screenshots for all the forms, store them in a "cache" and show previews. Later, when I need to create previews again, I would like to determine somehow that visual content of MDI form has changed (or change is pending) and re-create the screenshot only in that case, and otherwise use "cached" screenshot.
I tried to implement this by overriding of WndProc function of the child form class and looking for some messages like WM_PAINT or WM_SETREDRAW. But when I log all messages I see neither WM_PAINT nor WM_SETREDRAW even while the form is active (in foreground) and the web browser control on it constantly updates its page. Probably those event are sent directly to the controls of the form, but not to the form itself.
I don't want to traverse every form and connect to "changed" events of all the controls, because all of them are very different and not all have such notification events.
I guess that every control when it wants to change its visual representation sends some notification to OS to force self repaint. So, is there any way to detect such notification from any control inside MDI child form?
UPDATE:
I found WinAPI GetUpdateRect function that should return a rectangle that needs to be redrawn. I thought that if it returned non-empty rectangle then that would mean the screenshot needs to be updated. I tried to call it before the call to PrintWindow, but it always returns empty rectangle.

Update UI when application runs in backroud

I am developing a banking application for Windows Phone 8.1 RT. For security reason I need to grey out or show an image in my application when it goes background.
It's like when application is running user presses windows button then press and hold back button at that time application's current page is visible. I need to show a image on that view.
When application is running if user press and hold back button at that time also irrespective of page I need to grey my application or show an image.
I have tried changing the opacity of frame in On suspending event it is not reflecting. I have also tried in Window visibility changed event changing the opacity of Window.Content but it's not working too.
Please help me with some pointers on how to achieve this.

There isn't a good way to do this. The app doesn't suspend until several seconds after it has left the screen, so it is too late for the app to change its UI then. Window.Activated would be closer, but is still too late.
ApplicationView.IsScreenCaptureEnabled will prevent capturing a screenshot of the page either in the app or on the task switcher page, but won't prevent the image from showing at all.
The least bad may be to call Application.Current.Exit to close the application completely when deactivated. This is generally a user unfriendly idea, but it will remove the app from the task switcher one it closes (it will probably show up briefly first though).
You can post feature requests on http://wpdev.uservoice.com

WPF application with several windows including a non active: focus issue

I have a .Net 4 application with two windows in WPF 4:
One uses the WS_EX_NOACTIVATE style to prevent gaining focus.
The other is a basic Window.
The "no-activate" window behavior is appropriate as soon as I do not select the basic window (it doesn't gains the focus). But when the basic window is selected, the "no-activate" window can be focused... and gains it when the user clicked on it.
It is as if WPF considered two windows of the same application had the right to give focus even if they are not supposed to.
This behavior does not happen if both windows are WS_EX_NOACTIVATE.
Have you ever been faced with this problem?
I have read this: WPF in Visual Studio 2010 – Part 3 : Focus and Activation, but does not solve it.
Edit: I have been able to get around by using a Popup as a base class for my no-active Window. However, I don't want to have a Popup. Why !? The popup never receives the focus: does someone know why / how ? How can I reproduce this behavior to a Window ?
I try to step into Popup / Window code, but it is not very clear !
Thanks !

Try also giving it the WS_EX_TOOLWINDOW.
http://www.daniweb.com/software-development/csharp/threads/273724/a-form-that-doesnt-steal-focus#

OK. I partially solved the problem.
The Window already got the focus if it is directly selected, but it is not focused when a component of the window is selected.
Just add :
Focusable = false;
to any WPF controls contained in the Window and they will never been focused even if the previous focus is a Window of the same Application.

How do I block all keyboard and mouse input to my WinForms app?

I have a WinForms app that is retrieving data from a web service on a worker thread and I need to disable all input to my app until the data is loaded.
Currently, I create a semi-transparent form and place it over my application. When the data call completes I close this overlay form. This works fine accept that it causes considerable performance problems for users running the application over terminal services. I tried making the overlay entirely transparent but that still triggers two redraws of the entire window so this did not help at all.
I know that a common recommendation for handling this is to disable all the controls, but that would also redraw much of the screen so I'm looking for another way to block all user input. Any assistance would be greatly appreciated!
UPDATE: I should have mentioned that we have considered the modal dialog. Currently we show the overlay, start the data access thread then construct the form. If there is no better way to block input (App.BlockInput() might be nice) then we could use the modal dialog idea, but we would need to wait until the form construction had completed and there isn't currently a nice, central location to do this.

You could display a small modal (modalForm.ShowDialog(yourForm)) form with progress bar rolling on top of your app. This won't cause big areas to be redrawed.

If your app really is blocked while the operation is running, I'd do what Microsoft frequently does: open a modal dialog box with some kind of throbber animation or ProgressBar, and a Cancel button. Redraw is limited because you're only drawing the size of the new dialog, and input to the rest of your application is blocked because the dialog is modal. Also, users are much more willing to wait when you have some kind of status updates and or animation, because it looks like the computer is "working".
However, if there are operations your user can do while your web service request is running, it's better to leave the controls accessible. At very least, there should always be a way to interrupt/abort the process.
Update: Since you now changed the question: How long is it taking to construct the modal dialog? Why not simply construct the dialog empty, and then populate its controls? If all you have is a small dialog box with a single button and a single ProgressBar, then calling dialog.ShowDialog() should happen faster than your user can interact with your UI. Is that not the case?

One thing you could try for keyboard input is setting the KeyPreview property of the form to True. This will pass all keyboard events to the Form object first instead of to the individual controls. Create an event handler for the KeyPress event of the form and in there you can set the Handled property of the KeyPressEventArgs to True to prevent the key stroke from being passed to any of the controls. If you're currently retrieving data from the web service, set the Handled property True otherwise set it to False and the key stroke will be passed to the controls.
If someone has a good idea on how to handle the mouse input yet you're set.

I'd typically create a LockUI() and UnlockUI() functions in my form that toggle controls and flip a local form field that acts a flag to indicate a long running process. This approach works really well if you use a command pattern.
As previously mentioned, you could toggle keyboard input by using the KeyPreview property of the form (as suggested by TLiebe).
As far as mouse input is concerned, you could disable mouse activity by hooking the WinProc messages and intercepting mouse input messages. This is basically what KeyPreview does.

How do I prevent my custom tooltip code from drawing when that part of my window is obscured by an always-on-top window?

We have implemented some custom tooltip-drawing code that fires on Tick events of a timer. Whenever this event fires, we check to make sure our control is visible (this.Visible) and is the foreground window (GetForegroundWindow()).
The problem we are having involves "always on top" windows like Task Manager or Process Explorer (when the "always on top" option is enabled). Because these windows are always on top, sometimes our application is occluded/covered by such windows, but our tooltip still pops up and gets drawn on top of the top window.
I have tried to use the Form.TopMost property, but this is not acceptable because then, tooltips never appear if there is an "always on top" window anywhere. In this case, our application is even active, so we should be showing the tooltips.
How do I detect/determine whether there is an "always on top" window covering the area on my form where the mouse is hovering? I want to prevent the tooltip from showing "through" the window.

It sounds like you're polling the mouse position with a timer, and then displaying a tooltip. That's the wrong way to go. What you should do is detect mouse-move messages. If you get mouse-move events telling you that the mouse is in a certain region, then set a timer, and if the mouse hasn't left that region by the time the timer fires, display the tooltip. (Incidentally, that's how native Windows tooltips work. See TrackMouseEvent.)
That solves your problem with always-on-top windows automatically because if part of your window is obscured by an always-on-top window, your form simply won't receive mouse-move events for that region, so you don't need to check whether the mouse is really there.
If you're set on using your current technique, then you can use the WindowFromPoint API function to determine what window is visible at any given point on the screen. Use that to determine whether your window is on top at the place you plan to display the tooltip. (The .Net Framework API map says the .Net equivalent to that API function is Form.GetChildAtPoint, but that only gives children of a .Net form, whereas you need to consider all top-level windows, including non-.Net windows.)