Object Order Hierarchy (Front To Back) For Various Object Types

[SteveMyres]

I have an app where I'd like to stack a symbol component over the top of a variable value display, but no matter how I set the display order, the display always draws over top of the symbol. IIRC, you can't stack static components over the top of animated ones, but I was under the impression you could stack ones that were all animated.

1. Is there a workaround for this specific case?

2. This also raises the general issue of any other pairs of component types that have relative display priorities that cannot be overridden. So can you give us a list of the order hierarchy and any help on workarounds when it would be helpful to override the standard order.

[AzeoTech]

Section 7.3 talks about this a little. Basically Graphs, Symbols and Panels all get drawn on a separate layer which is placed behind everything else. The only real workaround for your particular case would be to convert the symbol to a bitmap stored in a file, load the raw data into a 2D array variable, then use the image or canvas control to paint the RGB image. You might also want to add this to the feature request forum.

[SteveMyres]

Thanks!

[SteveMyres]

Turns out in this particular case, there's an easier workaround. The text of the value display is pretty small relative to the overall size of the object, maybe 1/3 as high and wide. So I can just make it smaller, stack it AND the symbol side by side on top of a panel of the same color as the background of the value display; same effect in the end.

[AzeoTech]

Sure. I wasn't exactly sure what you were trying to do overall.

I should also explain: the reason for the double levels has to do with the fact that graphs are drawn in a background thread of the application. This makes it so complex graphs don't slow down the UI. The way its done, however, requires that it be drawn onto a background layer. We decided to put panels and symbols on the same layer so that graphs could be put over top of them, a rather common use case.

[SteveMyres]

Can it be made controllable so it can still be done that way when needed but changed for special cases?

[AzeoTech]

Possibly. That might be the solution for the feature request. But nowadays memory isn't nearly as costly as it was 11 years ago when DF was created, so another option is still do the background painting, but to a buffer for each component rather than a single buffer layer. This would eliminate the issue altogether without losing the background graphing capability, which I believe is rather important.