Detecting Mouse Wheel Events When Form Does Not Have Focus In Visual Basic 2010 - vb.net

I want to make an auto log off feature, I want to detect if there is any user input, and if there isn't the user will be automatically logged off. So I want to know how to detect mouse wheel events when the form doesn't have focus. Any help would be much appreciated.
Is it possible, because I have searched everywhere and can't seem to find it.
Thanks.

According to the WM_MOUSEWHEEL Message definition:
"Sent to the focus window when the mouse wheel is rotated. The DefWindowProc function propagates the message to the window's parent. There should be no internal forwarding of the message, since DefWindowProc propagates it up the parent chain until it finds a window that processes it."
The only way you could possibly do this is with a global hook but I very much doubt you can do this using managed code.

Related

Debugging problem in VB.Net with Windows Forms with losing events

We have a huge application that runs through a mass of code for every click you do. In one specific case, where you have a specific control in plain sight (so that the events are firing) and you load some special data into it and then click on the new button the form loses some events, like the closing event (you cannot close the form anymore and stop points in debug mode are not triggered) and one validating of a ComboBox that is really needed for the program. The only thing you can do when you get this kind of error is to restart the application to get out of this subform. But I tested it for 2 days now and even when I activate all points in the 'Exception Settings' I don't get any exceptions. The form (and other controls) are not losing ALL events. The resize, for example, still works. Even a specifically called AddHandler is not firing. Can you iterate somehow through the EventHandlerList? Or is there any way to test WHERE the event dies? Somehow any ideas on how to debug such a problem?

MFC Custom Keyboard DLL Accessed from Application Dialog Box

The overall goal is to be able to access a pop-up keyboard through an application that I am making in MFC.
I have created a dialog box with an empty text field. I would like to be able to click the empty field and have an onscreen keyboard to enter in the data field.
Is there list of functions or tutorials that anyone can provide me with to be able to perform this function? Ultimate I will be making the keyboard from scratch, so any guidance would be useful.
My first thoughts (I might be wrong someone might correct me if i am wrong.)
1)Create your Keyboard Ui in an MFC DLL and export the KeyBoard Functions like LaunchKB(Int screenx,int screeny) and CloseKB()
functions.
2)I would subClass CEdit and CRichedit such that when the edit control gains or loses focus it would call LaunchKB() function with windows ScreenX coordinates where the keyboard has to be displayed or CloseKB().
3) A callback function registered to dll ,which would get called for every click on the keyboard with characters clicked and these characters are to be displayed in the edit control.
This is just my thought ,there may be better ways to implement as well.

How to handle intercommunication between windows

I am able to open a new window by clicking on a button in another window, but my requirement is that I should be able to listen to the events generated from the other window.
Can anybody help me? How can I register the events from one window and listen to them in the other, so that intercommunication can happen?
My answer would be that you shouldn't. Register your listeners in a common controller--that way, whatever events are fired by either window can be captured by the controller, and the controller can decide what needs to happen to what window in what circumstance.
I use TIBCO PageBus (http://developer.tibco.com/pagebus/default.jsp) for inter application events within my ExtJs applications. It is a JavaScript event bus. For instance, similar to what you describe, I have an editor window, which has a button to display a preview window. The editor window on a save, raises a update content event on the page bus, which the preview window subscribes to, upon receiving the event it refreshes the preview.
One of the advantages of this approach is that many clients can subscribe to events, if you have a complex application.

How can I tell if a Balloon tip in the system tray has closed?

I have an application that uses a NotifyIcon in the tray to hide/restore the application, as well as pop up notices to the user of application events. My application has a notification queue, and I use the NotificationIcon.BalloonTipClosed event to determine when to reset the balloon and show the next notification (if there's one in the queue).
This method seems to work great in both usual causes (user lets the balloon close itself when it times out, and user clicks "X" in balloon to force it to close), but there's a third case where BalloonTipClosed doesn't get called:
Notification balloon pops up
While it's visible, user right-clicks on notification icon to bring up context menu, causing the balloon to disappear
The BalloonTipClosed event doesn't get triggered in this instance - I figure it's a bug in the framework (I'm using 2.0), but does anybody have an idea around this? If I don't get this event, my application always thinks there's a balloon visible (I have a boolean that prevents it from displaying multiple balloons at once), and it will never show another icon again, as long as it's running.
This belongs as a comment to Aarons answer, but I am not allowed to comment yet.
If you handle the BalloonTipClicked and MouseClick events on the NotifyIcon (as well as the BalloonTipClosed) then you can capture all the ways the balloon can close. The only thing you have to be aware of is that several scenerios will trigger multiple events, so be sure to code around that (something like isClosed = true, and then reset that when a new balloon is displayed).
In the event handler for the BalloonTipClicked Event, I would check to see if the right mouse button was clicked, and if it was set the boolean to false.
Here's what I ended up doing, though I don't particularly like this solution. I added a second timer to the form and set it for 10 seconds. When a notification pops up (when I pop one), I start the timer, and then in BalloonTipClosed, I stop it. If the timer ticks (meaning that BalloonTipClosed hasn't run yet), I display the next tip manually.
The result is that if it hasn't fired yet, I take care of it. However, I'm open to better solutions if anybody has one.
I think this post from Raymond Chen about balloon notifications may help you:
http://blogs.msdn.com/oldnewthing/archive/2009/05/04/9585032.aspx

.Net Not Responding, Application.DoEvents and Threading

My mdi VB.Net application performs a long operation on some data. Ideally I should use a separate thread to prevent the dreaded “Not Responding” message.
My problem is if I use a separate thread users then have the ability to click on other controls in the application which can directly affect the operation my background thread is working on, creating an error.
Is there any way to prevent all the mdi windows, toolbars and other controls from receiving mouse clicks and keyboard input during my background thread’s operation?
Or is there a way to clear the message que before performing a Application.DoEvents?
Thanks
I would say that the best choice when you don't want a user to click on a control is to set Enabled to False for that control.
CLARIFICATION: Setting Enabled to False for a parent control will also disable any children. So, setting Enabled to False on the main window and and MDI windows, will do the trick.
There are a couple of ways of disabling the controls but I'm not sure it's what you want.
If you have a main window which is completely disabled while a background thread is processing then why go through the overhead of processing on the background? The advantage of processing on the background is to allow the user to still work with the application while you process data.
I think a better approach would be to take Dustin's route and selectively disable certain controls that can affect the background operation. Or make your background operation independent of the UI while it's processing.
If you tell us a little bit more about how your Main Window and Background thread interact we may be able to give you a better solution.
Hide all forms and only show the one main form. Then disable the Toolbar/Menu if you have either. Then have a status bar with a progress bar and when it gets done, unhide the form the user was working on.
When you are using a statusbar or a progress bar while your background thread is processing some longduring task, disabling your form will also disable your progress/status bar from updating. So what you should do in this case is disable every other control exept from the one that needs te be kept active (e.g. like a progressbar).
List<Control> lstControls = GetAllControls(this.Controls);
foreach (Control ctrl in lstControls)
{
if (ctrl.GetType().Name.ToLower().Contains("progressbar") {
ctrl.Enabled = true;
}
else
{
ctrl.Enabled = false;
}
}
Use a thread and display a modal dialog that shows the user the progress of your task and gives the user the option to cancel it.
The modal dialog will automatically prevent input (the parent may have to be the mdi window itself.)
(Please do not use hacks like hiding or disabling controls or windows. And please, please, please! do not use DoEvents.)