How to stop windows form from refreshing/updating
-
I am amazed to find that nothing exists (that I can find from a internet search and here at CP) to suspend a windows form from updating itself. I've tried suspendlayout and resumelayout methods of the form with no luck. I see calling the win32 api is one way but wow, this could easily be done in VBA with "ScreenUpdating=false" then set to true again when you wanted to hide screen happenings from the user. My needs arise from programmatically setting some control's (comboboxes, textbox) values that I don't wish the user to see necessarily. Any ideas?
-
I am amazed to find that nothing exists (that I can find from a internet search and here at CP) to suspend a windows form from updating itself. I've tried suspendlayout and resumelayout methods of the form with no luck. I see calling the win32 api is one way but wow, this could easily be done in VBA with "ScreenUpdating=false" then set to true again when you wanted to hide screen happenings from the user. My needs arise from programmatically setting some control's (comboboxes, textbox) values that I don't wish the user to see necessarily. Any ideas?
Why would you set values to controls if you don't want the user to see them ?
Christian Graus Driven to the arms of OSX by Vista.
-
Why would you set values to controls if you don't want the user to see them ?
Christian Graus Driven to the arms of OSX by Vista.
The user will use the controls to input information of course. But, I want the user to be able to do a "quick entry" of sorts, by a less onerous method via some other controls (radio buttons) that, based on these simple choices, cause code to programmatically set the values of these other more numerous controls (with their events firing etc that I want). What my goal is by this design is to 1)make common entries faster for the user to enter and 2)ensure the logic (there's quite a bit of interactions of the controls) of these controls to be the only path of creating the data that the user will be storing via the app. ..so it's a single pathway of logic/code/bug opportunity & fix, in determining the many data elements that the user needs to indicate to the app for what they need to store. Anyway, since my original post I found that I could just set the container of the controls, in this case a tabpage of a tab control, to not visible for the time in question, then set it back to visible afterwards. That seems to work well enough. . .I was just surprised to not have another way of doing what had been available in VBA. I guess if one had a bunch of controls on a form and wanted the user to see them but also have done what I am aiming at then it would be a little more difficult without the way that is easy in VBA (screenupdating=false).
-
The user will use the controls to input information of course. But, I want the user to be able to do a "quick entry" of sorts, by a less onerous method via some other controls (radio buttons) that, based on these simple choices, cause code to programmatically set the values of these other more numerous controls (with their events firing etc that I want). What my goal is by this design is to 1)make common entries faster for the user to enter and 2)ensure the logic (there's quite a bit of interactions of the controls) of these controls to be the only path of creating the data that the user will be storing via the app. ..so it's a single pathway of logic/code/bug opportunity & fix, in determining the many data elements that the user needs to indicate to the app for what they need to store. Anyway, since my original post I found that I could just set the container of the controls, in this case a tabpage of a tab control, to not visible for the time in question, then set it back to visible afterwards. That seems to work well enough. . .I was just surprised to not have another way of doing what had been available in VBA. I guess if one had a bunch of controls on a form and wanted the user to see them but also have done what I am aiming at then it would be a little more difficult without the way that is easy in VBA (screenupdating=false).
OK. Well, what you're doing seems the most sensible way of achieving that to me. I'd just think if you have a quick entry method, there's no reason for the client not to see the result. But, you understand your business rules better than I do, I guess.
Christian Graus Driven to the arms of OSX by Vista.