jgcode

Congrats from down under

You can all send a thank you note to JGCode.

Happy to collect in reputation points instead

No, seriously I just woke up got out of bed and its like Christmas.

Unfortunately I have to finish off building my deck (another story) so I can't play with this right now and it going to KILL ME

Thank you so much AQ - you rock!

I've just added a similar comment to the idea, but I think my prefered variant would be the inclusion of VIT/CTT files on the palettes.

That way when your with the rest of the VIs/Ctrls for your module/plugin/thing you could just click on the template icon and instead of dropping the VI or merged VI on the diagram, a new VI from the template would be created and placed.

That way people who already know how to find the rest of your API will also by default know where to find your templates.

This was all mentioned over on the darkside and is now on the Idea Exchange:

Allow VITs and CTTs to Behave Correctly As Merge VIs

To my knowledge and as per this thread only DAQmx Base drivers only are supported on Mac.

Therefore, you will have errors/missing files if your Windows App includes calls to DAQmx as they are two different driver sets (as you stated).

The only workaround (term used lightly) would be to run LV in a VM (or bootcamp) on Mac.

However, I can't see why you couldn't edit the non-DAQmx code on Mac, then run your changes back on Windows, no need to trick it.

I wouldn't call that a big

Bug?

Added Idea - please vote for it if you like it: Allow Templates to be Selected Directly from the Tools Menu

Hi All

I don't know if you know, but there is a simply way to rotate a symbole when you place it on icon under icon editor.

After symbol selection, you just have push R key (one or few time) (90° each time) before release left mouse button.

Fun

Eric

You can also use the F key to Flip the image about the Vertical Plane.

I guess the class icons get stripped when building an exe. They seem an unneeded resource at runtime.

Agreed! But tripped me up for a bit tho (I had a broken build)

Nice menubar btw. :-)

Thanks, thats a whole 'nutha story

Here was something interesting I recently came across.

If I build an executable that has a Class Control on it's Front Panel it looks like this:

Initially it threw me off as in the development environment a question mark means broken class etc...

But it is ok, as all the code worked.

I came across it as I was hunting for broken code, and built this SubVI as the Top Level VI to test something in the Run Time.

This topic is continued on ni.com.

This whole thread should be posted on ni.com so some AEs can dig into it and file CARs as needed. I frequently file CARs for threads I see on LAVA, but a lot of what you're discussing here is beyond my knowledge to write up.

Done!

This topic is continued on ni.com

Turns out, most of it is because of the Enhanced DSC Run Time environment.

Making it a symbolic path would encourage you users to link against it. If you thought we were cavalier about changing VIs in vi.lib that aren't in the palettes, that's nothing compared to what we feel free to do to the Resources directory. ;-)

lol

I use Cute PDF to create pdf non programatically

I like this app too, have always wanted to check out the api to see if I could build a wrapper for LabVIEW but you have to pay to get the SDK.

I think I looked at this code once too and associated app

But UAC in Vista was blocking the app and I had to switch it off to get it to work.

I didn't like this, so I left it - but it did work (and it was free).

No reason to rename the VIs. AppBuilder uses lots of things out of VI.lib. So does the Getting Started Window. If it really is something that both LV and customers use, put it in vi.lib and let LV use that copy. It means that any bug fixes we find for Tools >> Options also get fixed for users of the dialog.

That is ok for future versions, but if we want it now (and us developers are a greedy, arrogant, demanding bunch) then it will have to get moved and renamed for LV2009 and LV2010 (if e.g. it was changed for LV2011) - unless you are saying that installing it to <vi.lib> not renamed, alongside the current files in LV2009, will not cause cross linking issue with other LabVIEW components?

Otherwise why not just make the Resource folder (and possibly others) a symbolic path?

Is this a good Idea - or are there reasons not to do this?

Really? Even though I likely buddied the code that introduced this bug?

Most definitely. It took 2hrs 14 minutes to lodge a CAR.

(Plus it hasn't been responsible for killing a customer's app - its scripting stuff, which in LV2009 is NI Labs and not supported - so you are off the hook).

Compared to this which took 720+ hrs to start lodging CARs (and a lot more effort).

Anyways - you will notice that I am pretty liberal with my Kudos - just a small way to say thanks to those for helping me, no matter how big or small the issue is

As it always big to the person trying to solve it!

Hi Peter

You can set up the LabVIEW installer to run other installers after it.

Is there a dependency on the order in this case - does the ODBC drivers have to install before your LabVIEW app installs even if they are in the same deliverable?

Otherwise you could use a batch file and just script the order?

Cheers

-JG

Yep. That's a bug. I'll file the CAR.

CAR 246266

Kudos!

I think that's a great idea, aalthough I'd like to see it distibuted as a VIPM package so I can control my project-based configuration management.

I was in the process of repacking the above to play with, but could not get past the cross-linking issues.

I too would like a package deliverable of the final product (but if not I am happy to do it myself).

[LV2009]

I can script Protected folders into a Library.

Bug?

-JG

I'm glad you brought up this concern so that we will consider it. I think the plan will be to make a copy of all the necessary VIs (less than there are now), place them in a separate lvlib and install all the code in its own location separate from any VIs used by the LV IDE.

Sweet, that will be a great release.

Playing with your example now.

Kudos!

Currently the options dialog framework VI is password protected while we refactor the code to make it user accessible. Stay tuned for an update of this reference example that includes the open source options dialog.

This is some cool stuff, and I look forward to the above.

However, I am wondering how it is going to be distributed so we could use it in an application?

All the called code sits under Resources\Dialog which is not a symbolic path in LabVIEW.

This means that when you move your source code around all the linking will break (had the same issue with the Icon Editor API for LV2009) - I even had to relink the example.

I guess you could namespace and re-install all the existing Resources\Dialog libraries/code into <user.lib>/<vi.lib>?

Good idea on the incremental builds. I'll have to start doing that as part of my tests.

The odd thing was that in my case, the error crept up from a source code revision tag which had been stable for months (no code changes had been made). I had someone ask for an old executable I made, so I did an export, built it and boom, error. The same source had literally been used a dozen times earlier to build from (there were no user.lib files, I manage dependencies within scc and they're similarly set to a stable tag). Took me the better half of a week to get this person what he had asked for.

Me too (sort of) the corrupt class (if it is the issue) inherits from a reusable component which I think may be the actual issue.

It did build previously ages ago, so I have no idea why its doing all this now.

The only reason I caught it is that I did a build on an integration VI as the Main VI in the build, and the Front Panel shows Class inputs as "Question Marks".

Need to investigate further tho.

I had this for VIPM (but only for VIPM).

Ton

Did it get fixed somehow?

This one is really weird - I think something has gone haywire with the IDE, contemplating reinstall.

I think this has come up before, with the answer being you had to poll.

You can Register for Events from Tasks, but I too would be interested to know if there is an Event Driven mechanism for device notification.

I've seen that "error" many times on 2009. Building applications became the bane of my existence for a while when that error would just creep up and not go away. I never sorted it out, just kept jockeying computers and IDE reinstalls until it worked. It was absolutely infuriating. When I finally got things to work, my installer package had ballooned up in size 2 or 3 times its original size, but I just let it be. Wasn't going to poke that sleeping beast at all, at least I had some kind of deliverable...

Application/Installer building in LV is still a rather arcane bit of voodoo in my opinion. They really need to spend more time developing the reliability of that tool, it is my least favorite part of having to deal with LV.

At least I know I am not alone

This one is killing me. 2 days and I *think* I may have narrowed down a class that seems to be corrupting the build at the close of business today.

Still not sure, back on the grind tomorrow... hopefully have it sorted soon?

Branching out into the third day - haven't had a build issue take this long (last time was 2 days).

Serves me right I guess, I wasn't incrementally building on this project either (for what ever excuse reason)

Would not want to be 400 deep with this one

Here is a cool build message: