loadobj input argument type determination?

7 visualizzazioni (ultimi 30 giorni)
Joseph Burgel
Joseph Burgel il 23 Mag 2011
All,
Can anyone tell me what drives the type of argument that loadobj() gets? According to the help:
The input argument, a, can be: The object as loaded from the MAT-file. A structure created by load (if load cannot resolve the object). A struct returned by the saveobj method.
Well my object was saved to a .mat file but now, all of a sudden, after some work on the object's class definition, my loadobj ftn is now getting structures passed to it. What does "if load cannot resolve the object" mean? I did something to my class that caused loadobj to all of a sudden start to get structures but I have no idea what caused it? If I remove the loadobj function and just load the object from the .mat file, load() returns an object; so it must be able to "resolve" the object at some point. I really don't want to go to the trouble of instantiating a new object in loadobj() if a struct is passed and copying all the fields over. Especially when I know the object can be loaded by load()
Very confused. Any help is appreciated. A doc somewhere that I'm missing? I think I've read everything available.

Risposte (1)

Richard
Richard il 24 Mag 2011
You can think of objects as being saved as a set of pairs of properties and their values. When you load one, it creates a new object and then sets those saved property values into the new object, and then calls loadobj if there is one. If any of the properties does not exist, or errors because a property function rejects the value, then the loadobj will be passed a structure of data.
Have you removed or renamed a property, or changed code to exclude property values that used to be valid? You can also try using the debugger to see if it stops in any of your MATLAB class code while loading.
  3 Commenti
Richard
Richard il 24 Mag 2011
Hi Joseph,
Yes, the property set functions are called before loadobj, and you can use these to accept and convert old property data. The transient property will still be set because there is saved data for it: the overall aim of the loading process is to get all the saved data successsfully sent into your new object.
I can't really explain your observations regarding the failing and then working load of a v1 object. Can you reproduce this from a clean MATLAB start? Is it possible that you have persistent variables in your set functions?
Another thing to watch out for is whether MATLAB has cleared and reloaded your class when you change the definition. The class can't be cleared if you have existing variables that contain an instance. If you were testing loading then the class definition reload might lag a test-cycle behind when you thought you made a class change.
Joseph Burgel
Joseph Burgel il 24 Giu 2011
Hi Richard,
Thanks again for the response. I would have replied earlier. I thought I would get an e-mail if someone replied and I didn't. Regarding your comment:
I can't really explain your observations regarding the failing and then working load of a v1 object. Can you reproduce this from a clean MATLAB start? Is it possible that you have persistent variables in your set functions?
Yes, I do have persistent variables in my set functions and yes, I should know better. I did it despite the ample warnings because it's so convenient on a number of fronts and at the time, it didn't appear to be causing problems. I should have been thinking more about the load process before I did it. I'll remove them and see if that doesn't fix the problem.
Regarding your comment:
Another thing to watch out for is whether MATLAB has cleared and reloaded your class when you change the definition. The class can't be cleared if you have existing variables that contain an instance. If you were testing loading then the class definition reload might lag a test-cycle behind when you thought you made a class change.
I think I'm also running into this on another problem in that some of my objects contain instances of java objects set to Transient properties of the object. These objects have been instantiated on the EDT thread and I have found no way of getting rid of a couple of them "Clear All" , "Clear Java" etc. have no effect. All I get is:
Warning: Objects of DQTree/DQTreeModel class exist - not clearing java
Warning: Objects of DQTree/DQTree class exist - not clearing java
Warning: Objects of dqtable/DQCellEditor class exist - not clearing
I asked a question about this but have not gotten a response. I've resorted to re-booting ML everytime I make changes. This as DRASTICALLY slowed my development
Regarding your Comment:
Yes, the property set functions are called before loadobj, and you can use these to accept and convert old property data. The transient property will still be set because there is saved data for it: the overall aim of the loading process is to get all the saved data successsfully sent into your new object.
Not sure I understand your answer. V2 make the property transient. Because the loaded V1 object had the property as persistent, will the set method be called? Can I interpret your answer to mean:
Yes, the property set functions are called before loadobj, and you can use these to accept and convert old property data. The NOW transient property will STILL CALL THE SET METHOD because there is saved data for it: the overall aim of the loading process is to get all the saved data successsfully sent into your new object.
Thanks again for your help.

Accedi per commentare.

Categorie

Scopri di più su Data Type Identification in Help Center e File Exchange

Community Treasure Hunt

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

Start Hunting!

Translated by