jgcode

No, the LV2009 Singleton methods do not need typedef inputs. In the AE each method should access it's own data - it unbundles it's own inputs and in bundles up it's own outputs. The cluster helps enforce this which leads to more robust code. Additionally it standardises the API (i.e. CP) to the AE main VI. In the LV2009 Singleton example I don't need to worry about any of that as each method is a VI so it only uses those inputs/outputs. That is why I consider the examples the same.

Hi Darren The patch was for LabVIEW 6.1, 7.0 and 7.1 only so I am assuming it was fixed (by NI) along the way (but I don't know the history of this package). However attached is the bugfix (which is from this package) which you could compare. Cheers -JG Copy From Folder To Folder__bugfix.vi

I have already discussed this offline with Ton. After some minor changes that Ton wants to make the package will be submitted for review by OpenG. So the ball is already rolling...

Why? In terms of the module (as a whole) it's core is an AE, with the those AE methods wrapped. So to me it's an AE/FGV/MFVI/VIG etc... As mentioned above I do not think this implementation is robust (I am assuming the the Enum is not a type def for ease of posting). The first thing that come to mind from looking at it is that when I go to select a method I do not know which data I should set without opening the block diagram and looking at the code. This is a simple example, but what happens when the code is more complex? What if there 2-3 inputs are needed for each method and there was 5 methods? What if some inputs are required and some are optional - how do you specify that? It's going to get harder to figure out what is going on for the end user. Once you run out of room for inputs/ouputs then you will need to use clusters - exposing this data (clusters, enum) leads to higher coupling. Therefore by wrapping the AE I can provide a more robust API for the end user. And if I was to go this route I would prefer to implement it with the DVR-IPE as it's less coding for me. Don't get me wrong, writing AE as you have is valid, lightweight and works - I just think it can be more robust. Here is an example - unlike yours, it just some BS functions, but it demonstrates the framework: Each module has the exact same API - and that API is robust IHMO. The DVR-IPE is more lightweight it terms of number of files and coding. I am not saying this is the only way to make an AE more robust and I always like seeing different implementations. If you check out LabVIEW For Everyone 3rd Ed pg 910-912 they show a similar implementation but the main points about encapsulation are the same: Each method bundles/unbundles has it's own input and output cluster respectively and The enum command is wrapped by the method However, they pass each cluster as a connection on the CP where I prefer to use a super-cluster and one in and one out connection and I like to use some real estate to pass the input into the state data, but this is all programming-preferences/style and has nothing to do with the point I am trying making about robustness Robust AE.zip Code is in LabVIEW 2009

The class is the state data of the module (in this example!). This state data is stored in the shift register (in both the AE and the LV2009 Singleton) But as I mentioned before it does not have to be a class - it could be a cluster. No different to the state data of the AE could be a class or a cluster. But it has nothing to do with how the DVR-IPE works - so it can be ignored. Yes, an AE is a singleton. But no, I prefer using the DVR because it is less work. No, the clusters are all private data of the module - no clusters are exposed to the end user. The reason for having an (input/output) cluster per method (where needed) is so that each method's data is separate from another method. I.e. you cannot accidentally bundle the wrong data at edit time into another method. Then in the AE (main VI) you can unbundle that methods data easily. The input to the AE (main VI) is a super-cluster of the input clusters (and the output to the AE is a super-cluster of the method output clusters) - so the CP of the AE does not ever need to change - it's interface is maintained. The polyVI is just so you can drop one VI (the polyVI) and select which method you want. I like to do that when creating APIs. Both the AE and LV2009 Singleton could do this (that is why I ignored it from the stats). No, that would violate encapsulation. No, they are not class accessors - it is DVR based. But yes, each method is a VI. Accessing elements from the state data is the same as for the AE (you use unbundle). If the state data is too complex to manage then it should be broken down e.g. into classes or clusters or whatever - but this doesn't differ between the two implementations. No I am saying that if I want to create a robust AE I prefer to use the LV2009 Singleton method (or whatever you want to call it). To an end user, both will have the exact same API, but for the developer there is less code. Using the DVR with the IPE means that the singleton feature is not broken then rebuilt - it's simply implemented a different way from the get-go.

Sorry I do not follow 100% - do you mean you are wiring in the VI Name as a String or Path (as you have mentioned folder hierarchy and we are talking dynamic)?

Yer, these could be nice to have in OpenG. *I think* this is the CRC16 I have used in the past.

I believe I am, because I am comparing robustness which means creating the AE with wrapper VIs for the Methods. Yes and no - that image is equivalent to both a AE frame and it's Method Wrapper - as it has the same level of robustness (IMHO), but contains a lot less boilerplate code. I think you are getting hung up on the fact it has a Class in it? Like I said this could be e.g. a cluster, the benefits/how-the-framework-works in based solely on the DVR and the IPE (as opposed to a Class). FWIW here are my stats comparing the two (either one could have a polyVI so that is ignored): In this example I have the exact same API, where each has the exact same number of Methods (n). AE/MFVI with n Methods 1 x Main VI n x Methods VIs 1 x Enum TypeDef 2n x Method Cluster TypeDefs 3 x (Input, Output, Local/State) Cluster TypeDefs LV2009 Singleton with n Methods 1 x Main VI (FGV) n x Method VIs 1 x State Class/Cluster TypeDef The LV2009 code is definitely light-weight compared to the AE not only in stats but how it is coded. Of course all this is all based on my definition of AE robustness - like I said in previous post, you could use an AE with the enum exposed and have either: A variant interface A cluster interface - CP never changes but you have to do the bundling on the caller's BD Or no standard interface - where you could run out of CP inputs/outputs But all the above means the user does not know what the inputs/outputs are of that method, so they need to have intimate knowledge of the Module's design (plus coupling is higher). And yes, if you coded the module using 1 of these 3 approaches then the stats would be different. But IMHO I don't think either approach is that robust - so to me it was never icing on the cake, it was how I implemented a Module (AE).

I have built applications in the past made up entirely of AE's - which I am sure a lot of people did too before they had any OOP options available in LabVIEW - and I am sure they got it to work. IMHO being able to use the latest techniques is an assumption - are you coding LabVIEW RT on a brick running <=8.6? - I guarantee I will be using an architecture made up of AEs if you want some form of encapsulation. Nowdays I personally prefer LVOOP based implementations but on a module-to-module basis however, I think everything has it's place and it's up to the developer to decide what is appropriate for what use case. So as the OP is about robustness I just wanted to post different ways of achieving the implementation of (what I consider) a robust AE. Personally, I have never like the use of variants as the inputs and outputs to a AE as it means the developer has to know what data to supply to what method without any edit time checks. Additionally I do not like using the AE as the API as it means coupling the enum on the BD of the calling VIs - I like using wrappers around the methods (which is a call to the AE with an Enum constant). And then like ShaunR - a polyVI for the API. Therefore in order to add robustness to the AE I found myself creating a lot of wrapper code. This was worth it IMHO as the code was less coupled, more readable, easier to make changes etc... but the extra work was a PITA and I didn't have any other options at the time. AE/FGV/MFVI/VIG -or whatever you call it (This is how I used to do it) This example is just a template so there is not much meat to it. I use the term private below but I never enforced it literally e.g. with a LabVIEW Project Library - it was just a coding convention. Also an end-user knows exactly what inputs to use for the method they are calling as and inputs can be marked required, recommended, or optional as needed: I believe this solution is more elegant - it does require LV2009 as it uses DVR's but there is a lot less code. LV2009 Singleton (This is how I saw AQ do it) This uses a Class in this example - but it doesn't have to be (I just prefer it).

I am unaware of the history of the OpenG Slice String VI (maybe someone else could comment) but you can see from the Context Help that is has Python origins. Additionally, I know other languages, e.g js, has both a slice and substring function too. And whilst you are correct that the end result could be obtained using either function (e.g. use either function to get 'BC' from 'ABCD') - each function has it's differences (and preferred use cases). E.g. Slice string accepts negative numbers to index backward from the end of the string etc... However both work on Strings as opposed to String Arrays (as per your proposal) so (aside from the above) I think it would be better suggesting a new VI as opposed to revising and replacing the existing Slice String VI.

No probs What is the definition of careful? Are you able to install the patch as a single-package install after it has failed in the original-multiple-package install? If not what happens? Posting these specific errors could be helpful? Ok. so thinking logically but with limited information I am making the following assumptions based on that You are getting errors in the install You are missing the VI where it should be From what you have said So it seems logical to conclude that on your failed systems the following is happening: The pre install script is renaming the original VI to _buggy The post install script is not renaming and moving the patch VI The post install script must be generating an error This error may report back to VIPM and thus VIPM is stating the package had a failed install Here is the code from the scripts (its pretty simple code): Pre-Install Code Post-Install Code (I am assuming this is the code failing) . So I was trying to work out what was happening- this would be a good starting point. Let us know what you find out. Cheers -JG

I could be wrong but I didn't take that as what jcarmody was saying (as in the context of the conversation I would not be the one using the CCT to post a snippet, Wouter would be) - I took it more as eating the LAVA community's dog food. And yes, I am not a CCT developer - all props to Ton and Yair

Danny I am glad you like the work on OpenG, and yes LabVIEW 2011 is very nice Happy Holidays to everyone on LAVA!! Thanks to everyone I have worked with, it's been another great year in the LabVIEW Community. Take care! -JG

Agreed! Seems something got messed up when I cut and pasted - I was able to edit it easily enough tho.

This was an interesting point and I had a look at this. Here is the same code in a text-based language: <script type="text/javascript"> // converts a string into an array, where each character is an element in that array function toCharArray(str) { var numChars = str.length; var charArray = new Array(numChars); for (i=0; i<numChars; i++) { charArray[i] = str.substr(i, 1); } return charArray; } </script>[/CODE] The result? I find that the code is self-documenting - if I use good variable names. I have added a description of the what the function does - but to me this is the equivalent of VI documentation (so maybe it should have been copied to the BD). So the documentation is ok if this is how we convert the LabVIEW code in our heads when we read it. I guess one thing that is missing is variable names - we specify inputs and outputs nicely in LabVIEW, but maybe labels on the wire should definitely be used in the example. Note: ToCharArray functionality already exists in js, this was just an example. [CODE] <script type="text/javascript"> var str="OpenG.org"; var toCharArray = str.split(""); </script>[/CODE]

As mentioned above - VIs should be posted, as well as (or opposed) to snippets, for reviews. Save for Previous would be a better workaround to host the VI. Snippets are good to view the code in the browser (same as posting an image).

This is a very interesting topic thus far, as it has gotten me thinking a lot! I agree that OpenG should comment code well and lead the LabVIEW Community with best practices. A lot of the OpenG functions are small and readable, but others aren't or require some background knowledge which should definitely be added. On average, I haven't seen this level of documentation in OpenG VI's yet (no saying we shouldn't start). On more than one occasion whilst editing OpenG code, there has been a lack of comments (or no comments) and I have added comments (as I was figuring stuff out and thought it would be handy for the next developer to know). So in the submission of new VIs, we should really aim to get this correct. Therefore feedback like this (from anyone) for a VI would be really handy during the review, so it could be discussed before release. However I think we should focus on entire topic: Given the current feedback (and other end users please continue) - What should the aim of our documentation be? I (personally) think the the number one purpose should be to help the reader understand (i.e. read) the code. I think this means that we need target a certain LabVIEW level of the end user when we do this. How low (or high) do we set the benchmark? Should we target the lowest common denominator (newbies) and add comments on wires, for loops etc...? Or should we be doing this anyway? Should we show the names of the functions (primitive label) etc...? Do we assume the user will use Context Help if they are unsure about a primitive (or argument(s) to one)? Would all this commenting be annoying for the average user and make it harder to follow? In the past I have been aiming for intermediate end users (like CLDish level) which I assume would be the average user of OpenG. I.e. I assume they know the function String Length and it's behaviour. The BD is not the only place for comments, there is also a VI description in this case. So the VI in question is understandable to me without the suggested documentation and is why I never bought it up as an issue in the review (nor added it at a later date). However the suggested documentation wouldn't hurt - I just think we should be (or start being) consistent across the entire OpenG Libraries. Agreed, that information could be handy in this case e.g. that this implementation was slower: As a side note: Maybe a link to the review would be good (more work to possibly maintain for the OpenG Developer)? - This is all traceable through it's SoureForge artifact tho. So in re-reviewing this VI based on your comment: At the time I thought the Trim Whitespace has sufficient documentation as well (I personally added it). The ASCII table was also programmatically created and is documented (this is more for OpenG developers though and is not included in the released package). I personally sit slightly on the other side of the fence here - I would prefer a little bit more (clear and concise) documentation, even if it was slightly redundant to the code. However, given this thread I think it raises another question: How (well) do people read LabVIEW Code? For me I find that text is always more understandable (and faster to understand) than LabVIEW code. However, I can quite happily work my way through the code I have posted above and figure out what is happening easily enough. Is this the same for the average user? And should e.g. Trim Whitespace have more documentation - I am now thinking yes. In summary the LabVIEW End User Level we are aiming for and therefore the content/amount of the documentation should definitely be identified, reviewed and standardised for OpenG practices (along with the assumptions we make about everything). This thread is a great place to do that.

Yes, please post in LabVIEW 2009 (however, I understand that you may not be able to) It's just going to make the reviewing process more difficult. Additionally proposals should be VIs not snippets. Cheers -JG

Thx Jim

Hi Bob I don't have LabVIEW 7.0 installed but I just downloaded the packages from SF and had a look at for you. I ran all the Librarian Patch pre/post un/install scripts (I just had to modify one case statement to install in LabVIEW 2009) and it all worked correctly. Additionally I checked the Notifier package and neither the spec nor the scripts interact with the Librarian destination - so I don't think this would be an issue (unless there was an error passed along during a multiple package install - but I don't think VIPM works like that?) Seems weird you are missing this Vi across multiple installs you have tested (I was initially thinking some folder/write permissions issues)? My recommendation is that you unzip the package and try a manual install - move the "bugix" file to its installed folder, run each script in order and see if it reports any errors etc... this is what I just did above. That may shed some light on your issues. Look forward to hearing what you uncover. Cheers -Jon <edit> Can you provide a cross link for this post? I could not find it by searching your topics in the JKI forums.

This is obviously an IPB thing - not sure if feedback is given by LAVA to Invision Power etc... But it would be good if you could either: Edit tags directly without having to delete the whole tag Not having to delete all tags to the right of a tag to edit that tag Separate the first tag into it's own textbox so it can be easily edited The reason being I have a use case where I update the first tag (which is displayed with the Topic Title in the list) as a topic changes (over time) and I have to deleted all tags to edit it, the reenter all other tags. Boo. Cheers -Jon

Sometimes I find when I go back in to edit the starting post of a topic, the Use First Tag as Prefix checkbox is unchecked (when it was previously checked). I think it may be a bug. Curious to know if anyone else has seen this issue.

My post above was relating to dynamic in the sense of lazy loading. The Static VI Reference approach will load the VI into memory when the called VI is loaded. So it really depends on what the OP is trying to achieve. Using the CBR and specifying a path with an appropriate setting may work? I have not used this method myself. I checked and the VI Hierarchy Window shows the called VI when the caller VI is only open (I would have thought it wouldn't?). Cheers -JG <edited>

I am very pleased to announce the release of the OpenG String Library 4.1.0.12 package as the features were driven by the LAVA community. This package will be available for download through VIPM in a few days. Thanks to Ed Dickens for helping to review changes. And thank you to everyone who participated in the online discussions. Changelog: [MOD] 3303663 - Format Variant Into String__ogtk.vi doesn't handle Timestamp [MOD] 3292424 - Update Trim Whitespace with Fast Trim [FIX] 3275381 - "Slice String__ogtk.vi" has Input or RHS of Connector Pane [FIX] 1958939 - "Scan Variant from String" missing description [MOD] 3275249 - Update OpenG Comment [FIX] 3386135 - OpenG Comment not Merge VI in palette [MOD] 1914597 - Format Variant Into String missing DAQ, DAQmx, and VISA type [MOD] 921506 - "Format Variant Into String" should accept RefNums [NEW] 3419755 - Create new String To Character Array VI Below are some of the changes in detail. New, Faster Trim Whitespace Code This was the first community review that integrated Shaun R's Fast Trim code which was further optimized by Darin K. The VI is ~7x faster than the native implementation! New String To Character Array VI Wouter proposed this new VI which splits a string into an array where each element is a character. The code was optimised by Fab and Darin K. Slice String Connector Pane Fixed The connector pane for Slice String no longer has an input on the right hand side. The original VI was deprecated. I64, U64, VISA, DAQ, Timestamp Support Added to Format Variant to String and Scan Variant From String One of the more requested features is that the Timestamp datatype is now supported in these VIs. ISO 8601 was proposed by Phillip as the default timestamp format however, you can specify any %T type formatting. Thanks to Mellroth with helping out with the format code. Once you have installed the new package, download this snippet to test for yourself: Kind regards Jonathon Green OpenG Manager

To call a VI dynamically you are going to have to: Know where that VI exists in a hierarchy (on disk or inside and .exe) Open a reference to it using Open VI Reference and the above path At some point, load the VI and run it Maybe it would be best discussing what you are trying to accomplish with your request? There may be another way.