Leaderboard

I've updated it to use a tree control. It indents states based on the presence of "-------" in the state name (ala JKI State Machine) assuming that these are section headers. Everything between them will be indented from the previous header and structures without this format will be presented without indenting anything. I also made it require a double-click to select a state so it would still be possible to expand/contract sections. The position of the scroll bar is persistent between calls (for the same Case Structure), but all sections are always presented expanded. CaseSelector.zip

And here is an example of an RSS generator. Ton

Dynamic dispatch means that you don't know at compile time which VI will execute, and it would be impossible to preallocate a clone of an unknown VI.

In order to manipulate the data received in an RSS feed, you need to be able to parse XML. Rather than coding this yourself, you might want to look at the JKI EasyXML Toolkit. It includes an example for reading RSS feeds. http://jkisoft.com/easyxml/

Name: Insert Type Conversion RCF Plugin Submitter: François Normandin Submitted: 21 Jul 2009 File Updated: 03 Jan 2011 Category: JKI Right-Click Framework Plugins LabVIEW Version: 8.2 License Type: BSD (Most common) Insert Conversion Node RCF Plugin v1.2.0.7 Copyright © 2009-2010, François Normandin All rights reserved. *Plugin* Name=Insert TypeConversion Summary=Inserts a type conversion automatically Description=Will insert type conversion for all strings, numbers, paths, variants & enums to the right datatype. Copyright=Copyright © 2009-2010 François Normandin License=BSD Developer=François Normandin Version=1.2.0.3 *Plugin* Author:François Normandin Contact Info: Contact via PM on www.lavag.org LabVIEW Versions: Created and tested with LabVIEW 8.2 Tested with 8.6 and 2009. Dependencies: jki_tool_right_click_framework >= 1.0.2.208 oglib_array >= 3.0.0 oglib_lvdata >= 2.9 Description: This package contains a plugin for the Right-Click Framework of JKI. It consists of a first draft of a tool to automatically insert correct conversion node on a wire (or multiple wire at once). Includes: - Decimal String to Number. - Float String to Number. - Any numeric type (int, unint, floats, complex) to any numeric type. - Variant to string or numerics. - Numerics to Variant. - String to Variant. - Path to String. - String to Path. - Boolean to string. - Enum to String. - String to Enum. - Numeric to Enum. - Numeric to String - Unbundle cluster to terminal indicator. Instructions: After installing package with VIPM, restart the RCF framework. Use the right-click on wires to automatically insert a conversion node if needed. ** VIPM 2010 or higher is required to process this package. Known Issues: 1- Not all typecasts are implemented. 2- Wires with joints will not behave correctly yet. Acknowledgements: JKI for providing with this great framework. Change Log: v1.0.0: Initial release of the code. v1.0.2: Added _rcf_ in package name. v1.0.3: Changed the typecast name for proper "type conversion" name. v1.0.9: Added readme file into .vip file package + some VI documentation v1.1.0: Changed name of package from normandinf to lava (lava_lib_rcf_insert_typeconversion.vip) and added some type conversions (Boolean to string; Enum to String; String to Enum) v1.1.3: Fixed bug with conversion from Enum to Numerics. Added conversion from Numeric to Enum using "Variant to Data" node. Added a lame icon. (Any user suggestion will be considered for next update!) v1.1.4: Updated the description of plugin that now shows up to date info in RCF Options menu. v1.1.8: Fixed bug when a type conversion node was inserted in a structure where the node was inserted on the main diagram. Saved for LV 8.2 v1.1.11: Included all files in source distribution to make compatible with LabVIEW 2009. v1.2.0: Added Unbundle cluster to terminal and corrected problem with Numeric to String. v1.2.0.7: Added Singular to Array & Array to Singular. License: Distributed under the BSD license Support: If you have any problems with this code or want to suggest features: please go to www.lavag.org and Navigate to the discussion page. Distribution: This code was downloaded from the LAVA Code Repository found at www.lavag.org Click here to download this file

Agreed, classes get typecast... I'll repackage it as "Type Conversion" and repost. I'll have more type conversions ready soon anyway.

VERY NICE!!! Minor technical point: the operations inserted are not really a type cast, but a type conversion -- casting means changing the type, but not the data; whereas conversion involves changing both the data and its type.

Here it is. Unzip the contents into [LabVIEW]\resource\JKI\RCF\Plugins\CaseSelector Use: select a Case Structure, apply the RCF Menu Activation Keys, right-click and select CaseSelector. A resizable list will be presented with the selected structure's cases. Select one of the cases, the list will disappear and the selected case will be brought to the front. I'll certainly use this functionality, but I may prefer to put a VI in the LabVIEW project folder (so I can have the list persist as a floating dialog). So. Is this anything that you'd use or do I have a unique situation? CaseSelector.zip

Sorry for doubleposting, but where is the edit button? [edit]THIS post has edit button, previous one had not (even when it was the last one) [/edit] I'm not too convienced that it looks too much like BD and why it should not, but ok - what about this? (background color is same as current one) Yeah, the Web 2.0 style... forgive me.

Here is a great piece of knowledge base from Adam Kemp. Twas posted on Info LabVIEW earlier this year. It maybe the reference you are thinking of? The PowerPoint is a good read. I agree. But as Crelf pointed out - if its a GUI then of course you are going to have FP objects inside the case structure. But its not then, yes, I too prefer to have them outside for a couple of reasons: I can define optional default values - or just select "use default if unwired". This is important e.g. on a basic SubVI with Errors I can pass the reference through the "in error" case, and not lose it (just like the LVOOP templates) It is much neater and easier to read (for me) - I can see what goes in (LHS) and what goes out (RHS) as nothing is hiding anywhere. Leads to optimised code (as per Adam Kemp's post) It helps me maintain a standard interface to the code module. If I am not building a class, but a standard Multi-Functional VI (MFVI) I usually have 1 input and 1 output - normally type-def cluster (sometimes variants) to the module for data (and also the Command Enum and error in/error our clusters). This makes the interface flexible, maintainable and scalable. And I don't need to handle a bunch of default values. Wrapper VIs bundle the inputs into the interface and they also pull out the required outputs from the interface for that method call into the connector pane. So the API is just like a basic SubVI to use. Any used values are disregarded.

Sure! Our plans for VI Tester (and other JKI Labs products) are to continue to improve the product and make it freely available, but with no promise to actively support and market it with the same rigor that we would a full-fledged JKI Software product. It is not our intention to take away your ability to freely use the JKI Labs version to assist in your development. You can rest assured that JKI believes strongly in the philosophy of "do no evil"

Here's a reference on what unit testing is all about: http://en.wikipedia.org/wiki/Unit_testing My summary is this: unit testing is a software engineering process for validating that your code functions as expected. You basically write tests to validate that your code works as expected, if your tests fail then you update your tests or your code until they pass. If all of your unit tests pass, then you have a level of assurance that your code works as you expect (as defined by the unit tests). What is useful about unit testing is that if you need to change your code (say, to make a sequence into a state machine), and you have created unit tests, you can validate that none of your changes have caused you to 'break' your previous logic simply by re-running your unit tests. In order to make you application logic more easily testable from your hardware interfaces, you may need to consider how you will test your code when you design your code. For example, you may want to create a simulation mode or abstraction layer that lets you test your application logic with unit tests, independently from your hardware interface code.

After a year of doing something from time to time, investigating various flash generation libraries and turning whole the code up side down, we have another prerelease of VIpreVIEW (interactive preview of VI in flash). Visually almost anything was not changed and actually even code looks similar as in previous version (best ideas come at beginning), but: it is much faster (speed is already reasonable) flat sequence works (however it is implemented pretty ugly) fixed issue with showing labels from not visible frames fixed issue with additional 1 px border its is much faster (repeating this because I'm so proud of it) and what even better - it still may be faster (and I know more or less how to do it) Below some instructions copied from the first post: The main file is VIpreVIEW.vi. You have to open it, fill all paths, sizes, etc. and run (not very professional, isn't it?). After some work (depending on VI complexity) it will create a lot of files at target path. Most of them are temporary files, but I do not delete them yet for debug purposes. Open {name}.html file in a browser and watch the result. I included SWFtools binary in this package (it's GPL). Comments as always are welcome

QUOTE (crelf @ Jun 5 2008, 06:54 AM) attached is the code that i was trying to modify. i found this code on one of the NI website pages. Thanks, Leen