Darren

This is the link that works for me...I don't think it's an NI employee-only link, but I could be wrong:

https://niweek2014.activeevents.com/portal/myPortal.ww

Also, there does not appear to be a way to export your schedule to your favorite calendar program, like in the past.

Through the regular web interface, you can use the Export button. I was able to successfully export to my Google calendar with this option:

I used that method when writing this VI, which programmatically generates an image of a VI's connector pane terminals.

http://lavag.org/topic/16581-get-connector-pane-32x32-image-looking-for-better-idea/?p=101586

Darren, can you make a 2012 version f this?

Sure, here's a version that can be used in LabVIEW 8.0 or later.

Suppress Dialogs.vi

Isn't it suppressed when you turn off automatic saving for recovery in Tools > Options?

The cRIO sample projects were written with close collaboration with the Systems Engineering group here at NI. The places in which we used global variables for multi-loop communication were specifically chosen for performance benefits over other data communication mechanisms.

I'm going to make our certification department aware of this thread so they know about your concerns, and take into account the (approved) implementations of the sample projects when grading the CLED.

I've never used the OpenG Variant tools, but when I try to perform the comparable operation with the VariantDataType VIs (vi.libUtilityVariantDataType), it works fine.

But, wouldn't this mean that the workaround only works if LabVIEW is installed after the ActiveX components?

Speaking to Report Gen specifically, if you install the toolkit without having Office installed, and try to open/save/mass compile the toolkit VIs, they would all be broken, since the ActiveX components wouldn't be on the system. So having the PrintOut method act funny would be the least of your worries.

If I make an update to the ActiveX component after LabVIEW has recompiled the VI, I would still have to fix this manually?

If you have saved the Excel_Print.vi, then upgrade your Office version, I suppose there is a chance that this VI would break again. I am not aware of anybody running into this issue, but it is theoretically possible.

What if you add another ActiveX property/method to the BD that is actually not called, would this force the VI to detect the change in the external component correctly? 

That is a workaround we didn't think to try, I suppose it might work. We would have to find a property/method that is guaranteed to be different (i.e. requiring a recompile) between the different supported Office versions.

Explain the Print VI issue a bit more then.

Ok, it's been several years now, but here's what I remember. There's some bug with the PrintOut method of the _Worksheet class, which is called by Excel_Print.vi in the Report Gen API:

Let's say I save a VI with this method on its diagram in LabVIEW 2012. Then I give you the VI. If you're also running LabVIEW 2012, the VI will not be recompiled because we're using the same LabVIEW version. But if the ActiveX components for this Excel library are a different version (mostly likely because we're running different Office versions), then the method will be broken on your system. If you were running LabVIEW 2013, though, the VI would be recompiled because of the LV version difference, and the method would not be broken.

Through our investigations, we found that this method was the *only* one in the entire Report Gen Toolkit API that exhibited this behavior...every single other property/method that we call in our VIs would detect the ActiveX component version difference just fine and force a recompile of the VI, even if the LabVIEW versions were the same. To my recollection, we found that there was a bug in the implementation of the PrintOut method itself that was causing us to not see the version difference on VI load. So, the best workaround we could come up with on our end was to force a recompile of the Excel_Print.vi on every installed system by installing a version saved in an older LabVIEW. We figured requiring a save of the VI was less of a burden on users that requiring an edit of the diagram (deselecting and reselecting the method).

If you take the project from one environment to another, then you might expect to see many (or all) of the VIs that make ActiveX calls to want to be recompiled. The ActiveX component version mismatch issue is independent of the Excel_Print issue workaround. That's why any ActiveX-based toolkit (like the Database Toolkit) will demonstrate these issues.

Ok, now it's coming back to me (I haven't worked on the Report Gen Toolkit in several years). You mentioned that the version difference only appears with that one VI? I'm starting to remember that there's a weird ActiveX bug with the Print method for Excel that Microsoft never fixed, and we were able to workaround it by installing a non-mass-compiled version of the VI that calls that method (Excel_Print.vi). A recompile on an installed system (which will always happen when the VI is saved in an old version) works around the bug in the Print method.

I can speak to the Report Gen Toolkit and Database Toolkit issues specifically. Both of these toolkits are mass compiled in the appropriate LabVIEW version before release (which makes me wonder about Jordan's second screenshot above referencing LV 8.6b7...this may be a bug). Bugs notwithstanding, both of these toolkits happen to make extensive use of ActiveX calls. If there are any differences in the ActiveX components on different machines, then the VIs will prompt you to save changes, even if you didn't actually make any edits to the VIs. This is illustrated by the message in Jordan's first screenshot ("external component modified"). One common cause would be a machine with a different version of Office installed than the one installed on our build machines here at NI, but there are many other causes of ActiveX version number differences as well.

That's right. When you're scripting, you need to use the Undo transaction methods in order to preserve (and add to) the Undo history.

If you drop a dummy object on the diagram, then delete it, without wrapping those operations in a Begin Undo/End Undo transaction, it looks like it clears the Undo history.

Call the "Get Tag" method of the ProjectItem class and use the alias.value tag:

In this thread I posted a VI that wraps a private function to suppress LabVIEW dialogs. Standard disclaimer here about using private functionality in production code, etc. etc.

The MenuLaunchApp property only works the way you desire when the menu launch VI is launched from the menu of a VI. If you want to gain access to the project from which the menu launch VI was run, you'll need to use the Active Project property:

From here, you can parse the project and get the Application Instance (which will be different per target in the project) you want.

Maybe use a subpanel to switch out the visible controls depending on user preference?

I don't know anything about the internals of LabVIEW window management, so I can't speak to whether or not what you're seeing is intended behavior when the windows are reparented via winapi calls.

Here's a VI that may help, though. This password-protected VI (saved in LabVIEW 2013) calls a private VI Server property to suppress LabVIEW editor dialogs. Call this VI before you do your scripting, with a TRUE input. Then when your scripting is done, call it again with a FALSE input to reenable LabVIEW editor dialogs. <standard disclaimer here about using private LabVIEW functionality in production code>

Suppress Dialogs.vi

In LabVIEW 2013, you can check out the following shipping example to see some snippets of scripting code that modify the configured events in an Event Structure:

LabVIEW 2013examplesApplication ControlVI ScriptingStructuresVI Scripting with Structures - Event Structure.vi

Here's a screenshot of the applicable part of the example's diagram:

Unfortunately, this functionality is not available in LabVIEW prior to version 2013.

Try adding the object after you show the BD.

Nope, still not prompted:

Here's the VI I'm trying (saved in LabVIEW 2013), if anybody wants to modify it in such a way that I get a prompt when the VI closes.

test script and close.vi

The LabVIEW Run-Time Engine excludes functionality that is purely for editing use...for example, there are no palettes in a built EXE. I'm guessing this is done to keep the Run-Time Engine size down. For better or worse, LabVIEW Scripting is considered editor functionality, and as a result, is not currently included in the Run-Time Engine.

FYI, the VI Analyzer Toolkit includes a test called Built Application Compatibility that will check your application for any functionality that is not included in the Run-Time Engine.

What specifically are you doing to the VI to cause it to prompt on close? When I create a new VI and drop an object in it, I don't get prompted to save when I close the VI, even if I set up an Undo transaction.