Antoine Chalons

Ton, I also had to remove an event case from the VI called "Annot_Deamon__CCT.vi" because it was using the Mouse VIs. Then it works fine

I'll try that, thank you for the suggestion.

The Code Capture Tool GUI__CCT.vi has a broken arrow, the LLB <vilib>:Utility:inputDevices.llb isn't found, I think this llb is Windows only. I'm running LV 2013 beta, I have no other LV version to try at the moment on my mac. yes, I think that by default a package supports all plateforms but you can set restrictions. Here's what it looks like :

First bit of feedback after 1 hour. I'll start using the package builder soon. While VIPM is installing packages, the mouse pointer is busy only when above the top button bar and the status bar but not when above the main part (multicolumn listbox), only above the abort button should it not be busy, no? VIPM lets me install the JKI_lib_rcf_... plugins but won’t install the RCF, of course the RCF isn’t mac compatible, does that mean VIPM lets the user install a package that has a non-installable package in its dependencies? I was going to say that RCF plugins should always be set as “Windows only” but in fact no! A RCF Plugin can be not “Windows only”, the limitation is in the RCF itself, if this RCF limitations goes away, without any change a RCF Plugin would work. So what to do then? In general I think most people don’t bother event thinking about the mac plateform when they build their packages, so I think by default a package should be “current OS” only and if the user *thinks* his package is compatible with other OSes it should be a manual task that needs to be done for each package. In the package information window the mouse wheel doesn’t control the vertical scrollbar, it works in the main VIPM window. In the main VIPM window the “two fingers” vertical slide on the trackpad (laptop) controls the vertical scroll but it doesn’t control the horizontal scroll.

While trying VIPM 2013 on mac I noticed that CCT is not MacOS X compatible (at least not with LV 2013) can you modify the appropriate setting when building the package's next release? or better, make the next release MacOS X compatible :-o

That's great I'll try it this WE!

I thought about posting this on the idea exchange, but I could only think of one use case and it's quite small so I don't think many people would be interested. I also don't think the "variant to data" primitive should be modified to match what I did, as you pointed casting to a specific type and matching by name are really not the same thing. Getting an error on type mismatch is I also what I expect from the primitive. The way I put it "I was wandering if it would be a good idea to have the "variant to data" behave the same way" was not exactly what I wanted to say, in fact it's another primitive that would be nice, I don't know what to call it... maybe "label based cluster variant to cluster match" but that doesn't sound right... The point in posting this was more to see if there was any other use cases that I hadn't thought about. The code posted is useful for my use case and really that what matters. Thanks for your comments!

One thing that I really like about the OpenG "Read Section Cluster.vi" is that if some values are missing form the INI file it doesn't matter, the default value for the corresponding elements will just have the default value. I was wandering if it would be a good idea to have the "variant to data" behave the same way, instead of returning an error 91, shouldn't it try and see what does match between the data available in the variant and the data type passed to the "Variant to Data" primitive? I find it not easy to explain what I mean so here's an example : And here's the code. my variant to data.zip I know there are some limitations, not all data type are supported (refnums, arrays, waveforms, etc...) and unique names are required. If someone wants to know when this can be useful, the answer is this : when you develop custom steps for VBAI and you want to add some parameters without losing all the ones that were already there. Maybe there are other use cases for this? Any feedback will be much appriciated.

A, incredibly helpful for making custom probes.

I'm not sure about NI's opinion about this, my feeling is that they don't want their RT OS installed on desktop computers, I imagine it would be a lot of effort for them to support the various hardware configurations outhere. That said, if you can manage to install RT OS + LabVIEW on a desktop computer and get it to work I don't think NI will run after you but they probably won't support you if you run into bugs. There might be another path you can go : virtualization but I know nothing about it. To answer your last question, I don't think performance would be an issue.

If the CAR isn't corrected in 2013, is there no chance at all that is in 2013 SP1?

We've had similar problems with vertical text for YScales on graphs. As far as I can remember we found no work-around for YScale legends but for texts we increased the size of the front panel in order to have a 1:1 zoom factor for printing, that was horrible on screen (huge) but it came out nice when printing. Hope this helps PS : I'll poke around internally because I think we have a CAR for that.

I understand the cross-platform concerns. Sounds like a good news. No urge though now that I have a work-around.

I do, It's for internal use! Thanks alot for that, I had no idea we could embed an EXE like that, neat!

Hi all, I'm using OpenG ZLIB Compress Directory.vi to turn a folder (and its subfolder) into a ZIP file. When some subfolders have characters like é in their name, into the zip file those chars become something else (Ù), is there anything we can do to prevent this? I guess the reason for this "issue" - or limitation - is that zlib library uses ANSI strings and does not support multibyte or unicode strings, fine. My question is is there a way around that? LabVIEW zip VIs probably use zlib too because they give the same result

That's a well hijacked thread indeed!

anyway who more than NI knows that if they really want their IP to be safe they should remove the block diagram?

If you activate private stuff (SuperPrivate... blablabla) you'll have access to this as a VI property : Then if you want to have a VI that enables this option to the whole sub-hierarchy of a VI you'll need to do some work, but be carefull before doing this on all sub-vis that will slow you down a lot, maybe you want to sort a bit and avoid those VIs that are in vi.lib and user.lib. Also I think it will be much easier to get the VI's project item ref and then use the "get all descendents" method than trying to get the list of all sub-vis from the VI's ref directly. Edit : or maybe I'm wrong : https://decibel.ni.com/content/message/36585#36585, in this discussion is shown a method to get VI's dependencies with some exclusion options, you could just remove vi.lib VIs fron there. If it helps, here's a VI I use to get all VIs in a project excluding VI.lib Edit : not sure the VI posted above sorts VI from vi.lib. Hope this helps (and sorry for my messy answer)

Thanks a lot for taking the time to have a look and comment. I have no illusions about how usefull this code can be, as I said I wanted something simple to start teaching myself that's why your comments are very appriciated. I wont have much time this week to work on this subject but I'll definitely go back to my code with your comments in mind and probably come back here with questions. Cheers

Are you interested in a "is prime?" primitive in LabVIEW? If yes, vote here.

Hi all, In order to teach myself to use LVOOP -it's about time to start- I've decided to start with a little project that I've had in mind for a long time, I've called it LVOOP VIServer, I hope it doesn't sound too pretentious. The idea is to make a hierarchy of LVOOP classes that matches the LabVIEW Controls class hierachy in order to take advantage of dynamic dispatch. In a way it is related to this LIE Idea : Improve the "cluster to array" primitive For now I've implemented the parent class "Control" and two child classes "Path Control" and "String Control" and a bunch of VIs to read/write position, size, caption text, caption font and font. If anyone is interested in reviewing the code, providing advice or whatever... I've kept it small enough so that if the core concept is not good it can still be changed. The code is hosted on GitHub here, it should be accessible to anyone, let me know if there is any issue of if you would like a zip in this thread. Cheers

I saw this blog post yesterday and found it pretty funny, hope you'll enjoy! http://highscalability.com/blog/2013/1/16/what-if-cars-were-rented-like-we-hire-programmers.html

I found a hack to remove the time limit to edit your posts, see here

Hi, I found this bug in LV 2011 SP1 and it was reproduced in LV 2012 by an NI application engineer who filed CAR #385212 for it. Basically, if an installer build specification has values under a key that you've created in the "Registry" section and that you delete the key without having deleted all the values before the build will fail. The solution is either to recreate all the same keys and values and delete each value before deleting the keys or edit the lvproj file with a text editor to remove all the lines corresponding to the values and keys your want to get ride of. The error I was getting when the build was failing was : *** Error: An internal tool or library returned an error. (Error code -21) Error adding registry key: Name: name_of_value ************** *** Error Details: Error in MDF API function: _MDFBuildDevPart_AddRegKey nmdkAddRegKey returned error code 26051 *** End Error Report

Hi all, I've just had a look at the drag & drop example that comes with LabVIEW and I was wandering if and how I could use this technique to transfer cluster values between 2 instances of the same EXE. Anyone has done something similar? Any advice?