Menu
▾
▴
[Oorexx-bugs] [ oorexx-Bugs-1567599 ] Destructor in MSIE running at the wrong time
|
From: SourceForge.net <no...@so...> - 2010-08-17 04:26:32
|
Bugs item #1567599, was opened at 2006-09-29 03:03 Message generated for change (Settings changed) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=1567599&group_id=119701 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: WSH Group: None >Status: Pending >Resolution: Postponed Priority: 5 Private: No Submitted By: Rony G. Flatscher (orexx) >Assigned to: Nobody/Anonymous (nobody) Summary: Destructor in MSIE running at the wrong time Initial Comment: 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. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-08-16 21:26 Message: 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. ---------------------------------------------------------------------- Comment By: Philippe Majerus (phmajerus) Date: 2007-08-03 07:13 Message: 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. ---------------------------------------------------------------------- Comment By: Rony G. Flatscher (orexx) Date: 2006-11-28 08:10 Message: 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. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2006-11-28 08:01 Message: 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. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2006-11-28 07:59 Message: 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. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2006-11-28 07:49 Message: 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. ---------------------------------------------------------------------- Comment By: Rick McGuire (bigrixx) Date: 2006-11-28 07:29 Message: 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 ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2006-11-28 07:20 Message: 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=1567599&group_id=119701 |