Darren

That onesie rules!

I'll be there. Thanks for organizing this, Jeremy.

Here's a VI that tries to do what File > Save All (this Project) does. We are planning on shipping this VI with LabVIEW 2012. Save All This Project (2011).vi

Ok, then maybe picktime.vi is called elsewhere, and that dialog that comes up from the Timestamp is a built-in (i.e. not a VI) dialog? If that's the case, then yeah, short of modifying the application font settings like mike5 suggested, I don't have any other ideas.

If you're referring to the dialog I think you're referring to, it is a VI-based dialog and can be found here: [LabVIEW]\resource\dialog\picktime.vi It doesn't appear to be password-protected, so you should be able to modify it to fit your system settings. All of its support VIs live in picktime.llb next to the VI.

Most VIs I write ship as the source code of NI product features. It's my understanding that including open-source VIs in those features would not be allowed.

I will be at the Austin summit. I do not currently use OpenG.

Thanks, JG. I just confirmed that this bug was present in LabVIEW 7.1, and fixed in LabVIEW 8.0.

Can y'all point me to a post somewhere describing the race condition with the Copy from Folder to Folder VI? I own the libraryn VIs, so I wanted to investigate to see if something is CAR-worthy.

Looks good to me...before looking at your VI, I envisioned solving the issue just like you did...only format the visible cells. Seems like a simple enough approach that you could add a horizontal scrollbar as well with minimal effort.

Very nice...I always use the VariantDataType VIs, and have never thought about using Flatten to XML to get more info out of a refnum than what those VIs provide. Your approach looks solid...find the <Name> tag under the <ActiveXType> tag and you should be good: <LvVariant> <Name>Variant</Name> <Refnum> <Name>ActiveX Container</Name> <RefKind>ActiveX</RefKind> <ActiveXType> <GUID>{9B4CD3E6-4981-101B-9CA8-9240CE2738AE}</GUID> <Name>Acrobat.CAcroApp</Name> </ActiveXType> <Val>0x00000000</Val> </Refnum> </LvVariant>[/CODE] It's not often these days that I get to add something new to my LabVIEW bag of tricks...

Sorry, I didn't mean to offend. I have deep respect for fellow yak-shavers. Maybe some day we can exchange yak-shaving tips, goodness knows I've got a few. As for your scripting question...unfortunately, there is no way to programmatically change the image in a decoration. You have two options that I can think of: 1. If the new image is on the clipboard, you can use the "Paste" method of the TopLevelDiagram class and paste it in the same location as the existing decoration, then delete the old one. 2. If the new image is in a file on disk, then you read it in, and set the value of a picture constant on the diagram instead of a regular decoration.

Yes, I can help, I have a lot of experience with yak shaving. This video should give you all the information you need. Please follow its instructions carefully, as an unshaven yak is something to be taken very seriously.

I hate large icons. Aristos Queue loves them. If I had my way, they would have been gone long ago. Unfortunately, AQ always argues to keep them around. But since he's so badass in just about everything else he does around here, I'll pick my battles elsewhere.

Crazy like a fox!

Here's a weekly nugget where we described this very issue...I don't think there's a way to solve this without a "resume scrolling' button/action of some sort: Darren's Weekly Nugget 06/28/2010

Thanks, guys. JG: I noticed in your VI you are checking the VI Type to determine whether or not you should traverse. A more robust way to determine if a VI has a block diagram is to use this VI: vi.lib\addons\analyzer\_analyzerutils.llb\VIAnUtil Has Diagram.vi Despite its name/location, this VI does ship with LabVIEW core...use it whenever trying to figure out if a VI has a diagram. There is also a VIAnUtil Has Panel.vi in the same LLB.

And as most people know (based on the content of many of my weekly nuggets, as well as my penultimate response on AQ's thread linked above), I often *encourage* people to use VIs that are not in the palettes/Quick Drop. I would venture to say that, since the config VI debacle (which occurred with the LabVIEW 2009 release), we haven't had any major upgrade problems associated with changed interfaces to VIs...our developers are more well-informed of the issues, and we have processes in place that analyze our shipping VIs for interface changes between versions. Jarrod wrote a great Quick Drop Keyboard Shortcut that allows you to easily add a selection of code (which could just be a single VI) to the user palettes so it's accessible with Quick Drop. You can get it here.

User-defined menu entries in the File pull-down menu are linked to VIs created in the [LabVIEW]\wizard directory. Do you have a 'wizard' directory in your LabVIEW 2010 install?

You wrote a custom Quick Drop Keyboard Shortcut during the exam? That's the best!

I'm working on the scripting backend to the DSP Design Module that was announced at NI Week.

You get flak for using the LabVIEW feature that facilitates programming as fast as possible? How strange... I give people flak whenever I see them spelunking the palettes.

Funny...I've only ever programmed in LabVIEW, yet I found mousing around in the palettes to be a huge bottleneck, as I know the name of almost every function I ever need.

No, the default option is to still load palettes in the background. The change in 2011 is that we fixed some background palette loading issues that were causing some palette contents to never get loaded in the background...thus, on Quick Drop's first launch, there was still a bunch of work to do. In 2011, *all* the palette info gets loaded in the background, so assuming this all happens before you launch Quick Drop for the first time, its first launch will be instantly usable.