jgcode

Unfortunately this also breaks the build when using non-Class VIs (LV 2010)

Great job on the release FWIW I like using events most of the time, but I have been creating API's for the messages since I can remember - I agree that the process/object should not expose the message In terms of the structure I started using what Justin presented after seeing it a@ NI Week, it was close to what I was doing but more defined/refined. When I don't need multiple instances, a few examples API's looks as follows:

@Shaun R - exactly!

Hope we didn't scare Cat off! (I am going to blame you if we did)

Yes it certainly is, as I stated this: Because I agree with this: And because we do a lot of this stuff too, a distributed system that has multiple instances of client UIs that communicate with (usually NI Targets e.g. cRIO). Comms is either TCP/IP or OPC etc.. So I know what your requirements mean. I just think, there is validity in discuss various options or gradients given the OP's question (and that the topic is interesting). Because even when you write the distributed UI, if you choose to implement it in LabVIEW, then you still have the choices to decouple that code, so talk of references is relevant!

Given you have stated that your requirements are absolute decoupling, I still wanted to point out that I disagree somewhat with the above - somewhere in your code you need to communicate with the UI. If you encapsulate this code e.g. in a Class, then you could override it for different methods of communicating with the UI. This may not be the best example but I have it lying around at home. It was a small app and I decoupled the screen as to separate the code for ease of programming rather than any other reason. For the most part I program in LabVIEW, so the FP is usually going to be LabVIEW. It goes something like this: Send the references from the UI to the controller via a message on startup Set the UI references in the Class (that's it - they are never exposed outside of the UI Class again) Controller pokes data from the Model (in this case a Map) into the UI Class. Now my screen is just a bunch of UI Elements with no code behind them. I can change this with little fear of messing up underlying code.

Check out the LAVACR. Vugie and Franswa have already nutted out the VI Scripting.

I don't see it as that. Sure, its not the highest level of decoupling but it is still decoupling. And there are situations were this is advantageous. You want the UI to be extremely lightweight, and if you have 'skinnable UIs' you don't want duplicate code in the UI's. And there needs to be some interaction with refs because you need to access properties etc. I usually encapsulate this functionality. If you were really concerned then yes, you would have to implement e.g. a controller component as Dave mentioned. Most of the time I find the extra work can be overkill but it is really dependent on the project.

In a current project I find the event structure bogs down on startup as a bunch of these events gets processed, after a while every goes back to normal and the Event Structure works fast. I do find this to be a little bit of a performance issue on startup, I need to investigate further tho.

I am only guessing here - when you say "we intend to" means you haven't started coding the project yet but will start in LabVIEW 2011??? I guess it depends on you critical the job is but I wouldn't do this at all: If you run into any issues (and from experience I have had are more issues with RT/FPGA than Desktop LabVIEW) then you have no where to go. If you develop in a version you consider stable and you know what you have to do works, then you can always upgrade at some point, test it, then rollback using SCC if needed. If you develop code that depends on a feature in 2011 and you get burnt somewhere else you may find yourself in a tricky spot.

Congrats on 1k mate.

Hi Cat I used one of the examples (there were two strategies: reference and queue based) successfully after seeing it in the manual, and I agree, it does work quite well. I normally like to update the UI using Events and receive events from the UI using the Events but I also like to get references to the FP for working with Properties e.g. setting up Graphs etc... NI Intermediate I (now Core 3) course also shows a way to decouple the UI, like how Dave (*simple*) describes, I used to use it a lot a few years ago. It is queue based. Cheers -JG

Hey John, here are a few chats on the subject plus a couple of others on the subject of testing you may find interesting: Unit Test Frameworks: NI vs JKI? What unit test framework for LabVIEW do you use? Unit Testing Strategies with xUnit? Your favorite unit test solution for LabVIEW Unit Testing dynamic dispatch VIs Testing private class vis

I use Perforce, my local files sits under D:\Jobs or something similar. Having the whole C:\ drive under SCC makes no sense to me either. At the end of the day you only want your source code in SCC and maybe project files (word docs etc....) As Crelf recommended I would review your reuse strategy, whilst others like to check in/out directly into vi.lib etc... (so there must be some logic to it?) I prefer VIPM, and it would be a good place to start for you. That way your dist code is under vi.lib (etc...) but your src can sit where-ever. -JG

Jim I am pretty isolated wrt LabVIEW and I have found nothing beats online resources, in particular LAVA. There are a wealth of really talented people that will give you help and advice as long as you put the effort in too. There is also a repo full of good stuff, not to mention histories of posts that may have already answered your questions. Sure, i'd kill for a mentor, but if you don't get one don't freak out.

Off the top of my head I can think of a few reasons I like to (or have to) use Projects: Individual application instances (avoiding collisions) Working on targets e.g. Real Time and FPGA - I don't think there is any way around that You need to deploy Shared Variables from a Project, you can't do it just from the Library Creating Libraries/Classes/X-Controls Configuring Inheritance So I am the opposite, I rarely don't use them (by choice or otherwise)

Nothing compared to your Priscilla comment. Shazza

Really? Then what do you call something that looks like this? Queued State Machine, Queued Message Handler, QSM with event structure, etc... I know what NI call it and what others have called if for years so I am happy to stick to that (even though if taken literal it may not be correct, but I am no software engineer and can't be bothered arguing semantics here) Anyways, I was just pointing out how handy the Linked Tunnels feature of LabVIEW is - I think its great. Hey, that was one time, and...

I have been working in 2010 for the last two months, but full time as of late. In the IDE I have not noticed a slow down when things do edit-time compiles. But I am using a 3GHz i7 with SSD so I may be biased. I have seen terrible IDE performance in 2009 (launching, opening dialogs - esp app installer) that was made faster by re-imaging PC. OOI: AQ told me last year that NI have found the location of the installation on the HDD can affect performance and had an active test rig setup for this. I have had more dramas with edit-time compiling on FPGA. But again I have heard that NI have been working on this too

@ ShaunR - I have no idea what you are talking about. Have you never responded to more than 10 events on FP and had to wire data through each case?

Local variable should not be used to 'store' data. This is really bad practice. And if you really want to be anal they should only really be used to update a Control's display. If you use a template and lay it out, you should never have an issue with space. Like Shaun I sometimes use a couple of SR registers (for example, a private dynamic event refnum so I don't have to type it and keep updating it) but I always leave enough space so that I don't have to move code. Also since 8.6 you can set the tunnels to wire through automatically, which is a really cool feature.

I normally use a single SR (cluster) per module (SM) and if by design or if data gets complex (I.e. it should be encapsulated) I usually use classes within the cluster (to manage the data easily). Modules can call other modules, like the posts above.