WaitCursor, again
-
Hi experts, the problem described in an earlier message[^] has changed sightly. An application I'm developing needs to tell user that it is busy while doing some long-term processing and communication with hardware devices in a separate thread. User, in the meantime, needs to press some buttons on those hardware devices depending on what the application shows on screen. But the application itself shall be locked from user interaction with the exception of a "Cancel" button. I therefore made most controls (excluding the "Cancel" button)
control.UseWaitCursor = true;
control.Enabled = false;When busy time ends, controls are set back to
control.Enabled = true;
control.UseWaitCursor = false;A problem I had was that WaitCursor was also shown on the "Cancel" button. That was because I had set the whole Form to
UseWaitCursor = trueafter processing all individual controls. Having removed this erronuous command now, WaitCursor doesn't show up at all. By playing around a little, I found out thatUseWaitCursor = truehas no effect on controls that are set toEnabled = falseirrespective of command order. Are there any suggestions for 1. Disabling all controls except for "Cancel" button 2. Showing WaitCursor on all controls except for "Cancel" button Luc Pattyn already suggested[^] a modal dialog which is impossible due to the information on screen that user needs to press the correct buttons as mentioned above.Ciao, luker
-
Hi experts, the problem described in an earlier message[^] has changed sightly. An application I'm developing needs to tell user that it is busy while doing some long-term processing and communication with hardware devices in a separate thread. User, in the meantime, needs to press some buttons on those hardware devices depending on what the application shows on screen. But the application itself shall be locked from user interaction with the exception of a "Cancel" button. I therefore made most controls (excluding the "Cancel" button)
control.UseWaitCursor = true;
control.Enabled = false;When busy time ends, controls are set back to
control.Enabled = true;
control.UseWaitCursor = false;A problem I had was that WaitCursor was also shown on the "Cancel" button. That was because I had set the whole Form to
UseWaitCursor = trueafter processing all individual controls. Having removed this erronuous command now, WaitCursor doesn't show up at all. By playing around a little, I found out thatUseWaitCursor = truehas no effect on controls that are set toEnabled = falseirrespective of command order. Are there any suggestions for 1. Disabling all controls except for "Cancel" button 2. Showing WaitCursor on all controls except for "Cancel" button Luc Pattyn already suggested[^] a modal dialog which is impossible due to the information on screen that user needs to press the correct buttons as mentioned above.Ciao, luker
Can you get all the controls except the Cancel button onto a Panel? If so, disable the Panel. If not, use the Tag property on the Cancel button, say "AlwaysOn". Then loop through all the controls on the form and disable any that don't have a Tag property of "AlwaysOn".
Just like that old Carly Simon song... "You're so funny, You probably think this joke is about you" My Mu[sic] My Films My Windows Programs, etc.
-
Hi experts, the problem described in an earlier message[^] has changed sightly. An application I'm developing needs to tell user that it is busy while doing some long-term processing and communication with hardware devices in a separate thread. User, in the meantime, needs to press some buttons on those hardware devices depending on what the application shows on screen. But the application itself shall be locked from user interaction with the exception of a "Cancel" button. I therefore made most controls (excluding the "Cancel" button)
control.UseWaitCursor = true;
control.Enabled = false;When busy time ends, controls are set back to
control.Enabled = true;
control.UseWaitCursor = false;A problem I had was that WaitCursor was also shown on the "Cancel" button. That was because I had set the whole Form to
UseWaitCursor = trueafter processing all individual controls. Having removed this erronuous command now, WaitCursor doesn't show up at all. By playing around a little, I found out thatUseWaitCursor = truehas no effect on controls that are set toEnabled = falseirrespective of command order. Are there any suggestions for 1. Disabling all controls except for "Cancel" button 2. Showing WaitCursor on all controls except for "Cancel" button Luc Pattyn already suggested[^] a modal dialog which is impossible due to the information on screen that user needs to press the correct buttons as mentioned above.Ciao, luker
lukeer wrote:
Are there any suggestions for
1. Disabling all controls except for "Cancel" button
2. Showing WaitCursor on all controls except for "Cancel" button
Luc Pattyn already suggested[^] a modal dialog which is impossible due to the information on screen that user needs to press the correct buttons as mentioned above.Think about it this way: you are still using and displaying information to the user on the form. Thus, the form is not currently busy, thus it shouldn't show a Wait cursor. The wait cursor is meant for if your form is busy and unable to interact for a while. This is not the case here. Disabling all unavailable controls is already a very good hint that the form is 'working' on something, but it also shows that the form is still valid and ready for use. If you set the wait cursor on your form (even if it's not on your cancel button) then I'd get confused as a user: the wait cursor tells me that the form is currently unresponsive, pending the completion of an operation. But it isn't. My advise to you: don't use the Wait cursor for this. It's confusing.
-
lukeer wrote:
Are there any suggestions for
1. Disabling all controls except for "Cancel" button
2. Showing WaitCursor on all controls except for "Cancel" button
Luc Pattyn already suggested[^] a modal dialog which is impossible due to the information on screen that user needs to press the correct buttons as mentioned above.Think about it this way: you are still using and displaying information to the user on the form. Thus, the form is not currently busy, thus it shouldn't show a Wait cursor. The wait cursor is meant for if your form is busy and unable to interact for a while. This is not the case here. Disabling all unavailable controls is already a very good hint that the form is 'working' on something, but it also shows that the form is still valid and ready for use. If you set the wait cursor on your form (even if it's not on your cancel button) then I'd get confused as a user: the wait cursor tells me that the form is currently unresponsive, pending the completion of an operation. But it isn't. My advise to you: don't use the Wait cursor for this. It's confusing.
My vote goes to MicroVirus' analysis here: you need to think about your design in the context of what people are socialized to in using Win Applications. However, there are still things we don't know about the context of what you are doing that are quite important: you mention there's more than one "hardware" something that the app interacts with, and you imply that while the app may still be busy with some other hardware something(s), that one (more than one ?) other hardware something may have some controls presented in the app the user can interact with. We don't know if there's an implicit sequence here ... access to hardware something #1 completes ... and then you interact with its controls while hardware something #2 is accessed ... and so on. Or, whether this whole thing is asynchronous, with hardware something #n going out for lunch whenever. I suggest you think about a progress bar, or multiple progress bars here. But "design" also depends on what you want your user to know in the context of your unique application: your specific application, perhaps, doesn't need to let the user know that the app is busy accessing hardware something(s) #1 ... #n ? best, Bill
"Is it a fact - or have I dreamt it - that, by means of electricity, the world of matter has become a great nerve, vibrating thousands of miles in a breathless point of time? Rather, the round globe is a vast head, a brain, instinct with intelligence!" - Nathanial Hawthorne, House of the Seven Gables
-
Can you get all the controls except the Cancel button onto a Panel? If so, disable the Panel. If not, use the Tag property on the Cancel button, say "AlwaysOn". Then loop through all the controls on the form and disable any that don't have a Tag property of "AlwaysOn".
Just like that old Carly Simon song... "You're so funny, You probably think this joke is about you" My Mu[sic] My Films My Windows Programs, etc.
Thank you, that is nearly what I already implemented to determine which controls to disable and which to leave responsive. My problem is this: a control has
UseWaitCursorset totrue. It shows the WaitCursor, but user can still use it (click button, slide slider, whatever). The same control hasEnabledset tofalse. Now it is inaccessible, as intended, but doesn't show UseCursor any more. Instead the normal arrow cursor is shown, which is not intended. How can I disable a control and show WaitCursor at the same time?Ciao, luker
-
My vote goes to MicroVirus' analysis here: you need to think about your design in the context of what people are socialized to in using Win Applications. However, there are still things we don't know about the context of what you are doing that are quite important: you mention there's more than one "hardware" something that the app interacts with, and you imply that while the app may still be busy with some other hardware something(s), that one (more than one ?) other hardware something may have some controls presented in the app the user can interact with. We don't know if there's an implicit sequence here ... access to hardware something #1 completes ... and then you interact with its controls while hardware something #2 is accessed ... and so on. Or, whether this whole thing is asynchronous, with hardware something #n going out for lunch whenever. I suggest you think about a progress bar, or multiple progress bars here. But "design" also depends on what you want your user to know in the context of your unique application: your specific application, perhaps, doesn't need to let the user know that the app is busy accessing hardware something(s) #1 ... #n ? best, Bill
"Is it a fact - or have I dreamt it - that, by means of electricity, the world of matter has become a great nerve, vibrating thousands of miles in a breathless point of time? Rather, the round globe is a vast head, a brain, instinct with intelligence!" - Nathanial Hawthorne, House of the Seven Gables
Thanks, Bill. I not only need to think about the design, but also about how to convince my customer that the reconsidred design is what he wants. For now, he wants the controls disabled and with WaitCursor. For the important things we don't know yet: There are several "hardware" somethings (devices). Let's call them Charlie, Augustus, Veruca, Violet and Mike. The application shows several controls. One of them is some kind of "announcer" control. There is no 1-on-1 coupling between controls and devices. User can start a sequence in which announcer says "Go to Chalie. Press the red button." User then goes to "hardware" something called Chalie and presses the red button. Announcer changes to "Go to Augustus. Press the red button." User goes to Augustus and presses the red button. Announcer changes to "Go to Veruca. Press the red button." And so on until Mike's red button has been pressed. While user is on his way pressing hardware buttons, there is no need for him to touch any of the application's controls (with the exception of "Cancel" button). Therefore controls shall be disabled and show the WaitCursor. Since some controls (e.g. ListView) don't gray-out text when disabled, the additional WaitCursor would be a really great benefit. But it seems that disabling a control also disables its ability to show WaitCursor. How can I disable a control and make it show WaitCursor at the same time?
Ciao, luker
-
Thanks, Bill. I not only need to think about the design, but also about how to convince my customer that the reconsidred design is what he wants. For now, he wants the controls disabled and with WaitCursor. For the important things we don't know yet: There are several "hardware" somethings (devices). Let's call them Charlie, Augustus, Veruca, Violet and Mike. The application shows several controls. One of them is some kind of "announcer" control. There is no 1-on-1 coupling between controls and devices. User can start a sequence in which announcer says "Go to Chalie. Press the red button." User then goes to "hardware" something called Chalie and presses the red button. Announcer changes to "Go to Augustus. Press the red button." User goes to Augustus and presses the red button. Announcer changes to "Go to Veruca. Press the red button." And so on until Mike's red button has been pressed. While user is on his way pressing hardware buttons, there is no need for him to touch any of the application's controls (with the exception of "Cancel" button). Therefore controls shall be disabled and show the WaitCursor. Since some controls (e.g. ListView) don't gray-out text when disabled, the additional WaitCursor would be a really great benefit. But it seems that disabling a control also disables its ability to show WaitCursor. How can I disable a control and make it show WaitCursor at the same time?
Ciao, luker
Kind of thinking "out of the box:" have you considered using a small animated gif file in a PictureBox to serve the same purpose as the WaitCursor ? Check out: [^] Just a thought, Bill
"Is it a fact - or have I dreamt it - that, by means of electricity, the world of matter has become a great nerve, vibrating thousands of miles in a breathless point of time? Rather, the round globe is a vast head, a brain, instinct with intelligence!" - Nathanial Hawthorne, House of the Seven Gables
-
Thanks, Bill. I not only need to think about the design, but also about how to convince my customer that the reconsidred design is what he wants. For now, he wants the controls disabled and with WaitCursor. For the important things we don't know yet: There are several "hardware" somethings (devices). Let's call them Charlie, Augustus, Veruca, Violet and Mike. The application shows several controls. One of them is some kind of "announcer" control. There is no 1-on-1 coupling between controls and devices. User can start a sequence in which announcer says "Go to Chalie. Press the red button." User then goes to "hardware" something called Chalie and presses the red button. Announcer changes to "Go to Augustus. Press the red button." User goes to Augustus and presses the red button. Announcer changes to "Go to Veruca. Press the red button." And so on until Mike's red button has been pressed. While user is on his way pressing hardware buttons, there is no need for him to touch any of the application's controls (with the exception of "Cancel" button). Therefore controls shall be disabled and show the WaitCursor. Since some controls (e.g. ListView) don't gray-out text when disabled, the additional WaitCursor would be a really great benefit. But it seems that disabling a control also disables its ability to show WaitCursor. How can I disable a control and make it show WaitCursor at the same time?
Ciao, luker
lukeer wrote:
How can I disable a control and make it show WaitCursor at the same time?
Simple answer: you can't. I've experimented with this a little, just like you have. What you are seeing here is base Windows functionality. If a parent uses the Wait Cursor, then all children are considered to be 'waiting' as well. A disabled control has no user interaction, so using a Wait Cursor on that doesn't work. I've become quite convinced that there is no out-of-the-box way to achieve this. I'm guessing it's probably possible, but you're going to have to dig deep into the window procedure for the form and possibly for the child control as well. For a measly thing such as a cursor change, it's not worth the trouble and issues. However, Bill has suggested an alternative, which I must admit sounds much better. I still think the Wait cursor idea is too much against common practice with what users are used to :rolleyes: . So, I suggest going with an alternative.
-
Thank you, that is nearly what I already implemented to determine which controls to disable and which to leave responsive. My problem is this: a control has
UseWaitCursorset totrue. It shows the WaitCursor, but user can still use it (click button, slide slider, whatever). The same control hasEnabledset tofalse. Now it is inaccessible, as intended, but doesn't show UseCursor any more. Instead the normal arrow cursor is shown, which is not intended. How can I disable a control and show WaitCursor at the same time?Ciao, luker
I suppose you could intercept the OnClick and do nothing if the wait cursor is still applied, or similar status checking.
Just like that old Carly Simon song... "You're so funny, You probably think this joke is about you" My Mu[sic] My Films My Windows Programs, etc.
-
Hi experts, the problem described in an earlier message[^] has changed sightly. An application I'm developing needs to tell user that it is busy while doing some long-term processing and communication with hardware devices in a separate thread. User, in the meantime, needs to press some buttons on those hardware devices depending on what the application shows on screen. But the application itself shall be locked from user interaction with the exception of a "Cancel" button. I therefore made most controls (excluding the "Cancel" button)
control.UseWaitCursor = true;
control.Enabled = false;When busy time ends, controls are set back to
control.Enabled = true;
control.UseWaitCursor = false;A problem I had was that WaitCursor was also shown on the "Cancel" button. That was because I had set the whole Form to
UseWaitCursor = trueafter processing all individual controls. Having removed this erronuous command now, WaitCursor doesn't show up at all. By playing around a little, I found out thatUseWaitCursor = truehas no effect on controls that are set toEnabled = falseirrespective of command order. Are there any suggestions for 1. Disabling all controls except for "Cancel" button 2. Showing WaitCursor on all controls except for "Cancel" button Luc Pattyn already suggested[^] a modal dialog which is impossible due to the information on screen that user needs to press the correct buttons as mentioned above.Ciao, luker
Was there a final resolution to this issue of having a disabled control AND a wait cursor at the same time?
Cheers, Mike Fidler
-
Was there a final resolution to this issue of having a disabled control AND a wait cursor at the same time?
Cheers, Mike Fidler
-
Sadly enough, no. I stayed with WaitCursor and enabled controls. In case of some user clicking anything, the software shows an error message.
Ciao, luker
Goal: Have the WaitCursor over a disbled control I experimented a little bit on a small C# form app. Add a Panel to the form and make it the size of the Button you want to add. Add the Button to the Panel and set Dock = Fill (Panel obviously becomes the parent of the Button) Disable the Button (Enabled = false) Set Panel's UseWaitCursor = true When the the app runs, the button will be disabled and the WaitCursor will be visible over it. Conclusion: Use a parent panel to control WaitCursor visibility over a disabled control. It's extra work but you can have what your customer wanted.
Cheers, Mike Fidler