From: SourceForge.net <no...@so...> - 2008-08-15 19:56:07
|
Bugs item #2053673, was opened at 2008-08-15 19:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2053673&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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: "The NIL object" from .OLEObject~getobject? Initial Comment: Mark requested I open a problem report on this issue. I am getting a NIL object returned from .OLEObject most/some of the time when I try to create an access from a concurrent method. I am running on Windows XP Pro SP2 with an AMD Athlon XP 2400+ processor. The OS has all but the most recent (last month) updates on it. My ooREXX is Version 3.2.0. I don't have access to my SourceForge account for now, trying to reclaim it. You can contact me at bob...@rr... Below is a sample ooREXX program that hopefully shows the problem. The problem for me is about 60% of the time on my systems. If you remove the 1st .OLEobject~getobject statement or the "reply" statement, it works 100% of the time. Bob Jewett OS/2 User! ---------- CLIP -------- /* The next stmt needed to setup failure */ .OLEObject~getobject("winmgmts:\\.\root\cimv2") .thread~New ::REQUIRES "winsystm.cls" ::CLASS "thread" ::METHOD "init" reply -- If I remove this statement, it works! activeX = .OLEObject~getobject("winmgmts:\\.\root\cimv2") say activeX -- Why does this say "The NIL object" most of the time? ---------------------------- Bob Jewett, OS/2 User! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2053673&group_id=119701 |
From: SourceForge.net <no...@so...> - 2008-09-02 14:41:33
|
Bugs item #2053673, was opened at 2008-08-15 12:56 Message generated for change (Comment added) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2053673&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: Classes Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: "The NIL object" from .OLEObject~getobject? Initial Comment: Mark requested I open a problem report on this issue. I am getting a NIL object returned from .OLEObject most/some of the time when I try to create an access from a concurrent method. I am running on Windows XP Pro SP2 with an AMD Athlon XP 2400+ processor. The OS has all but the most recent (last month) updates on it. My ooREXX is Version 3.2.0. I don't have access to my SourceForge account for now, trying to reclaim it. You can contact me at bob...@rr... Below is a sample ooREXX program that hopefully shows the problem. The problem for me is about 60% of the time on my systems. If you remove the 1st .OLEobject~getobject statement or the "reply" statement, it works 100% of the time. Bob Jewett OS/2 User! ---------- CLIP -------- /* The next stmt needed to setup failure */ .OLEObject~getobject("winmgmts:\\.\root\cimv2") .thread~New ::REQUIRES "winsystm.cls" ::CLASS "thread" ::METHOD "init" reply -- If I remove this statement, it works! activeX = .OLEObject~getobject("winmgmts:\\.\root\cimv2") say activeX -- Why does this say "The NIL object" most of the time? ---------------------------- Bob Jewett, OS/2 User! ---------------------------------------------------------------------- >Comment By: Mark Miesfeld (miesfeld) Date: 2008-09-02 07:41 Message: Logged In: YES user_id=191588 Originator: NO The problem demonstrated by the example is inherent in the way OLEObject is designed. The COM library needs to be initialized for each apartment that calls COM functions. OLEObject only initializes the COM library on the first apartment that an OLEObject is instantiated in. In the example program, the COM library is initialized during the fist invocation of getObject(). In the init() method of the 'Thread' class, when the early reply is used, the second invocation of getObject() runs in a different apartment. Since the COM library is not initialized for that apartment, the call to BindToObject() fails. (Actually it might be the call to MkParseDisplayName() that fails. It was a couple of weeks ago that I looked at this.) If I put in some temporary code to initialize the COM library in the second apartment, then everything works as expected. Since we already have a lot to do to get the next release out the door, I don't intend to make any changes here for the next release and this will probably have to wait until later. Just wanted to jot down some notes so that I remember what I did on this and let Bob know that it is not forgotten. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2053673&group_id=119701 |
From: SourceForge.net <no...@so...> - 2008-10-08 00:37:24
|
Bugs item #2053673, was opened at 2008-08-15 14:56 Message generated for change (Comment added) made by bobjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2053673&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: Classes Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: "The NIL object" from .OLEObject~getobject? Initial Comment: Mark requested I open a problem report on this issue. I am getting a NIL object returned from .OLEObject most/some of the time when I try to create an access from a concurrent method. I am running on Windows XP Pro SP2 with an AMD Athlon XP 2400+ processor. The OS has all but the most recent (last month) updates on it. My ooREXX is Version 3.2.0. I don't have access to my SourceForge account for now, trying to reclaim it. You can contact me at bob...@rr... Below is a sample ooREXX program that hopefully shows the problem. The problem for me is about 60% of the time on my systems. If you remove the 1st .OLEobject~getobject statement or the "reply" statement, it works 100% of the time. Bob Jewett OS/2 User! ---------- CLIP -------- /* The next stmt needed to setup failure */ .OLEObject~getobject("winmgmts:\\.\root\cimv2") .thread~New ::REQUIRES "winsystm.cls" ::CLASS "thread" ::METHOD "init" reply -- If I remove this statement, it works! activeX = .OLEObject~getobject("winmgmts:\\.\root\cimv2") say activeX -- Why does this say "The NIL object" most of the time? ---------------------------- Bob Jewett, OS/2 User! ---------------------------------------------------------------------- Comment By: Bob (bobjewett) Date: 2008-10-07 19:37 Message: Mike, Thanks for the followup. Would it be possible to fix this in 4.0.1? Bob Jewett OS/2 User ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2008-09-02 09:41 Message: Logged In: YES user_id=191588 Originator: NO The problem demonstrated by the example is inherent in the way OLEObject is designed. The COM library needs to be initialized for each apartment that calls COM functions. OLEObject only initializes the COM library on the first apartment that an OLEObject is instantiated in. In the example program, the COM library is initialized during the fist invocation of getObject(). In the init() method of the 'Thread' class, when the early reply is used, the second invocation of getObject() runs in a different apartment. Since the COM library is not initialized for that apartment, the call to BindToObject() fails. (Actually it might be the call to MkParseDisplayName() that fails. It was a couple of weeks ago that I looked at this.) If I put in some temporary code to initialize the COM library in the second apartment, then everything works as expected. Since we already have a lot to do to get the next release out the door, I don't intend to make any changes here for the next release and this will probably have to wait until later. Just wanted to jot down some notes so that I remember what I did on this and let Bob know that it is not forgotten. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2053673&group_id=119701 |