PJM_labview

QUOTE (jcarmody @ Sep 6 2008, 07:41 AM) Welcome to LAVA. VIC20: Ah the good old time when one could do pretty much anything with peek and poke (Note: I start with a Commodore 64). PJM

Back on topic, I created a small utility that add a temporary overlay on the VI icon of the active VI (see images below). I put this thing together rather quickly so there is no warranties that it will work in every situations. Before After I use the following convention: Attached is the utility. Installation Instruction: Copy the entire "LVOOP Utilities" folder under your "project" folder in LabVIEW and then you will have a new menu under tools (once LV restart) as seen here --> Note: OpenG Libraries are required Download File:post-121-1220470490.zip

I will say that Ben is probably right. This has happened to me countless time, and every single time this was a lifetime issue. Scenario Example: Create Queue in a VI Put Queue refnum in LV2 Gbl Launch (asynchronously) other code that need the Queue (other code call LV2 Gbl) Create Queue VI stops --> Queue refnum become invalid because LV garbage collect it. --> Get error in you asynchronous code PJM

QUOTE (Aristos Queue @ Aug 29 2008, 08:21 AM) I agree that when writing a vi for the first time this is not useful at all (but this will be in future editing). I also agree with the glyph suggestion on the SubVI call (this is actually a great idea :thumbup: ). Note: In the my previous post entry, the screenshots were never intent to mean that I need the glyph on untitled VI. I guess I should have use an existing VI to add the glyph to. Sorry about that confusion. Basically, at any given time a typical LabVIEW developer has a fair amount of VIs opened (which he may not have written). There is currently no (quick, at a glance) way to know what is the scope of opened VIs. These VIs may have been opened through various mechanism (lvclass project view, VI Tree, Explorer ...); they may or may not be member of the class, they may or may not be utility reuse code. At the moment, the only reliable way find the access scope is to use the "locate in project" openg utility. So I think there is also a need for knowing the access scope of opened VIs (along with the "glyph on SubVI call" idea). PJM

I don't know if anybody else feel the same way, but I would like to have a visual indication [somewhere on my VI] of class member access scope (public, private, protected). May be a glyph in the lower left corner (where project namespace/instance is usually located) or somewhere else will really be useful. or Alternatively a word (public, private or protected) in the title bar (possibly activate through an ini key) will be good as well. PJM

QUOTE (NeilA @ Aug 28 2008, 05:26 AM) NeilA,As John mentioned, you could try the EasyXML toolkit. I just spent a few minutes to create a LabVIEW Data structure to accommodate your XML data (to read it in LabVIEW) and it work fine (see screenshot below). PJM

QUOTE (Darren @ Aug 27 2008, 08:01 AM) Daren, I there a way for you to share these shortcuts (I am the lazy type...)? PJM

QUOTE (JDave @ Aug 26 2008, 01:41 PM) Dave,From my perspective, I do not expect the icon editor to edit anything but the icon (so editing the icon description is not something I would do there). And as I mentioned earlier, I think and good icon editor replacement should implement all existing NI icon editor functionalities. PJM

QUOTE (giopper @ Aug 23 2008, 06:08 PM) Nope. There was two VIs (with a name) there. PJM

QUOTE (Chris Davis @ Aug 22 2008, 09:08 AM) I will have to side with Michael as well on this issue. The main problem about using the sequence structure is maintainability (in my opinion). In regard to redesign, I went through the excercise a few years ago to create a "n-button dialog" vi (similar to NI 3-buttons but with more functionalities). For more info about it see this blog entry. I used a state machine like architecture (more specifically a single loop string based queue message handler). Granted it is probably slower than Stephen implementation but I think that the flexibility and simplicity of this architecture outweigh the performance issues. PJM

Jeff, For once I am not blaming NI on this one. Windows gave me a BSOD and after rebooting and restarting LV this is what I got. I was just venting my frustration... Sorry about that. About improving the second dialog I think it should be consistent with the first one. You said: "we must not have any un-recovered files remaining in the autosave directory for the version of LabVIEW you are launching". What about having a cancel button that would archive the files (like there is a Cancel button on the first dialog) instead of a "delete backup files". Deleting file seem to be very drastic thing to do. It just does not feel right. PJM

Ok, lets try it. Oops wrong choice. So what now? I guess I want to delete my backup files (or kill LV)... A "Do nothing" option would have been helpful there. PJM

QUOTE (mross @ Aug 21 2008, 10:46 AM) I believe he his talking about space on the FPGA. From what I recall from a training I got on this topic (and this was a while ago), usage of sequence structure is "recommended" when creating code for the FPGA because it will result in more optimized code deployed on the target. PJM

QUOTE (neB @ Aug 21 2008, 07:07 AM) add me too. PJM

QUOTE (ragglefrock @ Aug 20 2008, 03:06 PM) Ya, but this is not really practical when you have SubVIS and typedef that you don't want to copy (because they already are member of the lvoop class) PJM

Little Background info. I am in the process of converting some pre-lvoop by reference class to LVOOP class (using the OpenG By Ref framework from Tomi). My customer found a bug (and fixed it) in the pre-lvoop class. Now I want to integrate this fixed VI in my lvoop class (every VI in the class folder are members of the lvclass). In older LV version (before lvlib and lvclass) replacing a VI was trivial and very fast. Close LV Overwrite VI with bug fix VI Open LV Relink and resave Now with LV class this has become significantly more convoluted and time consuming (or I am missing something obvious which is entirely possible). The previously mentioned method does not work at all (trying it does actually put the class in a state where I can't recover other than reverting the code to the pre-overwrite) The only way I could make it work is as follow: Open the lvclass in LV Remove the file to overwrite from the lvclass save and close LV overwrite file Open the lvclass in LV add the new file to the class reasaved Am I missing something? Is there a better (and faster) way to do that? PJM

QUOTE (JiMM @ Aug 19 2008, 11:54 AM) Works all the way to up to LabVIEW 8.6 (which is the latest LV release at the time I am making this post). PJM

QUOTE (Darren @ Aug 15 2008, 08:39 AM) I believe I did... http://lavag.org/old_files/monthly_08_2008/post-121-1218902291.jpg' target="_blank"> PJM

This is a pretty awesome application. Thanks for the link. PJM

QUOTE (Justin Goeres @ Aug 12 2008, 04:30 PM) Something is compelling alright. I am not sure that the evidence have anything to do do with it... PJM

QUOTE (crelf @ Aug 12 2008, 04:45 PM) Actually you don't need the 16 colors icon for that. Only the 256 colors and the B&W is required. PJM

QUOTE (JDave @ Aug 12 2008, 12:36 PM) In some instance for some type of icon (that are render blank in the B&W icon), you get the following LV error message. http://lavag.org/old_files/monthly_08_2008/post-121-1218579115.png' target="_blank"> If you want to keep your 256 color icon intact, then the only way around this is to edit the B&W icon separately. PJM

Here is the screenshot of what I was attempting to do several years ago (this was at a very early stage). The document below is (if I recall properly) a list of the feature I found in the NI icon editor (which I was thinking to implement in the custom Icon editor). Download File:post-121-1218571039.doc PJM

QUOTE (JDave @ Aug 12 2008, 10:08 AM) Dave, I like what you did with your icon editor. The UIs are great although I have to confess that I am having a hard time figuring out what some of the toolbar button do. In regard to a LAVA Icon editor. I think we could probably get away with editing only the 256 color icon (although there are some use case where editing each one independently is required). I start working on such an icon editor about 6 years ago and I even made a doc about all the NI icon editor functionalities. I will see if I can find what I had (so far no success). The reason why I think duplicating NI Icon functionalities is a must is that every time I use a custom editor I end up CTRL+. because it does not do something I need to do (ex: copy image from clipboard and more) which end up being more time comsuming than just using NI icon editor in the first place. PJM