I have a custom object I have created that is one of the key backend items in my projects. This code object represents the functions of a real world object it interfaces with. It is sub-classed from object and is not a control - so it’s not graphical in nature.
That said, I have graphical objects such as rectangles or canvases that sometimes need to be associated with this object. It varies depending on the function or mode of display being used in the app.
Is it OK to have graphical (ie: control) objects to be properties of a non-graphical object? I would use WeakRefs in my object to prevent any issues with circular or hanging references. Or would it be more appropriate to use a dictionary where the key is my custom object and the value is the graphical control?
I would think that this is a good idea. A non-graphical object can be threaded which updates the data faster than updating the graphics through a timer.
[quote=354135:@Jon Ogden]Or would it be more appropriate to use a dictionary where the key is my custom object and the value is the graphical control?
Or does it matter?[/quote]
When creating graphical intense programs, such as animation, then I would usually prefer an object because the speed is fast. I am unsure as to the refresh speeds of a dictionary, and its possible that a dictionary that has all of its data is memory would be quick. This is a good question, and I have always seen animation with objects, not as a dictionary. I am not sure what the overhead in a dictionary would do for performance, and there are some dictionaries which can perform many updates per second. Just because everyone does it this way, doesn’t make it right, and there is usually a reason for this… that’s all
Maybe make a small trial program and try both and object and a dictionary and compare speeds and reliability.
Speeds not generally so much of the problem. It’s not a super graphically intense application that I have. I’m just looking for the best place to stick the dang things! So for example, if a particular window is open, I’ll need to create a rect shape and place it on a canvas in that window. That shape gets some parameters and other things for displaying an icon or image from my object. So they have to be tied together.
But as long as it’s OK to have controls to be properties of a non-graphical object, then I am OK with that.
@Jon Ogden Another possibility is to use a class interface. Then anything that could connect with this class would need to implement the interface to be valid… even if the interface has no methods attached (although it may be more useful if they do).
I second the idea of a class interface. That abstracts the graphical portion away from the object. The object calls methods on the interface reference that it holds (if any) and the graphical object can implement those “commands” however it chooses. A rectangle might change color, while a progressbar might increase its value, or a canvas might display different images.
You might consider doing it the other way round
The graphical object should know about the non-graphical thing and be able to “draw” whatever state makes sense
That way the non-graphical one doesn’t need to know or worry about “drawing” in any way shape or form
It does its thing and lets the rest of the system know about it (or not) however it does that
And the thing that DOES need to draw, the graphical object, can ask the non-graphical object about whatever is relevant for whatever it needs to do to draw and neither concerns themselves about things outside their scope of responsibility
The UI things draws UI stuff
The non-ui thing does its non-UI stuff and they dont overlap