Background Objects in User-defined Controls

[UrbanCyborg]

I just had occasion to move some objects from being coded by the VMD editor to hand-coded in the java file, and discovered to my chagrin that anything tagged as a background object vanishes. How do you go about getting things like rectangles, lines, etc. to show up? I know some of the devs, like Colin, hand-code all their controls. How do you make that work? In this instance, there aren't even any code fragments to copy over.

Reid

[seal58]

Hi Reid,

for my Bar Meters I did it this way with lines and rectangles:
- create one of each needed kind of element manually in VMD
- uncheck option "is background element"
- copy automatically created code to a method into my code as often as needed, including all code lines that seem to be unnecessary
- delete manually created elements

During this work I found:
All elements which are created in runtime have a Z attribut from back to front in the order they are created in. If the elements are created within various methods, order of that methods call is significiant too.
It is recommended to send all manually created graphical elements to back as far as possible.

Finally graphical result looked as desired. Elements created during runtime can be modified by methods as SetColor() or SetPosition() and so on.

Roland

[ColinP]

Components that are tagged as background objects are pre-rendered rather than drawn normally. It's intended to speed up things like label drawing as on initialization VM fills the buffer with the background image or plain color and then draws all components tagged as background objects into this buffer on top of the background

Then on repainting a damaged area VM just copies the area from the buffer and doesn't ask the components to redraw themselves.

If you tag a component as a background object it no longer even appears in the InitializeControls() method. So technically it should be impossible to reference it. But it sounds like you've copied the generated code while an object wasn't a background object and then tagged it as background.

This probably confuses the hell out of VM as there might now be two versions of the same component - one a background object that VM knows about and another that's a foreground object that you've created that VM doesn't know about, and they are interferring with each other. Or something along these lines.

You should be able to fix the problem by just removing the duplicate rather than tagging it as background.

---

Ah, I see that Roland already posted more or less the same thing. HIs critical line being "delete manually created elements".

[UrbanCyborg]

Roland, Colin, thanks for the responses. I figured out some of this. For instance, I could manually create graphics objects. Because of my use case, I don't think I can flag them as background objects; this is basically a debug pane, and I need the ability to just comment out all the code that creates it for a release build. I also want to add it to my basic template, so I can use it on any module I start in the future. Maybe this doesn't obviate post-tagging objects as background; I'm not sure about that.

I have run into one oddball case where I created a copy of a control set containing background objects, deleted it, and had the background objects still present, although not selectable. I can right click on them and get that menu, but selecting Delete from the menu changes nothing. I can drag the objects around, and even create copies of them (which behave normally); I just can't get rid of them.

Reid

[creart]

I place one object that I need in foreground manually and hide that in the the initialize section... as sort of a 'template'
Then I use a function to create the objects that I need dynamically in an array.. that way you also have more influence on size etc.
I mainly do that with in/output ports, knobs etc (those are not in the background of course), but have also done it with rectangles and ellipses.