Globals, trapping using setProp [was Re: Testing for numerics]

[Jim Ault]

If you want a trigger, Rev sends messages for both setting and getting
custom properties.  Sooooohh...

a one-liner is all we need in our working scripts......
set the trapGlobalEvent of this stack to "gExecuteStatus"
--I made up ŒtrapGlobaEvent¹

and one handler in the stack or back script or library

setProp trapGlobalEvent  glbName
-- do some stuff
end trapGlobalEvent

Below is a working script, so just create a new Mainstack,
paste the following into the stack script,
apply, 
then doubleClick anywhere on the stack to see how it works.

--------start copy script here -------------------------------------------
on mouseDoubleUp
  -- a stack script, card, button, field, group, front
  --we want to initiate a global and supply a trigger
  --using a one-liner in any Rev handler
  -- our global is named 'gExecuteStatus'
  set the trapGlobalEvent of this stack to "gExecuteStatus"
end mouseDoubleUp

setProp trapGlobalEvent  glbName
  -- a stack script, back script, or stackinuse (library)
  --triggered by the handler "mouseDoubleUp" in the stk script
  
  answer glbName & " triggered by mouseDoubleUp from "& the target
--optional
  do ("global "&glbName) --declare
  do ("get "&glbName &" is among the items of the globals") --retrieve
  if it is true then exit trapGlobalEvent  --already done
  
  do ("put null into "&glbName) --init value to null
  breakpoint  --install temporarily until you know you did not
  --create a recursion event/trap loop (see below)
  
  ------  --we don't care about actually setting the custom property
  ------  --we just want to TRAP the event that we triggered
  ------  --then ....
  ------  --     take the action of declaring and giving it to Rev
  ------  --    and [ ta-da ]  auto-initialize it to null
  ------  --
  ------  --and "trapGlobalEvent" never gets created
  
  ------  --on the other hand
  ------  --we could count the number of events by
  set the lockmessages to true ‹ to avoid recursion*
  get the trapGlobalEvent of this stack
  set the trapGlobalEvent of this stack to (it+1)  --does the setting
  get the trapGlobalEvent of this stack
  set the lockmessages to false
  answer  "the trapGlobalEvent of this stack has been triggered "& it & "
times"--optional
  --save this stack  --if you wish persistence, like path names, etc
  
end trapGlobalEvent
--avoid recursion*  means that
--   our line of code that sets the trapGlobalEvent would be caught
--    by the same handler ... this one!  So by locking messages, none is
--    sent, but the customProperty IS updated by rev.  A nice subtlety, eh?
---end copy script here ----------------------------------------------

Hope this helps you get the most out of your global system


On 10/12/06 1:20 PM, "Robert Sneidar" <bobs at twft.com> wrote:

> OIC Jim. I think you've nailed it. A declared global does NOT show up
> in the globals UNTIL you put something into it! Brilliant! So is
> there a handler that gets triggered if I declare a global? If so, I
> can intercept it and auto-initialize it with a handler to null and
> never have to change a line of Foxpro code that checks for null
> globals! BRILLIANT!!!
> 
> I turned the message watcher on but cannot discern if any of the
> messages are the result of declaring a global variable. Still, this
> is workable.
> 
> Bob Sneidar