Object Oriented Programming with Xojo, and in this case Event Oriented Programming as well, is simply wonderful. You create objects (Instances) from the defined classes that act as templates and just let them roll. From there, the interactions made by the user are those that determine how objects interact with each other via sending messages to each other (method calls), the access to properties and also the execution of events.
However, sometimes the combination can simply reach unstable situations by the very nature of our applications and here is where failures can arise in memory management. Fortunately, we can keep this under control with the help of the WeakRef class.
This is, in fact, what happened to me recently while implementing a new feature in Snippery my productivity application where one of those unlikely but possible cases one of the objects left in an unstable state. What does this mean? The referenced Control object stored in a property was not marked as nil once it was out of scope because its containing window was closed, so it was simply unsafe (an dangerous!) to check or access its properties and methods through a simple verification of the type:
if miPropiedad <> nil then â¦
Despite the object referenced through the property would have been released, this condition will execute the code inside the block resulting in a unexpectedly exit from the app! In fact inspecting the object via Xojo’s debugger shows that the reference is still there but it inner structure is void.
So executing the previous code will bring a beautiful error message from OS X:
That is an attempt to access a memory vector where we expected to find a data structure that is not there anymore.
I have to say that after further research on the subject I have found that this kind of error does not always occur and that it may depend on the type of object that we maintain the reference to, or even the property we want to access, or the method we try to call when the objects is in this “unstable” state. In the best of the cases, simply nothing happens. In the worst case, your application will suffer an unexpected exit you will not be able to trap using the Try … Catch block or exception handling mechanism offered by the Xojo language.
If you want to see for yourself what I’m talking about, you can download the example application (https://www.dropbox.com/s/
WeakRef to the rescue!
How can we solve these kinds of situations? Easy! The WeakRef class allows code to maintain weak references to objects. When you wrap the object you’re interested in an instance of the class WeakRef, we will ensure that such reference is released (and thus becomes nil) through proper memory management. So, problem solved! From this point on we can perform and trust a conditional test of the reference against ‘nil’ before trying to access any of the properties of the object itself.
In the case of our sample application, we can fix the problem with the following changes:
1. We define the property SourceControl Worker class to be of the WeakRef Data Type
2. We make the following changes to Worker class constructor (where the referenced Control instance is now wrapped into a WeakRef instance):
sourceControl = new weakref( c )
3. We modify the conditional block of code for the Worker method to:
if sourceControl.Value <> nil thenâ¨
textArea(sourceControl).Text = “This is a test”
Note that in this case we Cast SourceControl to TextArea, so we can work with the properties and methods of the control that we know are actually a control of TextArea type.
Make the changes, run the app again and you’ll notice that this time the app will continue running without errors once all the windows are closed.
You can watch the video (in Spanish only) that talks you though this example.
Javier RodrÃguez has been the Xojo Spanish Evangelist since 2008, he’s also a Developer, Consultant and Trainer who has used Xojo since 1998. He is in charge of AprendeXojo.com and the developer behind the GuancheMOS plug-in for Xojo Developers and the Snippery app among others.