Properties retention

I normally place properties that I wish to keep alive in a module. To better organize my program I was wondering if I had a serial class with properties that I wish to maintain how would I keep those properties alive? They would hold running values that the serial class needs.

Hi, Clifford!
You should create a subclass of SerialConnection (or the now-deprecated Serial class) and have your properties, methods, etc stored there so that they are instance-specific.

Here’s some documentation that should help:
https://documentation.xojo.com/getting_started/object-oriented_programming/oop_design_concepts.html#Inheritance_.28Subclassing.29
https://documentation.xojo.com/getting_started/object-oriented_programming/subclassing_examples.html
https://documentation.xojo.com/getting_started/object-oriented_programming/class_properties-_methods_and_events.html

That is already what I have done. My concern is that after the subclass is instanced and used does it not vanish along with its properties?

Not as long as you keep it in scope. This can be as a property in a module, as you’ve stated, or as a property of a window, ContainerControl, etc. Wherever it makes the most sense logically so that when it isn’t needed any longer, it can go out of scope and be destroyed.

If your entire application relies on the existence of the serial connection, then placing it in a module and set to public is fine. Likewise with making it a public property of the App object.

Shared class properties behave like module properties. Right click the property and select “convert to shared”.

You can simple create a singleton object, to be kept in scope at the highest level, the App.

I’m not sure what a singleton object means??

I believe this is the solution I was looking for. The properties hold a running average factor for sensors that are read every few seconds. I needed those averages to stay alive and now they can live with the subroutines that use them for better encapsulation. Thanks.

A singleton is a OOP design pattern that guarantees only one persistent instance of the class can exist in the program.

A prototypical singleton in Xojo uses a shared method to guard the constructor, and a shared property to hold the singlular instance:

Class Singleton
    Private Sub Constructor()
        // a private constructor means outside code can't instantiate this class
    End Function

    Private Shared Property Instance As Singleton

    Shared Function GetInstance() As Singleton
        If Instance = Nil Then
            Instance = New Singleton() // call the private constructor
        End If
        Return Instance
    End Function

End Class

Then, in other parts of the program:

Dim instance As Singleton = Singleton.GetInstance()
instance.DoSomething()

So does a singleton make the instance and its properties persistent or does my properties still need to be in a module or in the App? Does this need to be associated somehow with the right click shared properties option or is that something else?

Yes, the singleton instance (and its non-shared properties) is persistent without being held as a reference anywhere else, like in a module or the App, and that’s the point. The Singleton class itself holds the reference as a shared property, which behaves like a module property but is encapsulated by the class.

So instead of App.MySingleton.SomeProperty = 1 you have Singleton.GetInstance.SomeProperty = 1; the class name replaces the module name or App in the calling syntax, and the details are encapsulated in one class instead of being scattered across several modules, the App, windows, etc.

This is just one example of what shared methods and properties of a class can be used for.

1 Like