put into named field weirdness

Russell Martin russell_martin at yahoo.com
Mon Feb 11 14:11:17 EST 2008


You're right, but, it still doesn't make sense.

In my preOpenStack, I have the following:

on preOpenStack
  if the owner of the target is not me then pass preOpenStack
  answer "preOpenStack called by: " & the short name of the owner of
the target
  [Other ommitted lines of code]
end preOpenStack

...then, in my openStack handler:

on openStack
    
  -- if the short name of this stack is "CSV2HTML" then
  if the owner of the target is not me then pass openStack
  answer "openStack called by: " & the short name of the owner of the
target
    
  [Other code ommitted]  
  
  openPrefsFile gPrefsStackName
  answer "readPrefsStack being called by: " & the name of this stack
  readPrefsStack gPrefsStackName
end openStack

... then in my readPrefsStack handler:

on readPrefsStack _prefsStackName
    [Other code ommitted]

    answer "the name of this stack is: " & the name of this stack
   
end readPrefsStack

... so,

preOpenStack runs and I get the following dialog:

"preOpenStack called by: [NAME_OF_MY_MAIN_STACK]"

openStack runs and I get:

"openStack called by: [NAME_OF_MY_MAIN_STACK]"
"readPrefsStack being called by: stack
"[NAME_OF_MY_PREFERENCES_STACK]""

readPrefsFile runs and I get:

"the name of this stack is: stac "[NAME_OF_MY_PREFERENCES_STACK]""

...now, within my openStack handler, just before I spit out the answer
dialog and then call my readPrefsFile handler, I do, inside of my
openPrefsFile handler, open a separate stack stored on disk, but once
that handler completes and execution returns to the line below it, how
does the recently opened preferences stack then become the stack that
is calling readPrefsFile?!? That doesn't make any sense.


--- "J. Landman Gay" <jacque at hyperactivesw.com> wrote:

> Russell Martin wrote:
> 
> > In the end, the only thing I could get to work in my readPrefsFile
> > handler was like this:
> > 
> > put lNewFilesList into field "FilesField" of cd "card id 1002" of
> stack
> > "[SHORT_NAME_OF_STACK"
> 
> If a long reference works but a short one doesn't, that usually 
> indicates that "this stack" isn't what you think it is. Some other
> stack 
> is the defaultstack and doesn't have the same fields.
> 
> One way to track this is to put a debugging line of code into your 
> openstack handler right before the line that errors:
> 
>    put the name of this stack
> 
> When the handler runs, look at the message box to find out what the 
> engine thinks "this stack" is.
> 
> -- 
> Jacqueline Landman Gay         |     jacque at hyperactivesw.com
> HyperActive Software           |     http://www.hyperactivesw.com
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
> 



      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 




More information about the use-livecode mailing list