I'd like to bring up this topic again because I have some need for it
myself now with D3NT. Here is the original discussion on the topic:
http://tinyurl.com/33e7xd
I'm looking for a solution that:
1) Doesn't go into debug
2) Doesn't clear select lists
3) Doesn't require a filesave after files are created.

The goal is to make this code work flawlessly:
EXECUTE "CREATE-FILE FOO 1 1"
OPEN "FOO" TO FV ELSE STOP
GOSUB DETERMINE.STATUS
IF STATUS = 0 THEN CRT 'VARIABLE' ELSE CRT 'FILE'
STOP
DETERMINE.STATUS:
* voodoo goes here to seeif FV is a variable or file var
RETURN

If no one has a solution for this yet then I might take a stab at it
but I can't waste too much time on it - for free anyway .

Thanks.
T

Tony,

I'll ask you the same question I've always been meaning to ask people
who raise this ... why?

As a person that I know embraces the notion of structured code, how
the hell could you NOT know if you had a file variable or not.
Obviously something that you and the previous posters want to do that
I just dont grok?!?

Goo'day, Ross....

On 11 Feb 2007 19:41:20 -0800, "Ross Ferris" <rossf (AT) stamina (DOT) com.au>
wrote:

Me too. Me too...

Would've thought file naming protocols and coding protocols for
opening those files to whatever variables would've been very near the
top, if not right at the top, of anybody's list of "Programming
Rules"... See last week.....

Even we (read "I") have got stringent rules for file
naming/handling! Followed shortly thereafter by variable naming
rules.

S'pose you could always try to add one to the variable to find out....
Makes as much sense as trying to determine if you've got a file, or
whatever, from code.......

S'pose, also, we're going to see all sorts of code that'll match the
dodgy code offered yesterday/today setting a variable to 5 and then
starting a half-coded supposedly decrementing loop where the variable
is set to 10 to start, and wondering what the answer would be, and why
it's not the same as somebody else's answer ... Oh well, it takes
all types....

BTW, does today's UniVerse still allow the
FOR I = 1 to X
do stuff ......
NEXT J
construct? As a "clean" compile, no questions asked????
Regards,

Bruce Nichol

Talon Computer Services
ALBURY NSW 2640
Australia

If it ain't broke, fix it 'til it is

SELECT FV TO FV.TEST.LIST
STATUS = FV.TEST.LIST<2> # ""

I seem to remember someone else posting this. Can't imagine it's an
original thought.

Mark

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

Uv does not check Next var against the For, though it must exist.

Chandru
"Bruce Nichol" <reverse_ecurb (AT) taloncs (DOT) com.au> wrote

"Ross Ferris" wrote:
Good question Ross.

DesignBais has an Include item for all of their common. I'm trying to
expand my understanding of how data is flowing from one event and
module to another. When I set something 'here' can I expect it to
come out 'there'? So I wrote a program that parses the common block,
extracts all variables, then it creates another program that writes
all of those variables to a logfile in a structured format.

So now when I enter an event handler I just CALL LOG.COMMON, and when
I exit I call again. Then I can run compares or search the data to
see where my changes went or where they made their own changes.

I don't think I've seen anything like this discussed, but it occurred
to me that this would be a good general purpose tool for any
application. So, not knowing which variables are file buffers, if I
tried to store the values the runtime would die, and that's what
prompted this posting. My solution for the immediate problem was to
manually remove the file variables before I generate the LOG code. In
DesignBais all file vars begin with "F.", so it was easy for me to
check for this in my code. All of this is working and the first time
I used it I had some revelations. With other apps we won't be so
lucky, and for a general purpose routine I couldn't guess at this.

The log currently stores data long with flags as key segments for
whether the variable is Assigned and whether it's Null. It also
accommodates dimensioned arrays. The end result being that you can do
an access query for any assigned variables or array elements that
contain specific data, and (with calls littered throughout the code)
you can even track variable changes moment by moment as the app
executes.

If I have a firm solution (like the SELECT FV suggestion that Mark
proposed) I could generate code, run a sample, detect file vars, then
eliminate them in a second iteration.

Inquiries are of course welcome.

TG@ removethisNebula-RnD.com

In generalized routines, there's a good reason to. Fi, in our web RAD, the
user can save state variables, which of course have to be written to a file.
There's a warning in spades not to put file vars (also, in this case, @AM
delimiters) in the state array.

Would be nice to parse the array for filevars, which, as it turns out we
can't do because this is uv and the STATUS instruction drops to TCL on
illegal variable. I guess we could do EXECUTE 'CHECK' passing the variable
in common and examining the CAPTURE! Overhead would be terrible.

Chandru

"Ross Ferris" <rossf (AT) stamina (DOT) com.au> wrote

On Feb 12, 2:27 pm, Tony Gravagno
<g6q3x9lu53... (AT) sneakemail (DOT) com.invalid> wrote:
Tony,

If you rin it in jBASE 4.1 you can use the built in tools to help you
with all of that. If you try for a generic solution you will be, by
definition, bound to the lowest common denominator.

Jim

"Chandru Murthi" wrote:

Chandru, I agree that there is undesirable overhead in any method that
detects file vars. Coming back to what Ross said, this is a developer
tool, we have access to the source, there's no reason why we can't do
our fact finding in development/test mode. Consider the approach I
mentioned where one or more initial runs in dev/test mode would do the
investigation, and the production mode would not attempt to detect var
type.

T

Tony, that's not quite the point. It's not a development/test issue, it's
how I (tool designer) want to make life easier for the application
developer.

Ideally, the tool should ensure validity under all circumstances, in other
words, prevent the developer from shooting himself in the foot. Obviously,
it would be better to send back a message indicating that "ARRAY(42) is a
file-variable, you stupid twit," than to have the phantom server process
abort and logoff and cause the browser to hang with no indication why.

Chandru

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote