LAVA 1.0 Content

QUOTE (b_subhasis @ Sep 2 2008, 08:11 AM) That's not an easy task. http://www.carya.nl' rel='nofollow' target="_blank">Carya has a toolkit to build PDFs Ton

The problem is that you can't establish a connection. Strange, what error code is generated on the LabVIEW side? Ton

QUOTE (Ton @ Sep 1 2008, 02:19 PM) Tagging? How about retiring. I should have remebered that. How to old ways die hard. Ben

QUOTE (JiMM @ Aug 31 2008, 06:00 PM) QUOTE (Michael_Aivaliotis @ Sep 1 2008, 09:16 AM) Yes, it's a neat way to organize your VI's but an OS folder can do that too. One of the primary benefits for me has been the ability of a project to wrap your code in a project namespace. You can open two or more projects at the same time and VI's within those projects can have the same name but you won't have the problem of cross-linking. One word of caution on projects. If you decide to use projects, you MUST use projects all the way. What I mean is that the very first thing you open, to start your work, must be the project file, not the VI. It's the boss. QUOTE (Darren @ Sep 1 2008, 10:03 AM) I was primarily responding to the "as usual" comment. Anyway, my favorite use of the project is the built-in SCC. Being prompted to check out a file that I don't have checked out whenever I start trying to edit it is really handy. QUOTE (crelf @ Sep 1 2008, 06:02 PM) ....The project gives me a layer of abstraction from the disk space, so I can arrange things however I like. I think this is one of the least-talked-about features of the project environment, but I love it. I also suggest that this is where the overall computing world is going... I've started a seperate thread on (needed) project enhancements in the LabVIEW wish list. Ton

This post is a try to group several project-related wish-list items into one discussion. Based on recent discussion (1, 2), I felt there are some things missing to make the project the super-duper LabVIEW IDE enhancement. The things that are currently lacking (IMHO) Set a description for a virtual folder This allows you to group VIs under a folder that has a better description than the name of the folder Setting 'Conditional Disable settings' in the build-properties Better Build-toolsThe possibility to set the version of an executable and an installer in one location Have dynamic built location (builds\executable\%version%) Have the possibility to edit the GUID of an installer [*]Update the SCC settings when they are edited from within LabVIEW code [*]Allow extending of the context menu-items of project items [*]Copy build settings from one project to another Share your thoughts, fill in the poll and respond, make the project perfect. Ton

QUOTE (neB @ Sep 1 2008, 05:11 PM) Ben, you should really start tagging, it took 10 minutes to find this http://forums.lavag.org/Video-Objects-and-Classes-t11336.html#' target="_blank">post Containing this way to instantiate an active object via reentrant clones: Ton

QUOTE (Aristos Queue @ Sep 1 2008, 09:51 AM) Hmmmm.... Opening them with the 8 (?) switch and run as the sub-VI of a template maybe. I'll have to think obuout how I can do this. I'm trying to instaciate Active Objects of a class and am trying to figure it out as I go. Thanks, Ben

QUOTE (Aristos Queue @ Aug 30 2008, 10:44 AM) I recently reported what I thought was a bug. A VI created from a template (where the template is a member of a class) using the Open VI >>> Invoke node run mtehod will not run if it has protected or private methods on its diagram. The invoke node returns an error and looking at the VI created from the template shows errors on the class wires. But the emplate does not have a broken run arrow. It looks like the template is being created "outise of the class Library" so its use of bundle, etc are not allowed. I worked around this issue by creating public accessor VIs and I was able to move on, BUT This bug seems to bear witness to the fact the VI itself does not know it should be part of the class library. So maybe what I reported was not a bug? Ben [OT:Q Does anyone know how to use a VI template that is a member of a class? Knowing that would let me reduce the scope of most of the sub-VIs back to what I originally intended, Thanks!]

QUOTE (jlokanis @ Aug 31 2008, 06:37 PM) Yes I have shared app's with hundreds of VIs to support to demo bugs that only happen in large aps. Is there a possibility the launcher is going idle? Ben

QUOTE (crelf @ Aug 30 2008, 03:54 PM) I think 'hinted' would be a better word to indicate what I've read. The 'privatism' of VIs is set in the library properties and nowhere else, this strengthens my believe a VI doesn't know it's state. Furthermore if you use a private VI outside it's scope the owning VI is broken and not the private VI. Ton

QUOTE (JDave @ Aug 30 2008, 06:54 AM) Yes it would. Let me explain: The VI itself is unaware of it's 'privatism' (as http://forums.lavag.org/Visual-Indication-of-VI-access-scope-On-the-VI-Itself-t11825.html&p=51201#' target="_blank">AQ pointed), so you should get a reference to the item in the LVLIB, get's it status from the lvlib (if the VI itself is 'public' you should check every owning folder as well). Not very easy. Ton

QUOTE (jlokanis @ Aug 29 2008, 04:04 PM) Hi John, I'm not sure if the following may be what is hitting you but you did ask for "other ideas" When a VI is no longer running, all of the resource tht were allocated by that VI are destroyed. That includes queues. So if the Queue was created in a VI that goes idle the queues it created are destroyed. The work-around it to make sure the VI's that creaed the queue don't go idle until after the queues is destroyed. Ben

How about... Invoke node >>> FP.Open and wire a "hidden" constant to the "State" input? Ben

The search page misses (at least) the Tag Cloud in the upper pane. Ton

QUOTE (Darren @ Aug 29 2008, 12:10 PM) Thank you Darren! Ben

QUOTE (Darren @ Aug 29 2008, 11:50 AM) OK Darren. I'll play the game by the rules. I am goinfg to have to work to collect all of them since I don't have all of the same setting in all of my ini's since I don't need all of them all of the time but will go grab them when I need it. Could you urge the people involved in this effort to please run the list of tokens that will be eliminated through the "LAVA grinder" (or at least the LabVIEW Champions forum) before work is started? Sorry about making trouble! Ben

QUOTE (Darren @ Aug 29 2008, 11:33 AM) Hi Darren, My concern is rarely used tokens being dropped. e.g. The token that tells LV to show the full file path in the Hiearchy screen. I feel the few people use the hiearchy screen as much as I do and of those fewer still want to see the full file path. If I am the only person that submits an ini with that token used, then that token may be dropped. So if we work together on the token we do not want to see removed, then we are protecting ourselves from loosing options that we may not all individually use. By cooperating we can avoid potential losses of functionality. I'm open to hearing what others have to say (either by their responses of their silence). Ben

QUOTE (Phillip Brooks @ Aug 29 2008, 07:43 AM) Oppertunity? These types of calls for info end up being concidered representative of the cummunity at large. Before I send mine I'd like to here from Y'all which ini tokens you are using so I can include those in my ini. Think if it as "stuffing the ballot box" with votes for scripting etc. If they go through this study and don't find an entry for something we use, we can assume that option is going to fall away. "Just messing with the system" Ben

QUOTE (Michael_Aivaliotis @ Aug 29 2008, 08:16 AM) Confirm. Ton

Why is everyone forgetting LVLIB's and XCTL's when they are talking about 'private' and 'public'? Ton PS I think this is a good feature request

I was looking for that thread where I believe Jim and crelf were getting silly and eventually came up with the title "Certified LabVIEW Code-Monkey", or something to that effect. I was not able to find it using the LAVA search or even Google. Maybe I am mis-remebering the thread (or it was just a dream) but does anyone know how to find that thread? Ben

Unless I mis-read you the reason they could not be found was tht they were not loaded. A "cheap trick" that use to work was to put an instance of the dynamically called VI in a non-executing case structure so that the VIs are part of the top level app. This will forrce the dynamic VI to be deployed with the app. Also watch your file spec since the specs change in a exe. If you are using an invoke node, call by reference, I think you can now single step into that call and debug as normal. I also seem to remember that if you single step into multiple re-cursive calls you want to get out of all of the re-cursive calls before stopping LV to avoid a crash. (Just a friendlt warning) Ben

QUOTE (jdunham @ Aug 28 2008, 01:06 AM) Ditto that. Ben

QUOTE (P. Rosegger @ Aug 27 2008, 01:48 PM) I'm sure I will not remember all of them but ... Use the Hiearchy screen and do a ctrl-a to find the re-entrant VI's. Find the re-ntrant VI on a diagram and double click it to open the FP of that instance of the re-entrant VI Ben

QUOTE (Michael_Aivaliotis @ Aug 27 2008, 09:01 AM) I can't tag, the little popup comes up, if I click go I get a blank page. QUOTE (Anders Björk @ Aug 27 2008, 04:12 PM) I would agree on the value if you could select the previously used tags (or even get suggestion on the right tag), but without streamlineing tags it is no better then a regular search on posts. If I add a tag to a post (I tried 'tag' on your last post) I get some options (VI Tags, Tagproposal) so that is streamlined. I labeled some posts as 'spam' to indicate I think those posts are spam (besides that I reported it to the admin). This way you can express your opinion on a post. Ton