D
dransfield
Is it just me, or a Forms a complete PITA?
I've used them fairly extensively over the last 7 or so years,
building all sorts of things, and each project has been easy a
nightmare of de-bugging.
I'll give you an example: ControlSource. I thought this would be a
nifty way of populating my controls, and the 'problem' is that for
simple forms it actually works okay, so you set up your forms to use
ControlSources.
But when you have controls that are interdependant it all goes wrong.
Eg. In my current project I've got 8 checkboxes. The Checked items
appear as a list in a ComboBox, and the selected item of this combobox
dictates the contents of a list box.
This simple didn't work for me a lot of the time. Macros fire
repeatedly, or not at all, and Excel crashes.
It can be fine when the forms up and running, but then the 'up and
running' processes will conflict with the 'initialisation' processes
that you run to first populate the form when you first run the form.
My conclusions are:
) You can use RowSource, but avoid ControlSource or you WILL regret
it.
) Controls have to be populated by macro instead (eg.
MyForm.ComboBox1.value = "Fred").
) If the RowSource is a calculated set of cells than this can cause
Excel to crash. If this happens then: eg. use the column to the right
of the calc cells and copy and pastespecial into this right hand
column, so the control isn't fed directly as a result of an
application calculation.
) If a Listbox isn't displaying the items in the rowsource that should
be feeding it then try 'application.calculate'
) Macros that fire when a control is changed have to be de-activated
when you're initialising the form (eg. you have some boolean called
"DoNOFireComboboxMacro", etc.). Then once you've set the control you
fire the macro (quite bizarre really!):
....initalisation code....
DoNOFireComboboxMacro = True
MyForm.ComboBox1.value = "Fred"
DoNOFireComboboxMacro = false ' so that it will fire if the user
subsequently changes ComboBox1
ComboBox1ChangeMacro ' now run it.
....initalisation code....
) Allow lots of time for debugging a project, which will be completely
unappreciated by the client.
All of the above have been concluded after many frustrating hours. I
haven't ever conferred with anyone else - perhaps I'm missing
something, and there's better ways. I haven't come across any of the
problems that I've had in text books.
So I'd be interested to hear of other form builder's experience.
Bon Chance,
Dz
I've used them fairly extensively over the last 7 or so years,
building all sorts of things, and each project has been easy a
nightmare of de-bugging.
I'll give you an example: ControlSource. I thought this would be a
nifty way of populating my controls, and the 'problem' is that for
simple forms it actually works okay, so you set up your forms to use
ControlSources.
But when you have controls that are interdependant it all goes wrong.
Eg. In my current project I've got 8 checkboxes. The Checked items
appear as a list in a ComboBox, and the selected item of this combobox
dictates the contents of a list box.
This simple didn't work for me a lot of the time. Macros fire
repeatedly, or not at all, and Excel crashes.
It can be fine when the forms up and running, but then the 'up and
running' processes will conflict with the 'initialisation' processes
that you run to first populate the form when you first run the form.
My conclusions are:
) You can use RowSource, but avoid ControlSource or you WILL regret
it.
) Controls have to be populated by macro instead (eg.
MyForm.ComboBox1.value = "Fred").
) If the RowSource is a calculated set of cells than this can cause
Excel to crash. If this happens then: eg. use the column to the right
of the calc cells and copy and pastespecial into this right hand
column, so the control isn't fed directly as a result of an
application calculation.
) If a Listbox isn't displaying the items in the rowsource that should
be feeding it then try 'application.calculate'
) Macros that fire when a control is changed have to be de-activated
when you're initialising the form (eg. you have some boolean called
"DoNOFireComboboxMacro", etc.). Then once you've set the control you
fire the macro (quite bizarre really!):
....initalisation code....
DoNOFireComboboxMacro = True
MyForm.ComboBox1.value = "Fred"
DoNOFireComboboxMacro = false ' so that it will fire if the user
subsequently changes ComboBox1
ComboBox1ChangeMacro ' now run it.
....initalisation code....
) Allow lots of time for debugging a project, which will be completely
unappreciated by the client.
All of the above have been concluded after many frustrating hours. I
haven't ever conferred with anyone else - perhaps I'm missing
something, and there's better ways. I haven't come across any of the
problems that I've had in text books.
So I'd be interested to hear of other form builder's experience.
Bon Chance,
Dz