Hey folks, I've tried to keep this to less than "small book" scale,
but here we go...
Bob, Sarah, & Alex all concurred in one form or another that:
>Setting variables whose names are construct dynamically requires using "do".
Got it! ...the missing link. :)
To be honest, I never really even considered the implications of what
I was attempting.
Is that something that generally gets learned "by the seat of the
pants" or is it something I've overlooked in reading the
documentation?
------------
>From Mark:
>Whenever you discuss something that involved an error, you really should post
>the error message together with your question. It helps. Really, it does.
I have no doubt that you are correct. However, after the 10th attempt
and a wide variety of error messages, who can guess which one I should
have chosen to post that would have been helpful?
...and then it was added
>It is recommendable to use arrays in this case:
>
>repeat for i = 1 to 10
> put fld i of grp "AllFields" into tVar[i]
>end repeat
I'll really consider that to see if it will fit the need, Mark.
Question: Is getting data into or out of an array any faster than a
repeat loop used on regular variables?
>It doesn't matter, because David writes he got only 10 fields in that group.
Well, the code I posted was just a small sampling of the overall
requirements for the application. I actually will need to use my newly
learned info in a much, much broader scope. (Lot's of variables, text
fields and controls involved, moving a lot of data around)
>Besides, it is really a bad idea to call a field "field 1".
My question would naturally be why? (Explained very well by Scott in #2 below)
------------
Scott added:
>1) When referring to an object name dynamically, bracket the expression in
>parentheses: fld ("myField" & i)
I knew that I had read that somewhere and in most of my attempts, I
did use brackets. Unfortunately, as I now understand it, there was
just no way of it working any way I tried it without the missing "do".
>2) Avoid naming objects using their type (ie "Field1") unless you're very
>careful as Rev may get confused by the actual object it knows as "field 1"
>(the first field on the card) versus your "Field1" which may be the tenth
>field on the card.
Okay, that makes sense. I don't often name things quite like that, but
in this case I did to help mentally clarify the mapping of a large
amount of data from one area of the app where it is used in another.
As in:
Column1--corresponds to->Field1--corresponds to--->tVar1--> is used by..... etc
Is there a chance that this might cause problems down the road as an
executable? In the testing that has been done by myself and others so
far, it seems to be pretty solid. If so, I'll go back and make changes
now.
Again, I really appreciate the help folks.
Best regards,
David C.
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
