 |
Anaristos
Sorcerer
Joined: 17 Jul 2007
Posts: 821
Location: California
|
 Posted: Tue Jul 22, 2008 10:05 pm
CMUD 2.33 Problems with COM objects
|
This is probably occurring because CMUD 2.33 has closed some coding loopholes. However, I think it is worth reporting.
It seems that when the package is saved at session end, COM objects are saved just as other variables are and therefore when the session is again opened (the package is re-loaded), the COM objects "appear" to be initialized.
In versions prior to 2.33, this didn't pose a problem, %comcreate went on and set the variable as a brand new object. Not so, in the 2.33 version. If the variable is not pristine, the initialization of the object will fail.
What is puzzling is that this shouldn't matter because the initialization routine clears the variable and invokes %vartype:
| Code: |
<alias name="initsql" id="11271">
<value>comsql = ""
;;
#CALL %vartype( comsql, 8)
;;
#VAR comsql %comcreate( "Sqlite.ZMUD.WSC")
;;
#CALL %comset( comsql, CMUDFormat, 1)</value>
</alias>
|
However, it is definite that if the variable contains <COMobject> as its value when this routine executes, the initialization of the object will fail. This wasn't the case in previous versions. This routine has been running since 2.25 without a hitch.
Further, any attempt to use the variable as a COM object if its initial value is <COMobject> when initsql executes, will result in the variable being treated as a string variable (probably because the type is set to autotype, in spite of the call to %vartype). |
|
_________________
Sic itur ad astra. |
 |
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue Jul 22, 2008 10:15 pm
|
The "<COMObject>" value is just a placeholder string value so that when you use #VAR to examine your variables you can see that there is an object stored in the variable. So yes, when CMUD saves your session, it saves a string value of "<COMObject>" for your variable. There is no way to actually save the COM object itself across sessions...you need to recreate it.
I'm not sure why CMUD would care about this when assigning the COM object. Especially since, like you said, you already clear the variable and set it's type. Maybe you can try using #UNVAR to remove the variable before it is initialized.
But I haven't changed anything related to COM variables in a long time, so I can't think of any way that this behavior would have suddenly changed in 2.33.
Could someone else play with this and try to learn more about it? |
|
|
|
|
Anaristos
Sorcerer
Joined: 17 Jul 2007
Posts: 821
Location: California
|
Posted: Tue Jul 22, 2008 10:34 pm
|
Actually, I solved the problem by setting a default value to null. In fact, this is what prompted me to post. Since the variable has a default value, it is not saved at session's end and therefore the problem I described doesn't occur. This leads me to believe that the problem stems from something related to saved variables.
|
|
_________________
Sic itur ad astra. |
|
|
|
Anaristos
Sorcerer
Joined: 17 Jul 2007
Posts: 821
Location: California
|
Posted: Sat Aug 09, 2008 3:23 pm
|
This problem persists in CMUDPro 2.35. While the COM objects that were created before this problem started become initialized without any problems. New COM objects fail to initialize. Perhaps this is not a big deal. But I create these objects constantly. Spending 30 minutes to initialize each is becoming a bit over the top. The saving grace is that once I get it initialized once, then the problem goes away for that object.
|
|
_________________
Sic itur ad astra. |
|
|
|
|
|
|
