make mouse disable, how that user could not be able to use it.
-
somewhere in my program i need that user only use keyboard and mouse be out of his or her control. is it possible? how? please show me practical an explicit. tnx
Imagine you sitting in a car, and all of a sudden the radio takes over your wheel and brakes. The user wouldn't even be able to click away any popups (like the ones generated by Windows', reminding you that you need to update) Yes, it's possible. You could prevent input by filling the screen with a large form and hiding the cursor, like a screensaver. No, that still means that I can abort the operation, since there's always a reset-key on the PC.
I are Troll :suss:
-
somewhere in my program i need that user only use keyboard and mouse be out of his or her control. is it possible? how? please show me practical an explicit. tnx
As the previous answer mentions removing all mouse input is not a good idea. However the best that you can achieve is to ignore mouse input messages for your app for certain conditions, for example you should still accept mouse clicks to close the application. The simplest way to do this is to not process OnClick events etc. on your form when a specified condition is met e.g.
private void button1\_MouseClick(object sender, MouseEventArgs e) { if (\_allowMouseClicks) { // do you mouse click processing.... } }or even more simply if it is a different form at specific point only support Keydown etc. events... Alternatively you could override the WndProc for your form and trap the mouse messages here and test against a condition. However overriding the Wndproc isn't that simple a task, but if its the way you want to go have a look at this[^]
-
somewhere in my program i need that user only use keyboard and mouse be out of his or her control. is it possible? how? please show me practical an explicit. tnx
It is generally not a good idea to attempt to force users of your software to behave the way you want them to by limiting their ability to use or control your software through conventional means. They will simply stop using your software or complain to management that it doesn’t work and you’ll end up having rewrite the code, or worse yet, have someone else rewrite your code. (I do not wish to count the number of times I’ve been tasked to do just that.) Be mindful that removing control from the user is the goal of malware and virus writers, we know how popular folks like these are. You should create a user interface that makes it easier to enter data or interact with your controls by automatically moving the focus to the next desired control so that they don’t have to use the mouse. Sometimes it is unavoidable when certain user actions interfere with the application processes such as collecting live streaming data and moving the form can cause an interruption to the data stream. For these situations I allow the user to place or move the form when it is not collecting data, but lock it when it is. It crucial then to inform the user that this behavior exists so that it does not catch the user by surprise and have them do something like hitting the reset button because they think the PC is broke. Rhuros first suggestion is the one that I use when someone attempts to move a form when it becomes necessary to prevent it from being moved during a critical process.
It was broke, so I fixed it.
-
It is generally not a good idea to attempt to force users of your software to behave the way you want them to by limiting their ability to use or control your software through conventional means. They will simply stop using your software or complain to management that it doesn’t work and you’ll end up having rewrite the code, or worse yet, have someone else rewrite your code. (I do not wish to count the number of times I’ve been tasked to do just that.) Be mindful that removing control from the user is the goal of malware and virus writers, we know how popular folks like these are. You should create a user interface that makes it easier to enter data or interact with your controls by automatically moving the focus to the next desired control so that they don’t have to use the mouse. Sometimes it is unavoidable when certain user actions interfere with the application processes such as collecting live streaming data and moving the form can cause an interruption to the data stream. For these situations I allow the user to place or move the form when it is not collecting data, but lock it when it is. It crucial then to inform the user that this behavior exists so that it does not catch the user by surprise and have them do something like hitting the reset button because they think the PC is broke. Rhuros first suggestion is the one that I use when someone attempts to move a form when it becomes necessary to prevent it from being moved during a critical process.
It was broke, so I fixed it.
S Houghtelin wrote:
collecting live streaming data
On a thread I hope. That shouldn't be affected by form movement.
-
S Houghtelin wrote:
collecting live streaming data
On a thread I hope. That shouldn't be affected by form movement.
We use RS232 to collect raw A to D data from products when they are being tested for FDA compliance. The form, the Comm, and the file I/O are all invoked using their own thread. There is a momentary pause as the screen refreshes each position of the form while being moved, and depending on the machine, we've had problems when a user either moves a form to another part of the screen or decides to surf the internet or play solitaire because the testing is so boring. It is simple matter of resources, especially of time. When a company spends in the tens of thousands of $$ for testing, it is best to mitigate any possibility of data corruption. This is mission critical stuff in the medical device industry. The intent of my post is that a person should not prevent a user from being able to use normal interface operations such and clicking a button with a mouse or moving a form. I gave an example where a programmer could be instructed to do a little user action prevention.
It was broke, so I fixed it.