PeterM said:
I need to dynamically build public variables. For reasons beyond
understanding, I need to store the .left, .top, .width & .height
attributes
for entry fields on a form. The form is built dynamically and can have
from
25 to 100 entry fields. For example, if the form is built with a field
called customer_name, I need to dynamically build
The part above that is scary, is the part called "beyond understanding".
That don't make sense.
If you could in fact create zillion variables, an stuff some values into
those variables...how then will you SAVE the values in those variables?
(this just makes no sense!!).
If I create 20 variables, and put a value into those variables...where did
the original values come from? And, once I have successfully stuff values
into those variables...how do you plan to save them?
Why go thought hoops and waste precious time that could be use to feed the
poor?
I mean, why go:
dim myCustomerNameTop as single
mymNameTop = me!CustomerName.Top
Why go to all the trouble to put the "top" value into a variable when you
already have it????
msgbox "the top is " & myCustomerNameTop
Why on earth don't you just go:
msgbox "the top is " & me!CustomerName.Top
What would you gain by taking a existing value, and then stuffing it into a
variable that LOOSES ITS VALUE when the program stops?
Something is wrong...very wrong here...but I don't just know what....
At the very least, you could certainly create a table, and put the values
from the contorls in that:
somthing perahps like:
tblMyForms
FormName fieldName fTop fLength
fWdith
customer FirstName
customer LastName
etc. etc. etc.
At least with a table you desing, then you could then add values, edit
values, or retrieve values at a later time. But, creating a bunch of
variables??? Hum...no...???
At least with a table structure designed, you could "save" the values. How
to you plan to set, and save the values if you could create variables on the
fly anyway? Where will these values come from if you *could* accomplish your
goal?
Something is just so wrong here....
It is not clear what you are trying to do here. There are a good many
dynamic structures such as collections, and tables that would be better
suited to creating somthing that "models" the data you wish to store.
Further, why not just build the forms you need? If systems can be built that
let Boeing design new planes without having to create new forms..then you
should be able to do the same.
Look at accounting systems, or even job costing systems that allow costing
to be done by labor, board feet, weight, or any kind of unit you make
up....and these systems happy function without the need to create new tables
or forms. The secret to these systems is a good data model that allows you
the flexibility you need.
If you can't design the application..then it can't be designed!!
And, if you need something that generates forms for you, then wizards, or
some type of "table" structure as above can work.
I used a lot of "old fashioned" 4th gl systems...and your approach seems to
come from that angle. I don't want to sound harsh..but we don't need, nor
gain any benefits from the 4gl type approach in ms-access. In fact,...it is
a step backwards...
Something seems wrong here in the data model, or the design. I am sure
there is a better possbile solution for your needs (a table seems about
best).
Perhaps you might try and explain what you are trying to do here...I really
can't imagine it is "beyond understanding"....
