Zugg Software :: View topic - [2.28] COM breaks when done from a module

SubAdmin Joined: 18 Nov 2001 Posts: 5182

This makes absolutely no sense, but appears to be a scoping issue.

Procedure
1. Launch CMud
2. Close Sessions Window (ESC)
3. Open Package Editor (CTRL-G)
4. Paste (CTRL-V)

Posted: Sat Jun 21, 2008 7:30 pm

This is confirmed.
Actually, I noticed this behavior in 2.18 and just assumed that COM objects had to be located in the session window class, which is where I keep them.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Hrm, I never noticed this problem with 2.18. I wasn't really actively testing with 2.20 through 2.27, so I have no idea when this bug was intorduced.

What I find most interesting about this bug, is that the line "$Index=%session.NumDirs" puts the correct value into Index. This means the bug stems from using a subsequently created COM object. If I had to guess when this bug was introduced I would say it was when the fix was made so that closing a window didn't destroy all COM objects.

Posted: Sun Jun 22, 2008 8:03 pm

By habit I try to put all elements pertaining to a routine in the same class. With this in mind, I created a class to contain COM objects and their associated scripts (open, check, repair, etc). The scripts addressing the objects didn't work until I moved them (the objects) to the session window class. I discovered this in the version in which you introduced the SQLite interface. Perhaps that version wasn't 2.18.

Posted: Mon Jun 23, 2008 5:03 pm

Does it only happen with %session? Can you try creating a "normal" COM variable via %comcreate for some other Windows object and try that?

The problem is that %session just points to a predefined COM interface for the current "window" object in CMUD. When you do this within a module, there isn't any "window" object to attach to this variable. So it would be undefined.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I had to move both of these function into my main window to do any of the scripting work I was aimed at. These both belong in my global Toolbox package, and the variables MapCon and WidgetsComTemp that they use are still in my Toolbox.

Posted: Mon Jun 23, 2008 9:19 pm

Posted: Mon Jun 23, 2008 10:51 pm

I pointed out before that COM objects don't work unless placed in the window session class. I don't work with just one object, currently I have 7 objects that are operational and they all have to reside at the root. Perhaps this has nothing to do with the problem.

EDIT: However, in test operations where I use more than one package, I have no problem using the objects across packages (as long as the package containing the objects has them at the root).

Posted: Mon Jun 23, 2008 11:08 pm

You need to be very careful when you talk about things being in the root. Nothing except modules and windows should ever be in the root of a package - if that's really what you mean, something's gone wrong (as well as going right). If that's not what you meant, what did you?

Posted: Tue Jun 24, 2008 12:57 am

We've gone through this before. You don't seem to understand what the root is. The root is the window session, from it all other classes stem. That is why I call it the root. 'Session window' is too long a name for me to use each time I want to refer to it. If it has another name, let me know. But when I look at the compiled script, if it is in what I call the root, it will say <class packagename>. Anywhere else in the world I would be understood when I speak of the root class, I don't see what the problem is here. Another way to look at it is the class where a setting will default to, if no default is specified. If you have an empty package and you create a setting, that setting will go to the root. I hope this explains what I mean by "root". If it has a technical name, please inform me. Anyone who has ever worked with trees should have no problem understanding what I mean.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I guess I will have to dig through my archives for all the details on which version this first occured in.

The short version of the #VAR syntax not working is that #VAR name {COM type thing} seems to actually put "<COM Object>" into the variable instead of whatever low level reference it used to. It wasn't that much of a bother to change it to name=COM type thing since I was only changing a few functions that were responsible for the low level references.

I really wasn't concerned that much since #VAR was setting the type for the variable to String(expanded), and it was logical to other such uses of the same syntax. I personally would like it better, especially when I have already set the variable type; but it is a minor compatibility item. The specific procedure to demonstrate it is:
1. Launch CMud
2. Close Sessions Window (ESC)
3. Enter at the command line

Enchanter Joined: 11 Feb 2003 Posts: 511 Location: USA

Posted: Tue Jun 24, 2008 2:04 pm

Yes, my point's simply that the real root (meaning "having nothing as its parent") is only for modules and windows. If you start calling two things the root - the real root of the package and the session window - then it can get confusing. I was only asking because I didn't know if you meant the real root or something else.

Posted: Tue Jun 24, 2008 7:08 pm

Take a look at the Terminology section of the help file. In our official terms, "root" is the same as the "top level" of the settings. The "root" is the top of the package and it contains only windows and modules. By default, CMUD creates the first module/window in a package with the same name as the package file itself, which I know might be confusing.

Your window is *not* the root. The reason your terminology can be confusing to advanced users is that a single package can contain multiple windows and modules. The "root" is the top level of the tree that contains these windows and modules. The actual "node" for the root of the tree is not displayed in the settings editor, so that might also be confusing. The root node is always expanded to show the windows/modules within it.

So, if you mean the top-level of your session window, then you should say that. Don't confuse it with the "root" of the package itself. If you ever see a setting such as a class folder, alias, trigger, etc at the same level in the tree as a window/module, then your package is corrupted.

Anyway, back to the problem from the original post....

I will look into the #VAR problem. When you store a COM object in a variable, the #VAR command will display the contents as <COM Object>, but it shouldn't be using this "string" as the actual value of the variable. But I was able to reproduce the bug with the example that you gave, so it's definitely something I'll try to fix.

The problem with %session stems from how it worked in zMUD where each session only had a single primary window and child windows were treated specially. In CMUD, each window has it's own %session object, and some functions (like SendStr) use this to determine which window to send text to. However, when accessing the Aliases, Variables, etc you are actually accessing the *global* list of all settings for all windows/modules. So, for example, NumVars will display the total number of variables, not just the variables stored within the specific window.

CMUD really needs a new COM API to handle multiple windows/modules properly and to properly handle the new scoping rules. I can certainly see many cases where the COM API won't exactly match how scoping is handled in the rest of CMUD. Also, using %session within a module (which doesn't have any window associated with it) is undefined.

Posted: Tue Jun 24, 2008 9:58 pm

Yep, the problem was the {} around %session. That was converting %session into an expanded string, and CMUD wasn't checking first to see if this was a variant value.

So

#VAR a %session

was working, but

#VAR a {%session}

was not. I thought about what you said about the parser consistency, but decided that CMUD should really never convert a COM value into the "" string at any time, so I went ahead and changed it.

Posted: Thu Jul 03, 2008 3:59 pm

The secondary bug listed here, (#VAR a {%session} ) is fixed.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I also checked the primary bug and it seems to be completely fixed. I know the version history only listed the secondary bug. Now I can return to script writing. Twisted Evil