Run-time storage of non-COM objects/variables?

[Pablo]

I tried to use SDB.Objects and Node.CustomObject to keep a reference to an object (an instance of a class I defined). In both cases this doesn't seem to work. For example,

Code: Select all

MyNode.CustomObject = myObject

doesn't raise an error, and even later I get

Code: Select all

varType(MyNode.CustomObject) =9 'An object (in particular, not Null)

However, when I try to access the properties of MyNode.CustomObject I get an "Object doesn't support this propert or method" runtime error.

Is there any way to keep a reference to an arbitrary object during runtime? Is the CustomObject property really restricted to COM objects?

[Steegy]

SDB.Objects should always work.

Are you sure you "set" the object?

Code: Select all

Set MyNode.CustomObject = myObject

Code: Select all

Set SDB.Objects("MyNode") = myObject

And are you sure myObject is really the correct object, that supports the properties that you are trying to read?

Cheers
Steegy

[Pablo]

I tried with and without "set". And yes, I quadruple-checked that I'm trying to access the right properties. Is anyone else experiencing the same problem?

[uwuerfel]

Is anyone else experiencing the same problem?

Yes, I was experiencing the same problem and I also found the reason.
Even this thread is quite old, I just wanted to document it - just in case anybody else runs into this behavior.

The reason is that the script that originally stored the object in sdb.object has been unloaded from memory by MM.
It is quite hard to find out when MM loads a script into memory (i.e. start a script) and when it gets unloaded.

For my own tests i wrote a little test class that helped me to find out when this happens:

Code: Select all

Option Explicit

DIM StartStopMsg_Class : StartStopMsg_Class = "StartStopMsg_Class"


'==============================================================================
'
' NAME:     StartStopMsg
'
' PURPOSE:  This is just a class for testing.
'           It displays a Message when an object is created an one when that object is destroyed.
'           It's designed mainly to learn when MM starts and stops a script
'
'==============================================================================
'
Class StartStopMsg

    private m_text
    private m_title

    ' Initialize-Event -- Sort of default constructor. VBS doesn't know anything else...
    Private Sub Class_Initialize
        m_title = "Script start / stop notification"
        m_text = inputbox( "Reason for start of script?", m_title, "Unknown" )
    end sub 'class_initialize

    ' Terminate-Event -- Sort of default destructor. VBS doesn't know anything else...
    Private Sub Class_Terminate
        call msgbox( m_text &" finished", vbOKonly, m_title )
    end sub 'Class_Terminate
End Class 'StartStopMsg

If you want to, you can store this class in a separate file.

In one of the first lines of your script you can now write

Code: Select all

' Just for testing and debugging, to see when the script gets started and stopped
if eval( "StartStopMsg_Class <> ""StartStopMsg_Class""" ) then Script.include( "auto\includefiles\StartStopMsg_Class.vbs" ) 'end if
dim g_startStopMsg  : set g_startStopMsg = new StartStopMsg

At each start of the script this will pop up a message box asking for a name.
This is to help you distinguish different instances of your script.
You could use names like "AutoStartUp", "ClickedOnNode", etc.
When the script gets terminated (i.e. unloaded from memory) it pops up another message box, telling you that the "AutoStartUp" finished.

To circumvent the problem you can AFAIK do two things:

1)
Use MM V3.1 or later. Here the script handling was changed and scripts are always kept in memory.

2)
There are two different event mechanisms in MM (an older one and a new one).
Those events are used to inform a script about actions that occur in MM; e.g. user clicked on a node.
If you use the older event mechanism, the script gets loaded to and unloaded from memory every time an action happens.
If you use the newer on, the script gets loaded once into memory and remains there until MM shuts down.

The old event mechanism used the following syntax:

Code: Select all

Node.onFillTracksFunct = "SomeScriptFunction"

The new event mechanism uses the following syntax:

Code: Select all

Script.RegisterEvent Node, "OnFillTracks", "SomeScriptFunction"

Note that (with MM prior to V3.1) even if you use the newer event mechanism there can still be several instances of your script at the same time. The advantage of using the new event mechanism is, that the script instances can now communicate using sdb.objects.

According to the devs of MM this should get better with MM V3.1, since a script gets loaded into memory once and remains there.
I made a (really short) test with a beta version of V3.1 and it worked for me. But I can't tell you if all aspects of this problem are solved...


I hope this information helps somebody and saves some time.

CIAo, uwe..