Static vars without using a var? - Hewlett Packard

This is a discussion on Static vars without using a var? - Hewlett Packard ; I want to save variables for some programs but I don't want to clutter the dirs up with vars. I want these variables to save values the program will read next time it starts up. The method I am thinking ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 21

Thread: Static vars without using a var?

  1. Static vars without using a var?

    I want to save variables for some programs but I don't want to clutter the
    dirs up with vars. I want these variables to save values the program will
    read next time it starts up.

    The method I am thinking of now involves embedding the values in the program
    object and the program modifying itself and saving the modified version. For
    example, I could put a string at the top of a program with delimiters. When
    the progam loads, it looks for the delimiters and extracts the values. When
    the program exits, it recalls itself, extracts the code either side of the
    delimiters, rebuilds the string around the new values and saves it out.

    I'm pretty certain this will work but I am hoping there might be a more
    elegant method. Perhaps a way of making variables hidden? Perhaps a way of
    writing to an object as a file using an offset like random access?

    Any recommendations or tips here please?

    Many thanks,

    Mark



  2. Re: Static vars without using a var?

    hello,

    - If you are OK with having 1 extra variable in your directory, you could
    create a sub-directory for your variables, or a list in which you place all
    your variables.
    - you could 'hide' your variables. any variable located AFTER a 'no-name'
    variable (create it using "" S~N) will not be visible. so, what you need to
    do is: <<
    1 "" S~N IFERR STO THEN DROP END followed by an ORDER command with the
    variables that you want to hide located AFTER the empty object.
    - I realy do not advise you to use the self modifying program. this is first
    realy slow, and second, would not work for a program in library or something
    like that...

    cyrille

    "Mark Edmonds" wrote in message
    news:haqdnXqLlJr0kBrVnZ2dnUVZ8gidnZ2d@posted.plusn et...
    >I want to save variables for some programs but I don't want to clutter the
    > dirs up with vars. I want these variables to save values the program will
    > read next time it starts up.
    >
    > The method I am thinking of now involves embedding the values in the
    > program
    > object and the program modifying itself and saving the modified version.
    > For
    > example, I could put a string at the top of a program with delimiters.
    > When
    > the progam loads, it looks for the delimiters and extracts the values.
    > When
    > the program exits, it recalls itself, extracts the code either side of the
    > delimiters, rebuilds the string around the new values and saves it out.
    >
    > I'm pretty certain this will work but I am hoping there might be a more
    > elegant method. Perhaps a way of making variables hidden? Perhaps a way of
    > writing to an object as a file using an offset like random access?
    >
    > Any recommendations or tips here please?
    >
    > Many thanks,
    >
    > Mark
    >
    >




  3. Re: Static vars without using a var?

    Cyrille,

    Thanks for your help. Before I get into the detail, one question.

    Could you explain the S~N bit please?

    Is this creating a blank variable containing 1 or a variable called S~N
    containing ""?

    I haven't come across this S~N syntax before. Is the ~ significant in some
    way?

    Thanks!

    Mark

    "cyrille de brebisson" wrote in message
    news:g67bnc$5vg$1@usenet01.boi.hp.com...
    > hello,
    >
    > - If you are OK with having 1 extra variable in your directory, you could
    > create a sub-directory for your variables, or a list in which you place

    all
    > your variables.
    > - you could 'hide' your variables. any variable located AFTER a 'no-name'
    > variable (create it using "" S~N) will not be visible. so, what you need

    to
    > do is: <<
    > 1 "" S~N IFERR STO THEN DROP END followed by an ORDER command with the
    > variables that you want to hide located AFTER the empty object.
    > - I realy do not advise you to use the self modifying program. this is

    first
    > realy slow, and second, would not work for a program in library or

    something
    > like that...
    >
    > cyrille
    >
    > "Mark Edmonds" wrote in message
    > news:haqdnXqLlJr0kBrVnZ2dnUVZ8gidnZ2d@posted.plusn et...
    > >I want to save variables for some programs but I don't want to clutter

    the
    > > dirs up with vars. I want these variables to save values the program

    will
    > > read next time it starts up.
    > >
    > > The method I am thinking of now involves embedding the values in the
    > > program
    > > object and the program modifying itself and saving the modified version.
    > > For
    > > example, I could put a string at the top of a program with delimiters.
    > > When
    > > the progam loads, it looks for the delimiters and extracts the values.
    > > When
    > > the program exits, it recalls itself, extracts the code either side of

    the
    > > delimiters, rebuilds the string around the new values and saves it out.
    > >
    > > I'm pretty certain this will work but I am hoping there might be a more
    > > elegant method. Perhaps a way of making variables hidden? Perhaps a way

    of
    > > writing to an object as a file using an offset like random access?
    > >
    > > Any recommendations or tips here please?
    > >
    > > Many thanks,
    > >
    > > Mark
    > >
    > >

    >
    >




  4. Re: Static vars without using a var?

    On Wed, 23 Jul 2008 10:23:19 -0500, for Mark Edmonds:

    There is a SysRPL entry point called "WithHidden"
    by means of which any STO/RCL can be diverted
    into a "Hidden directory" -- the calculator OS itself
    uses that directory for storing things
    which it doesn't want you to see,
    and some libraries also use this idea
    to save non-volatile data and settings.

    Since there is only one system-wide "hidden" directory,
    only one variable in it can have any given name,
    regardless of your "current directory" path.

    See the following thread (third article)
    for potentially useful UserRPL programs 'Here" and 'Hidden'
    of which the latter can be used for "Hidden directory" access
    (the version posted works in _all_ HP48/49/50):
    http://groups.google.com/group/comp....a151927e0119f/

    Older post (with other usage notes):
    http://groups.google.com/group/comp....3467dc8825c947

    One could also, as previously suggested, use some other directory
    to save things, which could be a subdirectory, but equally could be
    some higher or "other path" directory, such as the 'CASDIR'
    in which the HP49/50 series keeps some permanent information
    which you normally don't directly see,
    or you could "hide" some variables even in the current directory
    (using tricks or third-party "variable hider" programs).

    [r->] [OFF]

  5. Re: Static vars without using a var?

    Mark Edmonds wrote:
    > I want to save variables for some programs but I don't want to clutter the
    > dirs up with vars. I want these variables to save values the program will
    > read next time it starts up.


    Put all your variable values into a list and then just save the list in
    one variable. That way you only have one variable to worry about rather
    than many.

    Regards,
    --
    Bruce Horrocks
    Surrey
    England
    (bruce at scorecrow dot com)

  6. Re: Static vars without using a var?

    On Jul 23, 4:55 pm, Bruce Horrocks <07....@scorecrow.com> wrote:
    > Mark Edmonds wrote:
    > > I want to save variables for some programs but I don't want to clutter the
    > > dirs up with vars. I want these variables to save values the program will
    > > read next time it starts up.

    >
    > Put all your variable values into a list and then just save the list in
    > one variable. That way you only have one variable to worry about rather
    > than many.
    >
    > Regards,
    > --
    > Bruce Horrocks
    > Surrey
    > England
    > (bruce at scorecrow dot com)


    A reminder: when a program is called from within a given directory, it
    can only store variables in that directory. But your program might be
    some utility of general use which you might call from elsewhere than
    its own directory.
    Suppose you are in directory {HOME DIR1} and the program is ProgName
    in {HOME DIR2}. You can run the program (via
    {HOME DIR2 ProgName} RCL EVAL
    for instance). But any variables will be stored in DIR1. You can get
    around that by changing directories within the program and then
    returning to where you were, e.g. by
    << ...
    program code which leaves a value val1 on the stack which you want to
    store as VAR1 in the program's own directory
    PATH SWAP {HOME DIR2} EVAL 'VAR1' STO EVAL
    .... >>
    Irl

  7. Re: Static vars without using a var?

    hello

    > Could you explain the S~N bit please?


    Transform a string less than 255 character into a name object. this allows
    to create variable names that would otherwise be illegal.

    > I haven't come across this S~N syntax before. Is the ~ significant in some
    > way?

    yes, it means that the command is bi-directional. ie, it's a S->N AND N->S
    in one (ie, it transform a name into a string and a string into a name).
    it's a trick that we started using a long time ago to save space and reduce
    command number and that is still alive in the so called 'hacker library'.

    cyrille



  8. Re: Static vars without using a var? [S~N for all HP48/49/50, variable "hiding"]

    S~N converts "anystring" <-> 'anystring' (now a variable name)
    and is a command in the built-in "Development Library"
    of HP49/50 series only,
    recognized for proper compiling and progam editing
    only when that library has been "attached";
    keeping flag -86 set will automatically attach it
    on "warmstarts" (ON+C), or one can do HOME 256 ATTACH
    at any time, before compiling or editing programs.

    The set of commands in that library
    may be viewed via 256 MENU or 256 TMENU,
    and are likely to be explained in any
    HP49/50 series "AUR" document.

    One can also invoke S~N as #100016h LIBEVAL
    on HP49/50 series, which can be compiled or edited
    even if library 256 is not attached.

    The HP49/50 series S~N command,
    like other "user" commands in the "Development Library,"
    does argument checking and is thus "safe" to use,
    but the following, which work on all HP48/49/50
    (including HP48S[X]/G[X]),
    directly invoke the same internal functions,
    bypassing argument checking,
    and thus may cause a crash or memory loss
    if lacking the proper object (and type) to work on:

    #5B15h SYSEVAL @ "string" -> 'id' a/k/a $>ID

    #5BE9h SYSEVAL @ 'id' -> "string" a/k/a ID>$

    Safer versions in UserRPL for all HP48/49/50:

    "'" SWAP + STR\-> @ can create only "legal" variable names

    "" + @ converts any variable name to a string

    One can use the internal $>ID to convert even an empty string ""
    to a null (illegal) variable name: ''

    When the VAR (variables) menu is being displayed,
    a null name causes the menu to abruptly terminate,
    somewhat like a "newline" inserted into a line of text;
    the original reason for this designed behavior
    was to conceal one single "hidden directory"
    (used by the internal calculator OS)
    at the end of the HOME directory.

    However, once "hackers" discovered this fact,
    they began designing "variable hiders,"
    which store a null-named object into any directory,
    thus concealing all of the subsequent variables
    (only from appearing in the VAR menu, since
    'xyz' RCL/STO/PURGE/EVAL continue to work normally anyway).

    Besides being a bit awkward to maintain,
    directories containing null variables
    also introduce one danger, which is that
    it becomes possible to purge an "apparently empty" directory
    which really isn't empty, and if it then so happens
    that any of its variables were "in use" at that time,
    the next "garbage collection" may wipe out all user memory.

    That's "all the news which fits" (in the time available to write it),
    so have a good day!

    [r->] [OFF]

  9. Re: Static vars without using a var? [PSTO, PRCL, PRUN, Hidden, etc.]

    On Thu, 24 Jul 2008 06:50:46 -0500, Irl thoughtfully wrote:

    > A reminder: when a program is called from within a given directory,
    > it can only store variables in that directory.


    To store into any path, you can use:

    "object" 'name' { path of another directory }
    { EVAL STO } PATH + EVAL

    If you will be doing this frequently,
    you might make the second line into a callable program:

    @ Perform STO into a path provided on level 1:
    \<< { EVAL STO } PATH + EVAL \>> HOME 'PSTO' STO

    It's even easier to recall a variable from any path:

    'name' { path of another directory } SWAP + RCL

    The 'PSTO' program will work even if the { path } argument
    does not start like this: { HOME dir1 ... }

    However, SWAP + RCL works only for paths starting with HOME;
    you could eliminate that restriction (accepting UPDIR
    or even just any sequence of one or more directory names)
    by doing the same thing as in the STO case, e.g.:

    @ Perform RCL from a path provided on level 1:
    \<< { EVAL RCL } PATH + EVAL \>> HOME 'PRCL' STO

    I suppose we could also add something for PURGE:

    @ Perform PURGE from a path provided on level 1:
    \<< { EVAL PURGE } PATH + EVAL \>> HOME 'PPURG' STO

    Gee, this is starting to become somewhat repetitive,
    so perhaps we could generalize even further:

    @ args { any commands } { path }
    \<< { EVAL EVAL } PATH + EVAL \>> HOME 'PRUN' STO

    @ Now we can simplify the original functions:
    \<< { STO } SWAP PRUN \>> HOME 'PSTO' STO
    \<< { RCL } SWAP PRUN \>> HOME 'PRCL' STO
    \<< { PURGE } SWAP PRUN \>> HOME 'PPURG' STO

    If any of these commands results in an error,
    then we remain in the other directory;
    it's left as an exercise to adjust PRUN, if desired,
    to return to the original path, even after an error.

    For running commands in the system "Hidden directory,"
    we can instead just use a 'Hidden' function,
    which acts on the next object following:

    \<< RCLF SIZE 3 < #64037h #370C3h IFTE
    #6FD1h SYSEVAL SYSEVAL \>> HOME 'Hidden' STO

    Then use:

    Hidden STO
    Hidden RCL
    Hidden PURGE
    (Etc.)
    Hidden HALT @ now you can inspect the hidden directory

    Error trapping (and return to original directory) for 'Hidden'
    is already built in, courtesy of the calculator OS.

    All of the above work on any HP48/49/50 (even HP48S[X]/G[X])

    Make a back up before using 'Hidden'
    (just as for any use of SYSEVAL,
    where any wrong address or input might lead to big trouble).

    Also, do not store into, purge, or re-ORDER
    any of these "system" variables in the hidden directory:

    { Alarms UserKeys UserKeys.CRC }

    [r->] [OFF]

  10. Re: Static vars without using a var? [PSTO, PRCL, PRUN, Hidden, etc.]

    John H Meyers wrote:
    > On Thu, 24 Jul 2008 06:50:46 -0500, Irl thoughtfully wrote:
    >
    >> A reminder: when a program is called from within a given directory,
    >> it can only store variables in that directory.

    >
    > To store into any path, you can use:
    >
    > "object" 'name' { path of another directory }
    > { EVAL STO } PATH + EVAL


    or

    "object" 'name' { path of another directory } PUSH EVAL STO POP

    Regards,
    --
    Bruce Horrocks
    Surrey
    England
    (bruce at scorecrow dot com)

  11. Re: Static vars without using a var? [PSTO, PRCL, PRUN, Hidden, etc.]

    On Thu, 24 Jul 2008 17:31:45 -0500, Bruce Horrocks thoughtfully wrote:

    > "object" 'name' { path of another directory } PUSH EVAL STO POP


    PUSH and POP (save and restore directory path and flags)
    are available on all HP49/50 series,
    but not on HP48S[X]/G[X]
    (previous suggestions work on all HP48/49/50).

    They also add a bit of extra execution time
    (the things which are saved and restored
    are actually saved in a permanent list named 'ENVSTACK'
    within 'CASDIR' rather than just in "scratch memory"),
    although this may not be significant to everyone.

    One helpful thing is that if an error occurs,
    you can then just manually POP to go back.

    The use of 'Hidden' (store/recall in Hidden directory)
    may be the fastest and easiest of all the alternatives,
    due in part to that directory's memory location,
    which may be why the internal operating system uses its own
    Hidden directory for all its own variable storage needs,
    as well as to the efficient automatic environment restoration
    upon any errors.

    Thanks again for noting PUSH and POP.

    [r->] [OFF]

  12. Re: Static vars without using a var? [S~N for all HP48/49/50, variable "hiding"]

    "John H Meyers" wrote in message
    newsp.ues6fesqnn735j@miu.edu...
    X
    > but the following, which work on all HP48/49/50
    > (including HP48S[X]/G[X]),
    > directly invoke the same internal functions,
    > bypassing argument checking,
    > and thus may cause a crash or memory loss
    > if lacking the proper object (and type) to work on:
    >
    > #5B15h SYSEVAL @ "string" -> 'id' a/k/a $>ID


    using this wrap it's a little safer
    IF DUP TYPE 2. == THEN ... END @ 2. = "string"

    > #5BE9h SYSEVAL @ 'id' -> "string" a/k/a ID>$


    using this wrap it's a little safer
    IF DUP TYPE 6. == THEN ... END @ 6. = 'GlobalName'

    > Safer versions in UserRPL for all HP48/49/50:
    >
    > "'" SWAP + STR\-> @ can create only "legal" variable names
    >
    > "" + @ converts any variable name to a string

    X
    [<-|] [CONT]



  13. Re: Static vars without using a var? [PSTO, PRCL, PRUN, Hidden, etc.]

    Hi all,

    Thank you all very much for such useful information - sorry to have been
    slow in saying this but I've been side-tracked elsewhere with limited time
    and development was on hold.

    There is a lot to take in here so bear with me whilst I digest it all and
    I'll follow up with my decisions. Meantime, thanks again for such great help
    from everyone

    Regards,

    Mark

    "John H Meyers" wrote in message
    newsp.uetk2fotnn735j@miu.edu...
    > On Thu, 24 Jul 2008 17:31:45 -0500, Bruce Horrocks thoughtfully wrote:
    >
    > > "object" 'name' { path of another directory } PUSH EVAL STO POP

    >
    > PUSH and POP (save and restore directory path and flags)
    > are available on all HP49/50 series,
    > but not on HP48S[X]/G[X]
    > (previous suggestions work on all HP48/49/50).
    >
    > They also add a bit of extra execution time
    > (the things which are saved and restored
    > are actually saved in a permanent list named 'ENVSTACK'
    > within 'CASDIR' rather than just in "scratch memory"),
    > although this may not be significant to everyone.
    >
    > One helpful thing is that if an error occurs,
    > you can then just manually POP to go back.
    >
    > The use of 'Hidden' (store/recall in Hidden directory)
    > may be the fastest and easiest of all the alternatives,
    > due in part to that directory's memory location,
    > which may be why the internal operating system uses its own
    > Hidden directory for all its own variable storage needs,
    > as well as to the efficient automatic environment restoration
    > upon any errors.
    >
    > Thanks again for noting PUSH and POP.
    >
    > [r->] [OFF]




  14. Re: Static vars without using a var? [PSTO, PRCL, PRUN, Hidden, etc.]

    The use of a directory for storing the values is currently the front-runner
    (for various reasons).

    I had been thinking about this and the way I was going to deal with it is:

    The storage dir will always be in home - that is fixed so the path is {HOME
    MYDIR}

    Now, the way I want the program to work is for it to return to the stack and
    then be called again from a TMENU option. Each main function within the
    program will generate a TMENU with a set of further sub-functions with code
    in the TMENU that sets up and calls the routines required. In a way, it is a
    bit like adding new menus to the built in menus. As the user is returned to
    the stack whilst the program is still active, the user can change dirs at
    any point so I can't rely on any path except the storage dir.

    Therefore, each time a variable needs to be saved, there is a wrapper which
    is:

    PATH @ Preserve the current path
    {HOME MYDIR} EVAL @ Move to the storage dir
    @ -- code for storing variables goes here and when done, the next item on
    the stack is the list from the earlier PATH --
    EVAL @ Eval the path list to return to original dir.

    Selected variables are only stored when a particular subfunction exits and I
    use locals for everything else so the overhead of the wrapper code is small.

    That's OK isn't it? I just have a nagging feeling I might have simplified it
    too far!

    Mark



  15. Re: Static vars without using a var? [S~N for all HP48/49/50, variable "hiding"]

    Thanks all for explaining the S~N business. It was completely new to me as
    I'm developing on a 48G and although I got a 49G a couple of days ago, I
    haven't had time to delve into its more specific features. About the only
    thing I've worked out on the 49G so far is that I hate the keyboard and it
    seems considerably slower than a 48G. Otherwise, it looks like a very
    promising machine in a nasty shell. I'll have to get a 50 soon...

    Mark



    "Veli-Pekka Nousiainen" wrote in
    message news:J8gik.38621$_03.17748@reader1.news.saunalahti .fi...
    > "John H Meyers" wrote in message
    > newsp.ues6fesqnn735j@miu.edu...
    > X
    > > but the following, which work on all HP48/49/50
    > > (including HP48S[X]/G[X]),
    > > directly invoke the same internal functions,
    > > bypassing argument checking,
    > > and thus may cause a crash or memory loss
    > > if lacking the proper object (and type) to work on:
    > >
    > > #5B15h SYSEVAL @ "string" -> 'id' a/k/a $>ID

    >
    > using this wrap it's a little safer
    > IF DUP TYPE 2. == THEN ... END @ 2. = "string"
    >
    > > #5BE9h SYSEVAL @ 'id' -> "string" a/k/a ID>$

    >
    > using this wrap it's a little safer
    > IF DUP TYPE 6. == THEN ... END @ 6. = 'GlobalName'
    >
    > > Safer versions in UserRPL for all HP48/49/50:
    > >
    > > "'" SWAP + STR\-> @ can create only "legal" variable names
    > >
    > > "" + @ converts any variable name to a string

    > X
    > [<-|] [CONT]
    >
    >




  16. Re: Static vars without using a var? [PSTO, PRCL, PRUN, Hidden, etc.]

    Mark Edmonds wrote:

    > That's OK isn't it? I just have a nagging feeling I might have simplified it
    > too far!


    That's fine. TMENU is a great way to construct programs and very
    in-keeping with the style of the calculator.

    Regards,
    --
    Bruce Horrocks
    Surrey
    England
    (bruce at scorecrow dot com)

  17. Re: Static vars without using a var? [PSTO, PRCL, PRUN, Hidden, etc.]

    Yes, agreed but there is one limitation I've just found - local variables.
    Difficult to describe but if you have a program that uses locals and creates
    a TMENU with code objects in the menu, the menu code cannot reference locals
    in the main program. So how do you pass a value to a TMENU program object
    without using a saved variable... hmmm... haven't sussed that one yet.

    Mark

    "Bruce Horrocks" <07.013@scorecrow.com> wrote in message
    news:6f3e6eF99plcU1@mid.individual.net...
    > Mark Edmonds wrote:
    >
    > > That's OK isn't it? I just have a nagging feeling I might have

    simplified it
    > > too far!

    >
    > That's fine. TMENU is a great way to construct programs and very
    > in-keeping with the style of the calculator.
    >
    > Regards,
    > --
    > Bruce Horrocks
    > Surrey
    > England
    > (bruce at scorecrow dot com)




  18. Re: Static vars without using a var? [PSTO, PRCL, PRUN, Hidden, etc.]

    On Sat, 26 Jul 2008 15:28:34 -0500, Mark Edmonds wrote:

    > each time a variable needs to be saved,
    > there is a wrapper which is:
    > PATH @ Preserve the current path
    > {HOME MYDIR} EVAL @ Move to the storage dir
    > @ -- code for storing variables goes here and when done,
    > the next item on the stack is the list from the earlier PATH --
    > EVAL @ Eval the path list to return to original dir.


    Where are the variable values that are to be stored
    (and their names)?

    Are they on the stack, above the "return to" path?

    The various other previous suggestions
    avoid ever leaving the "return to" path on the stack:
    PUSH (HP49/50 series) saves it in the 'ENVSTACK' list in 'CASDIR',
    while my earlier suggestions (for all HP48/49/50)
    transfer it to the unseen "return stack" (program execution stack)
    in temporary memory, which I think is a faster alternative.

    If there are multiple items to store,
    it might be more efficient to change paths only once,
    storing all of the variables at once.

    HP48 and HP49/50 "G" series calculators
    can store multiple variables at once using lists,
    e.g. { 1 2 3 } { a b c } STO

    As to temporary ("local") variables, a TMENU
    can reference any temporary variables that already exist
    in programs which invoked TMENU.

    You can use a HALT in a program,
    after it first creates local variables
    and then performs TMENU to set up a menu, e.g.:

    \<< 123456 \-> xyz
    \<< { xyz {"EXIT" \<< 0 MENU CONT \>> } } TMENU HALT \>> \>>

    Now 'xyz' is a local variable in the menu;
    when you press EXIT, the menu (and variable) both disappear.

    There is also a 48/49/50 G-series trick
    which allows separately compiled programs
    to reference the same local variables;
    the trick is simply that all variable names
    which begin with one particular special character
    are automatically compiled as "local" names (object type 7),
    regardless of their context.

    The special character is a left-arrow '\<-'
    typed via calculator keyboard as Alpha Right-shift Left-arrow
    (left cursor key), also produced by 142 CHR.

    It is still necessary for some program to create the variable
    before another program can use it, e.g.:

    \<< 123456 \-> \<-xyz \<< ... PROG2 ... \>> \>> 'PROG1' STO

    \<< \<-xyz SQ \>> 'PROG2' STO

    Now PROG1 can call PROG2, and PROG2 can use PROG1's local variable.

    Of course, a completely different approach might be for a program
    to first go to a "private" directory where its variables reside,
    then do everything with ordinary, "global" variables,
    then return to the original directory after it finishes.

    ---

    Our minds can think of many ways of accomplishing a thing;
    if we have time, as well as experience, we can evaluate well,
    and judge correctly what will best serve, in the long run,
    before rushing to act;
    otherwise we bomb or invade first, on ignorant pretexts,
    then realize only much later what we could or should have done,
    had we grown up and learned first
    how to live in greater fullness of life,
    and how to deliver that same pre-emptive blessing to others,
    so that they would have done the same.

    -[ ]-

  19. Re: Static vars without using a var? [PSTO, PRCL, PRUN, Hidden, etc.]

    Mark Edmonds wrote:
    > Yes, agreed but there is one limitation I've just found - local variables.
    > Difficult to describe but if you have a program that uses locals and creates
    > a TMENU with code objects in the menu, the menu code cannot reference locals
    > in the main program. So how do you pass a value to a TMENU program object
    > without using a saved variable... hmmm... haven't sussed that one yet.


    See John H. Meyers' next post about the use of \<- (back arrow) to
    create local variables that are shared amongst more than one program.

    Regards,
    --
    Bruce Horrocks
    Surrey
    England
    (bruce at scorecrow dot com)

  20. Re: Static vars without using a var? [PSTO, PRCL, PRUN, Hidden, etc.]

    In article <6f6ofcFa1a4nU1@mid.individual.net>,
    Bruce Horrocks <07.013@scorecrow.com> wrote:

    > Mark Edmonds wrote:
    > > Yes, agreed but there is one limitation I've just found - local variables.
    > > Difficult to describe but if you have a program that uses locals and creates
    > > a TMENU with code objects in the menu, the menu code cannot reference locals
    > > in the main program. So how do you pass a value to a TMENU program object
    > > without using a saved variable... hmmm... haven't sussed that one yet.

    >
    > See John H. Meyers' next post about the use of \<- (back arrow) to
    > create local variables that are shared amongst more than one program.
    >
    > Regards,


    Note however that as I understand it those shareable local variable only
    exist while the program that creates them is running, so that crating
    program must be halted with those variables still in existence and only
    ended after those variables are done with.

+ Reply to Thread
Page 1 of 2 1 2 LastLast