#189 Destructor in MSIE running at the wrong time

pending
nobody
WSH (6)
5
2012-08-14
2006-09-29
No

ooRexx objects created in MSIE will have their
destructors run at the wrong time.

Speculation on: AFAIK the Rexx state is "swapped out"
whenever the border/context of a script block (ie. the
respective SCRIPT element) is left. Whenever a script
block is re-entered, the state of ooRexx is "swapped
in" and "swapped-out" again upon leaving it.

It seems that the UNINIT method gets (wrongly) invoked
at the very first time a script block is left for any
object that got created in that invocation of the
script block.

Desired resolution: only run the destructor at the time
when no more references are available to an object.

Discussion

  • Rony G. Flatscher

    Contains test script to demo bug.

     
  • Mark Miesfeld

    Mark Miesfeld - 2006-11-28

    Logged In: YES
    user_id=191588
    Originator: NO

    Rony,

    This bug seems, to me, to be related to bug # 1604495. I am going to work on both of them.

    Would you assign this to me? Thanks.

    --
    Mark Miesfeld

     
  • Rick McGuire

    Rick McGuire - 2006-11-28

    Logged In: YES
    user_id=1125291
    Originator: NO

    I suspect this cannot be fixed until the 4.0 timeframe, since the facilities available for accessing variable values are still all string based, which will make it difficult to keep live objects around. This sounds like a facility required in the new ScriptContext APIs.

    Rick

     
  • Mark Miesfeld

    Mark Miesfeld - 2006-11-28

    Logged In: YES
    user_id=191588
    Originator: NO

    When I first looked at the 2 bugs, I did think that they might not be fixable until 4.0. But, it gives me a good starting point to work on orxscrpt.

    I've got the DLL built with logging turned on and these simple examples are a good place to trace the calls made into the script engine.

     
  • Mark Miesfeld

    Mark Miesfeld - 2006-11-28

    Logged In: YES
    user_id=191588
    Originator: NO

    When I first looked at the 2 bugs, I did think that they might not be fixable until 4.0. But, it gives me a good starting point to work on orxscrpt.

    I've got the DLL built with logging turned on and these simple examples are a good place to trace the calls made into the script engine.

     
  • Mark Miesfeld

    Mark Miesfeld - 2006-11-28

    Logged In: YES
    user_id=191588
    Originator: NO

    When I first looked at the 2 bugs, I did think that they might not be fixable until 4.0. But, it gives me a good starting point to work on orxscrpt.

    I've got the DLL built with logging turned on and these simple examples are a good place to trace the calls made into the script engine.

     
  • Rony G. Flatscher

    Logged In: YES
    user_id=662126
    Originator: YES

    Just to add to the discussion (and also the need for 4.0): a while ago I wrote a little TCP/IP socket application using MSIE as the GUI. The sockets are created and maintend by ooRexx.

    Each time a Rexx routine gets invoked and uses a previously established socket connection, that connection has to be re-established as it got lost in the meantime. With 4.0, having the objects live all the time, should alleviate this problem as well.

     
  • Philippe Majerus

    Logged In: YES
    user_id=1655860
    Originator: NO

    Just a quick note, I was thinking again about the problem of keeping live objects...
    Tests performed with ooRexx 3.1.2 on Windows Vista with Majerus.net Active Shell 1.0.2007.16.

    Testing with RexxTry (rexxtry.rex):
    wsh = .OLEObject~new("WScript.Shell") [Enter, gets executed fine]
    wsh~popup("Hello ooRexx in RexxTry") [Enter, gets executed fine]
    This shows that within RexxTry, the ooRexx engine can be used to execute statements on the fly and keep the engine state between them.

    Using the Active Scripting interface, within MAS:
    wsh = .OLEObject~new("WScript.Shell"); wsh~popup("Hello ooRex in MAS") [Enter, gets executed fine]
    wsh~popup("Hello ooRex in MAS 2") [Enter, error: object WSH was lost]

    It seems to me the ooRex 3.x engine is able to keep the object alive while executing, as it is working in RexxTry. A guess would be that RexxTry is keeping the same engine running and sends each line to the same parser, while the Active Scripting version is creating an new engine and parser and treat each line as a separate script, thus losing all the state between them.

     
  • Mark Miesfeld

    Mark Miesfeld - 2010-08-17

    Windows Scripting Host (WSH) has been temporarily disabled in ooRexx 4.0.0. The WSH implementation code is not compatible with the refactored interpreter and needs to be completely rewritten. The old code used undocemented, unsafe, APIs. Those APIs no longer exist.

    The WSH bugs are bugs in the old code. The old code is not going to be used, so technically, the bugs are not going to be fixed.

    This bug will put into the postponed state and used to ensure that this type of bug does not exist in the re-written WSH support. At that time it will be closed.

     


Anonymous

Cancel  Add attachments





Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks