ConstructOnLoad attribute for custom event.EventData objects?

9 views (last 30 days)
Reading the documentation on the creation of custom event.EventData objects I found the following puzzling note:
To save and load objects that are subclasses of event.EventData, such as ToggleEventData, enable the ConstructOnLoad class attribute for the subclass.
Checking further , I found that ConstructOnLoad allows one to automatically call the constructor of a class upon 'deserialising' a class from a .mat file.
However, for that to work, there should be a constructor with no arguments:
Ensure that MATLAB can call the class constructor with no arguments without generating an error.
However, in the doc on event.EventData, an example is given with a constructor that takes a parameter and without a loadobj!
classdef (ConstructOnLoad) ToggleEventData < event.EventData
function data = ToggleEventData(newState)
data.NewState = newState;
This is highly confusing to me.
No mention is made as to why it would be smart to add the ConstructOnLoad attribute and what would be the consequence of not having it. No background is provided.
This will cause users to add the attribute by default without knowing what it is for.
As such, the documentation should probably be improved.
That being said, I would love to hear from the experts what would be the reason for adding the attribute.

Accepted Answer

Guillaume on 13 Apr 2016
The relevant documentation about ConstructOnLoad is at I agree that finding that in the documentation is not easy. The search function in the doc is rubbish.
I agree with you that the note is inconsistent with the example. If you can, you should raise a bug report with matlab. If you tried the deserialise the event object, it would probably cause an error (that possibly matlab would ignore, I haven't tested).
It probably doesn't matter anyway as I can't see many use cases where you'd want to serialise event arguments, particularly since serialisation in matlab is limited to saving to a file. If you do need to serialise the object, you can also override the loadobj method and then not have to worry about ConstructOnLoad.
In my opinion, serialisation/deserialisation in matlab is badly implemented. loadobj itself has plenty of limitations. Every single time, I've wanted to implement custom deserialisation (to support old object schemas for example) I've run into major problems that couldn't be worked around: can't support immutable properties, can't deserialise member objects that have changed name, etc. Unfortunately, MathWorks does not seem to want to improve on that.
Guillaume on 13 Apr 2016
One scenario I could see for serialisation would be to send an event to a remote machine. That is normally done by serialising the event to a string or a stream of bytes, sending that over TCP, and deserialising on the other end.
That's not possible with matlab since you can only serialise to file. Unless you write to file, read the file, send the file content over tcp, save the tcp stream as file at the other end, and deserialise from the file. Really clunky.

Sign in to comment.

More Answers (0)


Find more on Data Type Identification in Help Center and File Exchange

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!