[quote=117919:@Markus Winter]What I don’t get:
I have modules and classes and can reference their properties from other classes just fine.
I can have object properties in modules and can reference them fine.
However if I have a class with an object property then it seems I can’t.
P.S. If I put the DictMod into a module then accessing it is not a problem.
[/quote]
I think I see the problem: you’re getting confused between a class definition and a class instance. I did a whole bit about that in my XDC talk, because it’s a really common error. Objects and instances are so confusing.
The metaphors I use to help make this clear are:
-
An object is like a blueprint showing the plans to build a house.
-
An instance is an actual house built from that blueprint.
In your project, cCanProteinPrint is an object definition, while CanProteinPrint is an instance (a canvas placed on the window).
Thus, when you tell Xojo (or RS), cCanProteinPrint.DictModificationsIdentified, it is not referring to an instantiated object (a built house, only the blueprints to a house), so it doesn’t work. (A blueprint’s properties don’t really exist.)
The solution, as pointed out earlier, is to use CanProteinPrint.DictModificationsIdentified, but that raises some OOP problems because then your cFragment objects are assuming things about their world (mainly, that an object called CanProteinPrint exists).
A better solution would be to do something like I demonstrate in my Invaders2 example project. The situation there is similar: I gave a gameCanvas, but I only want there to be one of such an object. I therefore use a Singleton design pattern (based on the Singleton example project that ships with Xojo). It’s basically just a method you call that returns a reference to the gameCanvas, but it will always return the same object (since there can only be one gameCanvas).
Once you obtain that reference, you can then safely refer to it by name.
Something like this:
dim myCanvas as canvas = getCanvas // This global method returns a cCanProteinPrint object.Now you should be able to refer to your canvas’ property like this:
myCanvas.DictModificationsIdentifiedThis makes your use of this slightly more complicated, but not in a bad way: you just have to include the dim myCanvas... each time before you want to do something with the canvas object (such as access one of its properties). But doing it this way is safer and more OOP-like, because now your object isn’t making assumptions about its world: it only knows about cCanProteinPrint because you’ve told it about it and you’ve got a specific way to access it.
(I wrote about Invaders2 and this process in the last issue of the xDev.
