jgcode

Hi Dave Someone might be able to reply with a better answer who worked on older releases as I was responsible for upgrading the sources to VIPM - I know there was scripts that updated labels with build information (I know as a wrote code to remove these artifacts) but AFAIK the license stuff and documentation was static. Having said that it would be super easy to script code to find a label (which had e.g. a tag on it) and update the VI Properties Documentation or vice versa.

Great news - congrats on the new role AQ. I say we lean on Mike?

I don't 100% follow the above (I think our definitions of things are different - but that's ok). If it helps here are my posts in summary: I agree with using FGV/MFVI/AE's etc... on a module per module basis I think all approaches discussed are valid - there are good reasons for both (I particularly find ShaunR's perspective in his last post above very interesting) I just personally prefer creating an API for a module I really like the 'LV2009' approach and hence wanted to post it in this thread to share with the OP

Haven't tried linux distros (don't know what DAQ drivers are supported anyway) but I have had success running DAQmx in Window VM's with the later VMware releases (as opposed to a few years ago).

No probs!

.. funny: 'haha!' or funny: 'weird?' ??

It's a visual indication that the object is linked to a typedef. See this idea.

I was able to answer this question regarding if CC licenses were suitable for LabVIEW code when I was researching for another thread. From Creative Commons website: Good to know

This thread is slightly depressing because the whole reason the community exists (IMHO) is to share ideas/issues/code relating to LabVIEW. E.g. If I post code (to a thread) on LAVA (or NI or wherever) I don't really care about people copying it - this point is to share. I also want to take other people's posted code and use it if they e.g. present a solution to a problem I am having etc... In both transactions I do not care or can be bothered with Attribution. However, if code is posted in the LAVA-CR then yes, it should be licensed (and has to be as per LAVA-CR rules) - so that is a different case. Either way, if there was a license then it would be respected and followed. Regarding licensing I did do some digging and came up with this: CC0 is a license designed for posting in the public domain (and therefore waiving your rights) and compatible with software. This creates Non-Copylefted Free Software which, if there was a default on LAVA (??) I would vote for CC0.

Nice! Here is my contribution to find an object's name // Custom TypeOf Function function returnObjectType(object) { // Constructor has syntax 'function Object(){ [native code] }' var typeRegex = /function [A-z_][A-z0-9_]*\(/; var testType = typeRegex.exec(object.constructor.toString()); // Parse and return the object's name, otherwise return null if (testType != null) { // Slice off leading 'function ' and trailing '(' to resolve object's name return testType.toString().slice(9, -1); } return null; } // Test returnObjectType function // Constructor for Data Type function UserDataType() {} document.write(returnObjectType("hi") + '<br />'); // returns String document.write(returnObjectType(2) + '<br />'); // returns Number document.write(returnObjectType(true) + '<br />'); // returns Boolean document.write(returnObjectType(new Array) + '<br />'); // returns Array document.write(returnObjectType(new UserDataType()) + '<br />'); // returns UserDataType[/CODE]

Not to go off topic - but doesn't typeof just return 'object' in javascript for any user defined data types? E.g. function Test() {} alert(typeof new Test()); // alerts 'object' [/CODE]

Apologies - yes that works.

I reckon this package would make a great OpenG candidate.

The OP does works as each PRTC primitive will return the class' default data (which when compared will be equal if they are of the same class) because the code forces an error (at the PRTC). <edit> That doesn't work as if the class' are of the same type no error will occur at the PRTC - so if the class are the same, but contain different data the equality will fail (when you want it to be true).

IPB has no built in spell checker (although from searching it seems people have made mods in the past). But I don't think you need one as e.g. Chrome does spell check automatically - no plugins (I use Chrome). Firefox has this option: What browser you using?

I agree - comparing this to e.g. traversing/working with the DOM; you have an appendChild() method which adds the element to the end of the parent's existing child nodes, and when position is important you have insertBefore() method. But I also agree with this - it's definitely something you get used to / don't even think about too much after using LabVIEW for a while.

I could be wrong, but I seem to recall there was a post made a few years ago that stated that we are covered e.g. under some CC license by default, if we post code to LAVA? I couldn't find that info in the forum guidelines tho. I am sure a mod could answer this question. In terms of NI - there is this thread here with some interesting info.

No probs. Thanks for the update.

I agree with Shaun to make the distinction for the purpose of discussion. And yes, if you define accessors then they should get/set one piece of the internal state data. (because that's what accessors do). In the examples I have posted I haven't mentioned accessors - I have been talking about supplying inputs/outputs for methods (I guess that's a distinction made there) - and the issues I have with that in the past and trying to make it more robust. I wanted to present other way of creating an AE using a DVR-IPE.

I agree. If I find myself in this position then it means that I want to call code in the Event Handler. Simply refactoring it out into e.g. it's own case, solves the problem.

Saying that a method only has one argument most of the time is a pretty big assumption! It is going to be totally dependent on the module.

There is no boilerplate code with the DVR (that is why it is less coding). Sure data is bundled/unbundled but this is the state data i.e. the data that is persistent for that module - same as in an AE: I don't agree with sharing inputs for methods. Yes, it may appear advantageous to share them initially - especially if a module starts off small. But it violates encapsulation (and I aside for that I find it confusing). What if we have to change the inputs for Method 1 in the future - how do we know that it won't affect any other methods? We don't. If each method has it's own input/output cluster then we can confidently make changes to that method. We do not need to worry about this with the DVR-IPE implementation. In the example you are referring to, this is your method's interface: In order to reuse your states you have created an input Enum that is a subset of your module's Command Enum - now they are coupled to each other. A change will mean you will need to make a change in two places. Now this method interface can still be replicated using a DVR-IPE - and I think it's cleaner/more-robust (just throw in the paths):

Thanks! And no It does not have to be a class, here I changed it to a cluster and updated the DVR refnum and the rest of the code stays the same (in that example). Ok, so now you have a wrapper methods and you have created a robust API IMHO - I like this API think it is robust like the DVR and the AE I posted e.g. you could change the implementation of underlying code (from DVR/Variant/AE) and it would not affect the API or end user. However, I would disagree that it less work than the DVR module I posted: So the example I posted (and you modified) is quite simple. How are you going to handle multiple inputs for a method? E.g. each method has 2 or more inputs. For your implementation (variant) I see two options (there may be others?) More Variant inputs on the CP of the AE Or the interface to the AE stays the same and you create a typedef Cluster of the inputs for that method and convert them back on the other side. In (1) more variant inputs could get messy fast and hard to manage in the AE? In (2) creating a Cluster means that you are going to have the exact same issues I have highlighted in terms of boiler plate code. So the typing issues has to do with the inputs/outputs to the AE not the state (persistent) data of the either module. The DVR is the state (albeit a reference to the state - accessed safely using the IPE) The DVR method inputs/outputs do not need to be isolated/grouped/protected etc... as there is only a single VI that will use them. In order to handle multiple inputs I don't have to do anything special, thus this makes the DVR less coding. IMHO the classic AE is not as robust, I have already addressed the following as to why I think it is not and why it should be wrapped to provide a more robust API to the end user: Additionally the Command Enum should be private/hidden as e.g. this will not allow user to run private methods. <edit> For discussion here are some images of the Variant implementations when I had to increase the number of inputs to a method: 1. More Variant CP inputs: 2. Switch over to a cluster:

Yes, I use the disable structure for testing too (as you mentioned because it's easy to switch back if needed). But I have not used it to facilitate discussing/commenting code.

I have never seen (or thought of doing) this before reading it here. Do any other developers do this?