PJM_labview

QUOTE(tcplomp @ Feb 15 2008, 07:26 AM) I agree with Ton, you did a very nice job. :thumbup: Please do give us the details. PJM

Since we are on the topic of "hardware" wish list, I want a cRIO with optional FPGA back plane. I want the modules, the processing power, not the FPGA. PJM

QUOTE(Yen @ Feb 13 2008, 12:03 PM) Here it is in 7.0. http://lavag.org/old_files/post-121-1202974163.vi'>Download File:post-121-1202974163.vi PJM

QUOTE(tcplomp @ Feb 12 2008, 09:34 PM) Yes, but this is very easy. The Item Symbol Index has to change according to this formula: Item Symbol Index = Orginal Item Symbol Index + Indent Level * 65536 Example: If you have this glyph ( http://lavag.org/old_files/monthly_02_2008/post-121-1202921719.png' target="_blank"> ), which has and index value of 14, and you want an indentation level of 2 then you set this Item Symbol at 131086 (which is 14 + 65536 x 2).PJM

Now that I got all the pieces together I am finally able to write UI like the one below. This MCL will really come in handy in many situations. Thanks everyone for all the feedbacks. PJM

Thanks :thumbup: PJM

I have made some progress on that front. I extract that control from the example finder (this turn out to be a MCL listbox). Here is the control: Download File:post-121-1202760621.vi Now I have to figure out how to change these glyphs. For info, here is a screenshot of NI VI interface that manage the listbox (Mikael, you might have been onto something with the 2d array of glyphs). Any feedback will be greatly appreciated. PJM

I think to even have a chance of this working, you will have to strip the compile code as well (so opening the VI would required a recompile). I think you should go with Darren solution. PJM

Which is what I meant by "resizing column".

QUOTE(MikaelH @ Feb 4 2008, 05:54 PM) Yes, this could be nice to have 2D array for symbols, but I am suspecting that this might not be how this has been implemented. As you say, this table/MCL/Tree might be available through scripting. I will have to investigate. Since the example finder has been build as an executable, it has used this MCL which support multi glyph columns. The first LV version that shipped with the executable example finder was LV 7.0, so this would be cool if NI could let us use this (since this has been around for quite sometime now). QUOTE(MikaelH @ Feb 4 2008, 05:54 PM) I guess you have to solve it something like this: http://lavag.org/old_files/post-941-1202176453.vi'>Download File:post-941-1202176453.vi Cheers, Mikael Yes, I have done it in a similar fashion in the past, and this work fairly well as long as you don't expect the user will want to resize the column. PJM

I remember attending a presentation last year (or the year before) at NI week talking about the example finder. The code is written in LabVIEW (if I remember correctly). I was wondering is someone know how to get to that multiple column list box (or tree or table) that allow for multiple glyphs columns (see image below)? Thanks PJM

This look very promissing. I will try to give it a shot next "free" time I got. PJM

QUOTE(Jim Kring @ Jan 5 2008, 08:10 PM) I have the same issue here. In LV 8.5, it does not work at all with no error. In the same fashion, the Open URL in default browser [path] does not work either with no error. If I try with an older LV version (for example 7.1), I got the URL, but it is truncated (in firefox). So basically, this is a no go for me as well. Some staring at the "Open URL in Default Browser core.vi" binary data seem to indicate that this function call a LabVIEW export function called WWWOpenURLInBrowser. This is probably were the issue is. http://lavag.org/old_files/monthly_01_2008/post-121-1199595693.png' target="_blank"> I will be curious to find out why it work on some computer but not on other though. PJM

Alternatively, if all else failed, you can generate it programatically ( ).Download File:post-121-1198880077.vi PJM

QUOTE(osvaldo @ Dec 19 2007, 01:17 AM) How about like this? http://lavag.org/old_files/monthly_12_2007/post-121-1198088545.png' target="_blank"> PJM

This is the "NI LabVIEW 3D Visualization Demos" from NI Labs. PJM

Quick update: After the search finishes, LabVIEW hangs. Therefore, LabVIEW search function is unfortunately note usable on large project PJM

The LabVIEW search dialog *appear* to slow down over time and when searching inside classes. I just did a search on a project that had a lot of VIs (clones included) in memory. The first few 1000s VIs/Clones went very fast, but around 4000s, things start to degrade pretty quickly. The entire search has been going for over an hour now (but it is close to the end). Is this a know issue (this slowdown)? PJM

Ya, you got to call Doctor Who. The Timelord will fix it up for you. PJM

The CAR number for this issue is: #7178839 PJM

AQ, I did submit a bug report on this issue this morning. I will be posting the CAR when I get it. PJM

Ok, I understand now. This method (although deprecated in 8.5) should do this (I have not test it though). PJM Download File:post-121-1196981358.viLV8.5

Tomi, I have used this VI buffer technique in the past several time (basicaly reading the VI as a text file and saving the end result as default in a string control). I don't understand why you say that LabVIEW will not recompile this VI. As soon you "extract" this VI to disk, it becomes like any other VI. I guess I don't quite understand your use case scenario. Note: I have seen the scripting buffer function and while I never had to try them, I always though that the App:Open.VI from Buffer method was the equivalent of extracting the VI to a temp location and them opening a ref to it. PJM

Ok, I will report it later today. Unfortunately I did not kept the corrupted VI (I just revert to my last known good copy in my source control). I will be working on that same class today, so I may very likely get that issue again. As to attached everything, I don't think this is going to happen. This class alone load 3600 VIs in memory. Another issue (might be related). While editing this VI, LabVIEW periodically freeze with the hour glass cursor (it *seem* to be verifying the hierarchy) for about a min. Most of the time this is not critical (no crash), but every so often it crash. I might be getting these compiler error just when I am attempting to do an edit and LabVIEW start to hang up (this is just a though). PJM