Dr. Damien's Development - Running Top Level VIs II - SubPanel Use

[Neil.Pate]

Hmmm, the results of my informal poll prove conclusively that Dr D's code is weird 😉   (infinity to zero ratio!)

Now,  in order to make this statistically meaningful, I would be most grateful if others could vote on this topic...

Thanks!

N

[GregSands]

N - With all respect, I think people would just prefer not to play your game   For me, it's not about whether it's "weird" or not, it's whether I can learn something.  I've thought that the way Dr Damien has revealed his code development process through this series has been very insightful and useful, and whether or not I would use that precise coding model, I can easily understand and evaluate it.  So Dr D, please keep the series going!  And N, rather than dismiss Dr D's contribution, why don't you post a parallel series of posts which develop code for the same application using techniques which you are familiar with and make sense to you?

Cheers ~ Greg

[Neil.Pate]

Greg,

Thanks for your comments. I am really not playing a game here, but just trying to judge my own level of competency.

I am all for learning, but my engineering background has taught me not to just accept things without questioning them. When something in my brain goes "thats odd!" I generally like to investigate it, to see if there is something I can learn from it.

DrD is posting from a position of authority. People who may not know better could look at his code and think this is the normal way of doing things. That was what I was trying to find out. Is it my perception of what "normal" code that is wrong, or not? I take it from your non-commitance that you would not use that architecture. Thats another vote in the weird column 😉

If people don't vote, I will never know what the general consensus is or not. I explicitly stated this is not a personal attack on DrD.

Your idea of me doing my own posts on the same topic is really interesting, but xylophones are not really my kind of thing. I will code up something less "weird" when I get a chance 😉

[jon_mcbee]

Hello DFGray,

I followed your example for a user interface I am working on.  I have five subpanels that make up the UI, and they are populated by plugins depending on user selections.  I have noticed that the plugins run much slower when launched into the subpanel than they do when run by themselves.  I do not know why this is, I can use the Simple Subpanel shipping example to call up one of my functions and it runs at normal speed within the subpanel.  Is the problem related to having multiple subpanels running at once?  I would appreciate any input you can give.

Regards

[jon_mcbee]

Nevermind, I found the problem.  It was timing in my function VI's.

[Daklu]

jmcbee,

Can you post your code?  Just to verify, your main app has multiple subpanel windows in it, each containing it's own vi?  Based on what you said I would start looking into parallelism issues, such as if your subpanel vis rely on a common sub vi that isn't re-entrant. 

----------------------------------

nrp,

---

I am sure your design decisions all have very sensible reasons behind them, and its probably an incredibly effecient architecture, but its just too much for us mere mortals without PhDs!

---

Rather than a blanket request to simplify the code, a better approach is to ask questions about why specific design decisions were made.  Things always look needlessly complex when you don't understand the reasons behind a specific implementation. 

To be frank, this code doesn't require a PhD to understand (although it would certainly benefit from more comments.)  It does require some understanding of the issues and techniques to break an application's functionality into modules.  Personally I don't think there are enough examples on creating modular code and as a result very few Labview developers think it's important.

----------------------------------

Damien,

Why are the 'Function' vis not part of the plug in child class?

[DFGray]

You cannot use the Open/Run methods on a member of a class (and certainly not a dynamically dispatched one, which this would need to be).  Since the function is dynamically called, it needs to be outside the class.  Putting it into a library with the class seemed the easiest choice.  I am not entirely satisfied with this architecture, but it seems to work.

Note that what you can and cannot do with class members changes from LabVIEW version to LabVIEW version as classes have been made more robust.

[Intaris]

I'm confused.

I understand that Load /Open doesn't work on a dynamic dispatch VI but can't the Launch / Open code simply be PART OF a dynamic dispatch VI (Parent class)?

I've done something similar in the past (shock horror).  I left the sub-VI embedding and panel launching up to the class and the ability to get a classes default values allowed me to load my plugin classes at run-time.

What I didn't test much was the reentrant aspect of things, so are there major problems to be aware of there?

Regards

Shane

[Daklu]

---

DFGray wrote:

You cannot use the Open/Run methods on a member of a class (and certainly not a dynamically dispatched one, which this would need to be). 

---

So this is code from an Active Object I wrote* that launches a privately scoped member vi using the Open/Run methods.  I wrote it in 8.6 and your comment worried me enough that I just confirmed it works in 2009.  Are there plans to remove this functionality or am I misunderstanding what you're saying?

*Based heavily on Kurt Friday's example on LAVA.

[jon_mcbee]

Do you have a link to the LAVA example you mentioned?