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. > >>>>> > >>>>> > >>>>> > >>>>> > >> > >>. > >> > >> > >> >
