Topic
  • 7 replies
  • Latest Post - ‏2013-02-07T18:08:31Z by llandale
Gedinfo
Gedinfo
87 Posts

Pinned topic How do I handle the "current" of this situation?

‏2013-02-06T17:01:11Z |
I open a module, then run a script which displays a dialog box, which depends on data from another module(this module is opened, data is read in, then the module gets closed).
Therefore, when I get to the part where I test if the original module is not null, since the original module is no longer current, the module that I thought was current is now null.

I have tried Louie's library function fSetCurrMod(), but this does not seem to help.

Any suggestions on how to resolve this?

Thank you.
Updated on 2013-02-07T18:08:31Z at 2013-02-07T18:08:31Z by llandale
  • SystemAdmin
    SystemAdmin
    3180 Posts

    Re: How do I handle the "current" of this situation?

    ‏2013-02-06T17:12:12Z  
    Could you just use
    current = m
    where m is the original current module?

    Greg
  • llandale
    llandale
    3010 Posts

    Re: How do I handle the "current" of this situation?

    ‏2013-02-06T17:19:34Z  
    Make this a global variable:
    • Module mHome
    If the script runs from the Explorer then:
    • mHome = read(Name, false, true)
    Otherwise if the script runs from that open module:
    • mHome = current

    Now if the module mHome gets closed, unfortunately variable "mHome" remains non-null but effectively corrupted. So you may want do this globally:
    • string NameHomeFull = fullName(mHome)
    In your callbacks wondering if mHome was closed while the dialog was open, do this:
    • module m = module(NameHomeFull)
    • if (null m) then Home was closed. Abort and Clean up mess
    • elseif(m != mHome) then Home was closed and re-opened. DANGER 'Object' et tal handles corrupted. Abort and clean up mess

    fSetCurrMod is useful only for those perms that require a "current" module. Otherwise I advise you to stay away from using "current".

    -Louie
  • Gedinfo
    Gedinfo
    87 Posts

    Re: How do I handle the "current" of this situation?

    ‏2013-02-06T19:17:22Z  
    • llandale
    • ‏2013-02-06T17:19:34Z
    Make this a global variable:
    • Module mHome
    If the script runs from the Explorer then:
    • mHome = read(Name, false, true)
    Otherwise if the script runs from that open module:
    • mHome = current

    Now if the module mHome gets closed, unfortunately variable "mHome" remains non-null but effectively corrupted. So you may want do this globally:
    • string NameHomeFull = fullName(mHome)
    In your callbacks wondering if mHome was closed while the dialog was open, do this:
    • module m = module(NameHomeFull)
    • if (null m) then Home was closed. Abort and Clean up mess
    • elseif(m != mHome) then Home was closed and re-opened. DANGER 'Object' et tal handles corrupted. Abort and clean up mess

    fSetCurrMod is useful only for those perms that require a "current" module. Otherwise I advise you to stay away from using "current".

    -Louie
    I am attaching my code and the module that gets read in that the dialog depends on will be in the second post.

    TestFunction() shows module m as null, even though the original module that was opened and the script run on is still open.

    Attachments

  • Gedinfo
    Gedinfo
    87 Posts

    Re: How do I handle the "current" of this situation?

    ‏2013-02-06T19:18:59Z  
    • Gedinfo
    • ‏2013-02-06T19:17:22Z
    I am attaching my code and the module that gets read in that the dialog depends on will be in the second post.

    TestFunction() shows module m as null, even though the original module that was opened and the script run on is still open.
    The module that the dialog depends on is now attached.
    This is an archive module.
  • llandale
    llandale
    3010 Posts

    Re: How do I handle the "current" of this situation?

    ‏2013-02-06T20:18:43Z  
    • Gedinfo
    • ‏2013-02-06T19:17:22Z
    I am attaching my code and the module that gets read in that the dialog depends on will be in the second post.

    TestFunction() shows module m as null, even though the original module that was opened and the script run on is still open.
    I'm not going to look at your module. Are you running this script from an open module or from the Explorer?

    I see ReadLinksetFile() will open that module, and will close it even if it was already open. Since that function is called via FillOldLinksetData(), that module will close when you run the script. If you are running from that module then there is no "current" module.

    I'm suggesting you remember which module you are dealing with using a "Module" handle at the program level; not inside some function.

    -Louie
  • Gedinfo
    Gedinfo
    87 Posts

    Re: How do I handle the "current" of this situation?

    ‏2013-02-06T21:27:56Z  
    • llandale
    • ‏2013-02-06T20:18:43Z
    I'm not going to look at your module. Are you running this script from an open module or from the Explorer?

    I see ReadLinksetFile() will open that module, and will close it even if it was already open. Since that function is called via FillOldLinksetData(), that module will close when you run the script. If you are running from that module then there is no "current" module.

    I'm suggesting you remember which module you are dealing with using a "Module" handle at the program level; not inside some function.

    -Louie
    This is run on an open module, not from the explorer.

    I open up module A, then open up module B to read in the configuration data that the dialog requires, then close module B, to hopefully have module A available for the rest of the script.

    I do not understand your comment of
    "will open that module, and will close it even if it was already open".

    The close only happens when a valid read occurs on module B.

    Not sure what you mean by program level. Does this mean that Module A should be a global?
  • llandale
    llandale
    3010 Posts

    Re: How do I handle the "current" of this situation?

    ‏2013-02-07T18:08:31Z  
    • Gedinfo
    • ‏2013-02-06T21:27:56Z
    This is run on an open module, not from the explorer.

    I open up module A, then open up module B to read in the configuration data that the dialog requires, then close module B, to hopefully have module A available for the rest of the script.

    I do not understand your comment of
    "will open that module, and will close it even if it was already open".

    The close only happens when a valid read occurs on module B.

    Not sure what you mean by program level. Does this mean that Module A should be a global?
    Sorry if I use the wrong word; I mean variables declared as "global" to the program. I see you have
    • Module mInit
    declared globally and should be used for this purpose
    • Module mInit = current()
    • if ( null mInit){warningBox("run from open module"); halt}
    Function TestFunction() would then NOT declare "Module m" but would use "mInit"; although as I said checking for null is inadequate.

    -Louie

    Scripts that run from the explorer could have this instead:
    • if (!null mInit){warningBox("Do not run from open module"); halt}

    I've changed nomenclature for this module over the years, "Current", "Initial", "Original", but now is the "Home" module.