LL>First off, are you using 5.0?  If not, you need to get it because
LL>there are some fixes in it that will clear up some of this, but not
LL>all.
Yep, I'm using the latest version of 5.0.
LL>Basically, you're right.  There are inconsistencies--ones that are
LL>difficult to justify using the way the application behaves today.
LL>When build-in methods are triggered internally (e.g. by Paradox as a
LL>result of something you do, everything works fine.  But, when you
LL>trigger these same built-ins using ObjectPAL, you need to take extra
LL>care to put these calls into TRY...FAIL blocks.  
LL> 
LL>Paradox does this internally, but there are some cases where you
LL>don't get the same results implicitly.
LL>Now, whether Borland would call this a bug or a design, I can't tell
LL>you.   But, I do know that this is an area that garnered a lot of
LL>discussion recently on CI$.  I'll go through my notes of the thread
LL>(some 100 pages) and see whether I can glean anything specific that
LL>will help.  
Basically, you've answered the question I had.  I was mainly worried 
that there was some fundamental logic that I didn't understand.  I 
basically know how event streams are started and finished, and it seemed 
that calling the pushButton() method didn't follow the rules of event 
streams.  I thought maybe there was an obvious reason for this that I 
was missing, but it seems more like either there are inconsistencies 
here, like you said, or that this subject isn't well known, or obvious.  
This is sufficient for me, since I would always check the return value 
of a method or procedure I've called, if applicable, and I always make 
my custom methods return a logical value, so that the calling method can 
check for success of the custom method.  Hopefully this will keep me 
safe until such time that I have a better understanding of ObjectPAL and 
the Event Model.  Thanks for your help!
Robert
--- WILDMAIL!/WC v4.12 
---------------