Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 07/21/2015 in all areas

  1. So here is a fun little nugget I worked on over the weekend. At our local user group there was discussions about action engines, and functional global variables. People talked about how a Action Engine, that has several cases like, Init, Read, Write, Close, will have inputs and outputs that just aren't relevant to every method of that VI. So people said how they some times write wrappers to their FGV where each VI is a unique value for their enum. This allows them to delete the unneeded controls and indicators, making for an easier to understand API, where only the important inputs for that method are exposed. So I wrote some code to demonstrate how to accomplish this with scripting. I figured this function might be useful to others. Included in the zip is an example VIG that can be used to demonstrate how it works. FGV Wrapper Maker.zip
    2 points
  2. I was wondering -- I would be curious to get full metrics for my latest project -- including not only number of .vi, .ctl, .lvclass (these I can grep from the file list, or from ls -R * |grep \\\.vi | wc -l ), but also number of global variables and where used, list of unused project items, optionally some complexity metric for all vis, which vis are password protected, which are on which execution system, and whatnot. I suppose that it would be possible with a bit of effort to put together a script for that, but is there out somewhere something ready made?
    1 point
  3. The more you explain, the more confused I get.
    1 point
  4. I do this as well. But I take it one step further and have it all inside of a library. I then make the Action Engine and the enum controlling it private. This makes it so that the API is nothing but the wrapper VIs. It helps by keeping other people away from the AE and screwing something up. I can't wait to look at your code here. Sounds like something I could possibly use.
    1 point
  5. Nice Idea, I always have the problem with connecting this enum and unbundling what needs to be used from cluster In one project I ended making polymorphic wrapper in similar way You did and then unbundling what is needed inside wrppers. It takes some time doing it one by one and they all look the same so it is bit confusing but if polymorphic vi can be scripted on top of that wrappers it will be nice Edit: added polymorphic vi generation after Edit2: if there could be easy way to do bundling/unbundling by scripting, not by hand it would be nice fgv to polly.zip
    1 point
  6. I see. Yes, maybe someday I'll play and will put together a tool of my taste. Indeed I see that to get odd vi properties is not difficult; I quickly put together the following as a proof of concept without bothering for recursive descending of the project hierarchy and item discrimination, maybe on some rainy day.
    1 point
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.