LabVIEW
Programmatically achieve overlapped subpanels ‘bring front’ and ‘send back’
@AdarshaPakala wrote:
Interesting....How was the memory performance with this?
How did it look to you from the performance angle? Interested to know your experience.
Once it runs, it's almost no overhead.
Hit detects can be expensive, but it's OK. On a mouse down event, a hit detect in 3000 elements 1D array of rectangles isn't noticeable. I guess even less so if the array is sorted. You only have to hit-test individual controls in subpanel that do hit. Mouse enter events won't work, as the panel is behind another. The switch is instantly.
Updating 3000 indicators in subpanels, by reference, is just as fast as updating 3000 indicators by reference on one front panel. The implementation of subpanels is very efficient 💪.
The only problem is that you can't insert controls in subpanels. You have to have VIs. Those VIs need to run, or the right click menus are off. Running VIs also need to be stopped. Opening VI Server references is pretty efficient. Sadly, releasing references can be really slow. Releasing 3000 references of non-trivial VIs van take 30-60 seconds...If you don't close them, you get the wait when you're code stops.
I also have a grid control, that can have 2000X2000 elements. That's 4000000. They're not all visible at the same time, so 100X100 subpanels will do. Still, subpanels don't work. Loading 4M VIs is one thing, releasing them takes forever. So instead I use pictures of the cells, and set the properties when activated. This is hard work BTW. You'll run into all kinds of evil, like order of value change events and detecting if a ring is deactivated (you can't).
So, my experience is that subpanels are very good under certain conditions.
Search LabVIEW like a graph! 