[RBASE-L] - Re: Create variable on the fly

[Jim Limburg]

Very, Very Good point. I always attempt to follow
this, or at least now I do. I wasted quite a bit of time troubleshooting
a problem along those lines about a year ago. It like to have drove me nuts.
It did improve my troubleshooting skills with the TRACE environment. I had to
go through a lot of old posts and I found alot of tips on how to use the
debugging environment.
P. S. One other major thing. Most if not all of what I now know has to be
attributed to the people on this list. Especially Bill Downall, Sami Aaron,
Dennis McGrath, David Blocker, Troy Sosoman, Mike Byerly, Ben Perterson,
and so many more... OH yea... that wacky packi... what was is name again.
Jim



Alastair Burr wrote:
Just one thing to add, Jim:

Set Var vXyx_Txt TEXT = NULL
Set Var vXyz_Int INTEGER=NULL
then to convert values use:

Set Var vXyz_Int = .vXyz_Txt
Set Var vXyz_Txt = (CTXT(.vXyz_Int)
so that the variable type is not changed - ever!!

Regards,
Alastair.


----- Original Message ----- 
From: "Jim Limburg" <[EMAIL PROTECTED]>
To: "RBASE-L Mailing List" <[EMAIL PROTECTED]>
Sent: Thursday, September 11, 2003 3:00 PM
Subject: [RBASE-L] - Re: Create variable on the fly



Bill, Alastait, James, listmembers.. Fourscore and seven... hmm.hhmmmm

Interesting idea of getting used to using the same variables all the way
through... Cold make smaller routines easy, but think it would make larger
routines hard to keep track of.  I have always leaned toward the
more descriptive (somewhat self documenting) declaring/naming of
variables.

Along with this idea have gotten into the habit that were suggested by
some of gurus on this list of using a prefix based on how the var is going
to be used... I use
vm_    for variables that I use in what I call a module/function role
vg_    for variables that are going to be of a more global basis, that is
       I will need it across more that one module/function
vp_    for variables that are going to be used in stored procedures
ve_    for variables that are going to be used in a quick eep

vf_    for variables that are used in a forms scope
vr_    for variables that are used in a reports scope
and so on.

Then when I need to clear them (like you say) at the end of the routine
the I would use CLEAR VAR vm_% which would just clear out just only
what I had used in the module/function of code. or... at application
end CLEAR VAR v%
I have thought of but never implemented using a convetion that would
also let me easily see what the datatype should be like..
vm_t  for all text variable
vm_i  for all integers
vm_c  for currency
vm_d  for date
vm_r  for real
vm_dt for datetime
vm_tm for time
vm_v  for varbit
vm_db for double
vm_b  for bit
vm_bn for bitnote
vm_n  for note
and so on.

I have used this code below provided by the great Troy Sosamon for
predfining some variables before the call of a form. I have
modified Troy's original version for own needs here.
-- ARRAY SIMMULATION PROGRAM
-- EXAMPLE WRITTEN BY TROY SOSAMON  1/4/98
-- EXAMPLE MODIFIED BY JIM LIMBURG  09-11-2003
SET VAR vname TEXT = 'vf_value'
SET VAR vtemp TEXT = NULL
-- ASSIGN VALUES TO VARS vf_value0 - 10
SET VAR vi INT = 0
WHILE vi <= 10 THEN
  SET VAR vtemp = (.vname + (CTXT(.vi)))
  SET VAR &vtemp = NULL
  SET VAR vi = (.vi + 1)
ENDWHILE
Jim

William Stacy wrote:

I agree with you completely.  I have a command file that runs every time
I start my app, and it looks something like:
set v i1 int=null
set v i2 int=null
set v i3 int=null
set v t1 text=null
set v t2 text=null
set v d1 date=null
set v d2 date=null
set v  n1 num(4,2,)=null
set v  count_of_pn int=0
and I have about 2 pages of this kind of stuff that presets all my
variables with a null, zero or whatever
default/starting value I want.
I NEVER use the CLEAR VAR command, instead just reset /reuse all these
preset variables using the
very compact syntaxes of:
d1=.#date
i1=0
t1='y'
t2=null
and so on.
Very compact, clean and lean, and the fastest, because it's so easy on
the CPU
I've always suspected that clearing variables created a memory leak, but
cannot prove it.
But it surely causes more typing when coding!
bill

Alastair Burr wrote:


Whilst I appreciate that it is sometimes nice to know if a variable

already

exists (and, if so, maybe even its value) but I would suggest that it is
much better to declare _all_ of them at the start of your app/cmd
file/eep/whatever and _never_ clear them until the end.
Of course there will always be exceptions but I have found it much

easier to

be able to see all the vars at the top of the file and their data type

in

one place. If I need to reset any I simply set it to null or a specific
value before use.
Would anybody like to comment on the overhead of keeping variables

defined

against regularly setting and clearing them (and, maybe losing them)?

With

computing power such as it is these days can a practical limit be

reached?

Regards,
Alastair.
----- Original Message ----- 
From: "James Hageman" <[EMAIL PROTECTED]>
To: "RBASE-L Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, September 10, 2003 9:24 PM
Subject: [RBASE-L] - Re: Create variable on the fly





I like that, short and sweet. However it does give a warning about
setting the variable to NULL without indicator variable or something,
but it still works and holds the assigned value if it is defined. Cool
Thanks Jim
James
Jim Limburg wrote:




James

Just use

SET VAR v1 TEXT

... or whatever datatype is is delcared to as before. Be sure to
keep the datatypes the same though..
Don't set it to null. Doing it this way will not clear the variables
setting if it already exist, but well set it to NULL if it doesn't


exist.



Jim Limburg



James Hageman wrote:




I want to be able to find out if a variable exists and if not to
create it and then pronpt the user to assign a value to it.
I thought I could do something like :

IF (IFEXIST(v1,.v1,NULL)) IS NULL THEN
   DIALOG 'Enter value for v1' v1 vEndKey 1
ENDIF
But I get an error message telling me v1 doesnt exist, Right! I know.





.