Setting variables onfetch

[rlgiordano]

Re: Setting variables onfetch

Hi Tom,
dim global vQuote as C
vQuote = this:QuoteObject.value
That worked Great.

Thanks Bob

[G Gabriel]

Re: Setting variables onfetch

I didn't anticipate any problem, but just for the heck of it I created a variable in the V box and in the OnFetch I put this simple script:

my_variable=table_name->field_name
msgbox(my_variable)

And it works whether it's local, shared or global.
Not sure what is the problem?

[Tom Cone Jr]

Re: Setting variables onfetch

G,

Perhaps I misunderstood something here. I thought Bob was trying to update a global each time the user navigated to a different record... presumably for use in a report or something. You're right the same technique can be used to update local or shared variables, also.

[G Gabriel]

Re: Setting variables onfetch

No misunderstanding on your part or mine either. The variable gets updated but I think we did not get the last chapter of the story..
Reading between the lines..I think what's missing from this whole epilogue, the last chapter, is that Bob fetches through the records, then instantiate the report, and Lo and behold, the variable is not updated..
i.e. the variable gets updated in the form window, but not in the report.
Without testing, I think What Bob needs to do, if this is the case, is to place the same variable in the V window of the report.

[CALocklin]

Re: Setting variables onfetch

If a variable name is used in a script or function, even just to set the value, Alpha is supposed to first check to see if there is a GLOBAL variable by that name then, if no match is found, check for a SHARED variable and last but not least create a local variable if neither a global nor a shared variable is found. And I know that's how it has worked in the past and I'm pretty sure that's how it works in v11 - at least in code stored in the Code Editor. (I'll allow for a 0.1% chance that it doesn't work that way in the OnFetch event but I'm sure it was intended to work that way everywhere.) I've done it that way many, many times. I've also added an "extra" DIM statement on occasion just as a reminder to myself that it's a global (or shared) variable but a DIM statement should NOT be required in every script or function that uses that variable. In fact, somewhere in the A5 Help files there is, or used to be, a warning that a variable name in a script will use the GLOBAL or SHARED value if one exists unless specifically DIMed as a local variable - which is the whole point of using OPTIONS STRICT (which I never use).

Disclaimer: I also almost never use the var->VarName construction (it's only necessary in very specific cases which I prefer not to use in the first place) so <I>maybe</I> that makes a difference - but it shouldn't.

I'm pretty sure the problem here was something else and messing with it finally got the rest of the syntax right. Perhaps checking the Trace window would have helped find the original problem.

I'm guessing that's basically what G was getting at in post #17 also.