@Jeff Bohrer wrote:
(Wrapping my head in duct tape)
Thinking out the most scaleable solution for a system that operates on "Widgets" by interacting with each "Widget cell" through "Gizmos". The path i'm thinking is the create "Widget cell" and drop it in 1-n subpanels. Easy right? just set Widget operator.vi" to reenterant (pre-alocate clones) and the GUI runs all widgets it is configured to run. the problem is the resource "Gizmos" will need to be re-enterant too (Share Clones) so that each widget operator associates with a unique gizmo resource module and the gizmos operate in their own space sharing memory between sucessive calls to the resource module.
The trick is what happens to gizmos clones? Does preallocating the spaces for widget operator also create a clone of gizmo or are all gizmo vi.s going to share space unless a larger clone pool is needed because of collisions? That would be BAD. Or is the correct approach to also prealocate gizmo.vi but, through some means force all calls to gizmo from widget operator to share the same clone copy?
I can't say this is your most clearly-written post, to the point that I can't quite rephrase what I think you're trying to do (is there a 1:1 mapping between widgets and gizmos?), but I think I can answer your question. You're asking about putting a reentrant (share clones) VI - I'll call it "share.vi" - inside a reentrant (pre-allocate clones) VI - which I'll call preallocate.vi. When you create multiple copies of preallocate.vi, you want to know, will you get pre-allocated copies of share.vi? No. There will be a pool of share.vi copies, and new copies will be created only when all existing copies are already executing. You won't be able to guarantee that a given copy of preallocate.vi will always call the same copy of share.vi. If you need all copies to share some critical piece of information, you can use a non-reentrant VI (perhaps a functional global) to store it.
