Antoine Chalons

love it!

Issues started to happen with LV 2011 and the last update of JKI RCF was released in july 2009 (unless I've missed something).

I think JKI folks are busy on other products now and I suspect that Quick Drop is a serious enough alternative for JKI to not put too much effort into the RCF anymore.

Scripting properties and methods are not supported in the run-time engine, so a built EXE does not have the ability to perform VI inspection.

I think I understand why NI would want users to not be able to use scripting in a built application but I find it hard to believe that is there no way around the limitation.

Hi,

I don't know of any "direct solution" for that, I think you have 2 options :

- keep checking if that string control has the focus (using a property node on that string)

- keep checking the panel's property called "Text Focus", it will return the label (name) of the control that will receive the keyboard strokes

but both these options need to be placed in a parallel loop that will run at a certain rate.

hope this helps

Here's one person's opinion that I think is to be taken into account : http://lavag.org/topic/17009-labview-2013-favorite-features-and-improvements/?p=105003

http://www.kickstarter.com/projects/noflo/noflo-development-environment?ref=category

Thanks for the link LogMAN, I did "report to mod" waited for about 2 weeks and then started that topic.

What's special on July 4? Anyway original post was from end of may.

End still now my report to moderator hasn't been dealt with 

204 views, no answer, no PM...

Hi everyone,

I need help from a LAVA moderator (or admin), please PM me.

Cheers

Call NI to obtain a SRQ from NI so that is issue is followed and can give birth to a CAR.
Or go to ni.com/ask and connect with you NI profile, it's pretty similar to calling, you only "lose" 1 or 2 days depending on how busy the AEs are, the advantage of that is that you can follow all the SRQs linked to your NI profile by logging on on ni.com/ask, I find it quick and easy.

Hi Antoine,

 

Yair is right that code is used for the panning/zooming using the scroll wheel. I always thought that code was OS generic.

Can you place the whole while loop + init/close VI inside a conditional structure, to see if it is fixed then?

If so we can easily create a platform limited code for Mac/Linux.

Apparently this code is only available on Win/Linux.

 

Ton

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.

Is it just a matter of setting a flag in the package to mark OS X as a supported platform?

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 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.

Indeed, the zlib library or more generally the zip addition to it do not use mbcs functions. And that has a good reason, as the maintainers of that library want to make the library compilable on as many systems as possible including embedded targets. Those often don't have mbcs support at all.

I understand the cross-platform concerns.

However I'll be having a look at it, since the main part of the naming generation is actually done on the LabVIEW diagram, and that may be in fact more relevant here than anything inside zlib. There might be a relatively small fix to the LabVIEW diagram itself or the thin zlib wrapper that could allow for MBCS names in the zip archive.

Sounds like a good news.

No urge though now that I have a work-around.

Do you want the crappy solution that works?

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