Re: IsValid(Object)
From: David Frauzel (net.weathersongATnemo)
Date: 01/07/04
- Next message: Kevin: "Application Icon"
- Previous message: Jack Roh: "Unit Testing Program .............. Help"
- In reply to: Kurt Barthelmess: "Re: IsValid(Object)"
- Next in thread: Bruce Roberts: "Re: IsValid(Object)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 7 Jan 2004 14:45:09 -0700
kbarthelmess@compuserve.com (Kurt Barthelmess (TeamB)) wrote in
news:3ffc839e.16042718@newsgroups.borland.com:
> You have a serious problem.
It's a scripting language that I'm building, to interact with this
"database", so I guess in a sense I've encountered a situation where the
script needs to raise an exception without the application itself raising
an exception - building exception handling into the script language is
another way to resolve it, I suppose, but it's no more a serious problem
than exists in actual programming languages where the same kind of thing
can happen: then it's not really a problem with the programming language,
but a problem with the program. :D
> Only that won't be reliable. The memory previously occupied by
> FGffContext (before it got Free'd) is still physically present and
> Free'ing something does not erase or zero it out. Its content is
> undefined and it might actually contain something that looks like (but
> is not) the sibling, another sibling, or ....
Ah, good point. I've had the nagging feeling that try..except isn't
really the way to handle unknown conditions, anyhow.
> Is it the case that if FGffContext had a sibling (before it got
> zapped) that the sibling is guaranteed to still exist after all your
> tweaking? If so, you could grab and save that field before you start
> tweaking. After tweaking, test the saved reference instead of going
> back to FGffContext.
Nope, I can't assume anything. During the loop, any number of arbitrary
scripting commands could have executed. For all I know, the entire
database might have been wiped.
> Otherwise you'll have to restart your looping from the top of the tree
> after every tweaking operation. Or redesign the logic in some way to
> ensure that you don't delete stuff out from under yourself. Perhaps
> you could start at the end of the chain and work backwards to the
> beginning?
Determining if I've deleted stuff out from under myself is the one that
has the matrix problem, so I'm saving it for a last resort. I have to
work in a strict order because it's a series of scripting commands. (The
scripting syntax is also XML-like, so commands can be nested inside of
commands: so it executes left to right, top to bottom.)
As an interim solution, I realized I could just save the "path" to the
field in another variable, and then use a database lookup to see if the
field named still exists; though this only works in my case specifically
because of the db-like nature of the app, and because I had already built
those functions (one to get the stringified path of a field, and one to
look up a field given this kind of string).
Looping := AGff.Find(Path).IsValid;
if not Looping then Exit;
// Now we can assume FGffContext is still valid
FGffContext := FGffContext.GetNextSibling;
Looping := Assigned(FGffContext);
Unfortunately, this solution technically suffers from the same problem,
because I don't know if AGff (the TGffFile) is still valid! I have
support for file handles in the scripting language, and there are
commands to open and close files, of course.
So, I have to cascade the solution, and determine whether AGff is still
valid by temporarily saving the name of its handle, and then checking if
it's still on the global list of open handles... :p
Well, I feel better about that than try..except, anyhow.
- Next message: Kevin: "Application Icon"
- Previous message: Jack Roh: "Unit Testing Program .............. Help"
- In reply to: Kurt Barthelmess: "Re: IsValid(Object)"
- Next in thread: Bruce Roberts: "Re: IsValid(Object)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
