jgcode

Hi UnCLAD If LabVIEW is configured to do so GSW will open when no other VI's FP are open (I.e. all closed). Are you looking for a programmatic way to show GSW? I don't think that is possible. Maybe you could suggest it on the IE??

Scott That is right, that issue does apply to both 8.2 and 8.6 implementations. But that is the limk I was referring to. Cheers -JG

Hi unCLAD Not sure I can contribute any more as everything is mentioned above - you will need to close the FP in order for the GSW to appear. Cheers -JG

I think there is cross-talk between the two implementations "8.2, 8.6" and 2009!

Hi iyeager I haven't looked at your code - but it sounds crazy if you are having to make 15 different apps of the same thing! Changes in names, settings etc... should be handled using configuration files (or the like). In this case you could even look at the features of MAX and whether they may help too. This way you only have to build one app and you can easily switch hardware around simply but just importing/exporting a new configuration. Cheers -JG

Yes, good point - but I think the 'race condition' issue is just a use-case issue rather than a design flaw. All transactions that occur inside the IPE are atomic, so you are safe if you create a 'Singleton' methods for everything you want to do and its done inside the IPE. If this is not flexible enough then don't use it, instead pass a DVR around whereby the developer has the choice to implement the lock-and-unlock paradigm and select and run methods where required. But I have also seen the 'same' race-condition is other's code when an API is created for a DVR'd Class - which is why I see it as a programming\use-case issue rather than design flaw. This is also (one of?) the reasons why NI would not allow wiring a DVR to a Class Method (PN only not IN) for fear of creating issues with unaware developers. Whilst I would still like the feature, I have seen it done 'accidentally' by experienced developers, so can now definitely see where NI are coming from. The advantage of the patten is that the code required is much simpler and cleaner than using a traditional FGV. When I used to use FGV\AE\MFVIs a lot (pre-LVOOP) I implemented them as follows. I don't like placing enums (methods\commands) down on the BD The enum should be private so private methods cannot be called If the enum gets updated, I don't want it affecting application code So I wrap each method call to the FGV in a wrapper VI This means I can also defined the data inputs/outputs of the method, rather assume user has intimate knowledge of the FGV I usually like to maintain an interface to the FGV which is a Cluster input and Cluster output so that I don't fill up the connector pane So in the wrapper VI I have to bundle up inputs and unbundle outputs All the above work in not required in the AQ's 2009 implementation, no enums, bundling, or wrapper VIs. To handle reuse between different singleton methods I create method VIs of the DVR'd Class. I am not really fussed whether it is technically a singleton or not, only that if the pattern fits my use case, then I like to use it.

This is a good point but as this topic focuses around the use of Classes wouldn't the dataflow and hence parallelism be predominately defined by the Class in/out terminals of the method VI (making the Error in/out terminals irrelevant)?

Might be helpful if you post some code of what you have done sjukheter.

Well, yes I am keen to know too. I aside from the DD comment above, you are have overhead calling the subVI on a static method anyways. Does the error case really matter? Or is it a big overhead? I would like to know the answer to that in the Dev Environment and in the Run Time Environment (if it is different). As for me, in terms of Classes, right now I can't be bothered not including Error in/out terminals - except for Private and some Protected VIs. The last thing I want is to update a Public method and find I don't have Error in/out terminals - that would cause a change in the Public API and I would want to go through my code and relink, I would rather just do that in the first place. And I have never found an application has bogged down because of it. Plus if I am chaining methods then I can keep them in a straight line for Class in/out and Error in/out and each VI in the API matches. But... is there a worthwhile reason to change?

Ok, back on a PC - here it is...VI Server is the issue.

Hey man! The answer is out there somewhere coz I am sure I have read it on LAVA. But I am on my phone so I am no help at the moment. Anyways, maybe AQ will chip in and set the record straight.

[8.2 vs 8.6 SEQ FGV] I am pretty sure AQ has posted this already on LAVA. From what I recall he said there was an issue with the 8.2 implementation that prompted the fix for 8.6. And that he did not recommend using the 8.2 version. I guess he is the best person to answer. FWIW the 2009 DVR implementation rocks. I really like the simplicity of it.

Hi Sharon The default Dialog primitives are modal, so you would have to create your own Dialogs that would be e.g. floating, to do the above. Ease enough, just means more work for you

Steve, you don't have to modify the templates as AQ added this feature in 2009. Static and Dynamic 'templates' are generated in C not G. Accessor methods are G. You can find them and replace them (this has been posted before) or you can use the Custom Hooks to alter them (introduced in 2009). Cheers -JG

Seems like some people are going around in circles. Mark, you use the term "truely decoupled" which implies that there are different levels that describe decoupling. Of course what John is saying is the higher level of decoupling. I have not disagred with that. What also has been said is that applications can benefit from a level decoupling depending on requirements. I simply presented 'an example'. Therefore, comparing the two directly does not make sense.

Ooh a t-shirt, I want one!!

Does that mean you already have??

Been there

So... I have no idea what your point is? All I said above is that I 'hope' NI can't do it and if they can then IMHO I think it means it's not 100% secure - which you just agreed with above?? The other thing I said is that 'I think' Locked VIs get skipped because when I tried mass compiling these they still take ages to open in a new version leaving me to believe that each time onload the compile would happen but it would never save the changes due to the Locking property - which leads to a loading performance issue. That's the reason I gave up on Locking for distributing code. Again happy to stand correct.

Happy to stand corrected... Well wouldn't LabVIEW need access to your block diagram in order to compile it? Meaning password protecting your VI's isn't completely secure? If I PP a VI - I want no one to access it - not even NI!

About this much: Get all the references, then its just handling events (sends message to engine) and receiving event (normally data to update screen etc...) Trying to keep it simple: with skinablism - minimise duplicate code More complicated stuff is done via references - configuring graphs etc... Nope, In the case above the engine can run the UI thread (or another higher-level VI could run all threads, but old habits). If you want to change the UI then drop and new one in and delete the old one. Of course you could do it more spectacularly (e.g. dynamically instantiated etc...) (code to switch between the UI's at Run Time etc...) but this project did not need it, nor could I be bothered (I just want to decouple the UI further). As per your 'slave loops' it easier to program on the separate thread just be double-clicking to open it.

The untold power of mods!! The untold power of mods!!

@Ben [Time] You obviously missed Jeff's NI Week 2010 speech then

Hey Cat, good luck with the surgery and lets us know how you go.