Tamars answer is fine, it's elaborating on bindevent, what I already hinted on, additionally to introducing the idea of a central EnableControls. Enabling/Disabling controls also is what the ffc application framework does in forms you create with the wizard, so this concept is well known and defined.
But I have another understanding of UI today. I don't like disabled controls, because they most often just rise questions from users, what to fill in to enable something. This can be the fault of the developer not streamlining the workflow properly, this can also be a problem of the user's understanding.
I often have forms with a compound control known as "mover". You have a list of options filled with selectable items, you have a list of selections, initially empty. You add something to the selections list, then click an action button, eg print a receipt or start a further form, whatever.
I could disable the action button, until there is at least one option selected into the selection list. But sometimes beginner users merely click an item in the options list and don't move it to selection, that needs a double click or they could select multiple items and use a right arrow button to move items from the options to selections. I rather not disable the button, but instead let the click display a user friendly message to please select items into the selection list, as there is nothing I can do with no selections. This whole mechanism then is self explanatory, more than a button which only get's enabled when you select an item.
And this is just a simple example. I say this because this concept of disabling is outdated. Look at any smartphone interface, do you really know disabled items, do you know a greyed icon means something is disabled? Users click on such buttons and get angry they doen't work, and they are not told what to do.
Actually I corrected such a form recently, which was a choice of data to transfer from a pc (online) to a netbook (offline). In case you didn't make a selection you got an empty transfer file, in detail it wasn't empty, because there always is additional base data. I added the message and n ow it should be clear.
There are pros and cons, but even if you did what you did for many years, new user come in with a different mindset. Kids don't start with PCs today, they start learning to work with smartphones and are used to a totally different UI.
I can tell you a story happening to me, with something so simple as a mail client. Outlook 2010 that is. First time I used this a created a new mail and finally wanted to send it, but there was no Send button. You might wonder, I make this up, but actually, if you don't configure your outlook 2010 account a mail form has no send. It does neither have a disabled or enabled button, it simply has no button. And nothing is telling me my administrator forgot to configure outlook after installing it.
It's actually more natural to not get confronted with the whole UI, which could get enabled somehow, but with the base controls which always are needed at start. But in my case the send should be there, if the form should rather warn me before I start writing a mail, that I can't send it.
Aside of this Outlook problem, to only show controls for an initial step and hide the next steps, especially if they are optional, until they become necessary, is a good strategy, I think. But I already warned you about not putting everything into one form, you better have popup windows, and even if you would want to have the controls on this form, I wouldn't put controls on the form invisible and show them, I would rather design container classes and add them to the form. That would also make it a class you can separately edit and maintain as the developer. You can do containers, you also can do forms without title bar and position them at where you want them, where you had your controls. You have to think both about the user and about your need to maintain such a UI in the form/class designers. Events to do this would most probably not be lostfocus, but already click or interactive change of options or buttons, so a general binding of textboxes to a form method is also not, what I would do for that matter.
It's very individual what needs to be done on the form level and I wouldn't put this into a general method. What would be a good idea is not to let a button show a container, but program a mediator, a manger knowing the ui and what controls are there for what part of the workflow. Then you would for example have a payment option "credit card" and in it's click would do THISFORM.oWorkFlowManager.ShowControls("credit card payment") or THISFORM.oWorkFlowManager.ShowCreditCardPayment() or THISFORM.oWorkFlowManager.ShowPaymentMethod("credit card"). However you design this is your choice. In any case this would also be rather self explanatory code to further developers later perhaps needed to maintain the application. The workflow manager class would have whatever code is needed, to show the appropriate portion of your form or start a new form.
Bye, Olaf.
