Usage of Error Handler Core

[Norm Kirchner]

So something I have done a few times and never questioned the 'appropriateness' of it was the usage of the "Genereal Error Handler CORE" directly on my block diagrams.

Now the ONLY reason that I like to use the CORE vi is because of the access to the "Stop Event Propagated" line that is not connected out to any of the other error handler VIs on the palettes.

The reason this is important, is because you can offer the end user dialog type to have the option to "continue or stop" but you have no way of knowing if they hit continue.

And I know there are a variety of things I can do, but before I start to investigate making my own dialogs and such, I want to get everyone's feel on what they think of the 'appropriateness' of using this "non-palette level" vi

[crelf]

And I know there are a variety of things I can do, but before I start to investigate making my own dialogs and such, I want to get everyone's feel on what they think of the 'appropriateness' of using this "non-palette level" vi

Usage of non-palette VIs is totally great, but I usually ping NI to see if there's anything in the wind about it being replaced (in fact, it's brought up the discussion here about packaging non-palette vi.lib VIs for internal use for a couple of reasons: to expose them to the palette and to ensure that they don't go away/change). Anyway, if you're specifically interested in building stuff around the GEH core, make sure you catch my session on Advanced Error Handling Techniques with LabVIEW at NI-Week - I think you'll like what you see...

[Michael Aivaliotis]

I don't think NI wants developers using VIs that are not in the palette because then if they decide to change some core functionality then your app will break, because they only officially want to manage functionality exposed in the palettes. NI doesn't want unhappy customers with broken code. But I'm sure you've heard the lecture from Aristos, haven't you?

[Aristos Queue]

As the owner (NOT the original author) of vi.libutilityerror.llb, let me just say: "If you use any VI not exposed on the palettes that is included in this error.llb, you should be aware that in any complete overhaul of error.llb, it may be wiped out, refactored or renamed. In particular, GEH Core.vi was created so that I could have a subVI that I could adapt and change to suit the needs of strange callers, such as Automatic Error Handling, the project providers, the FPGA compile system, etc, and that VI may need a lot more inputs, which may result in it going to the ridiculous 6x6 conpane in the future. This is true of any VI in vi.lib that isn't in the palettes, but is especially true of error.llb that is, at this time, being strongly considered for a near term refactoring (no guarantees)."

But, hey, it's your code! ;-)

[crelf]

If you use any VI not exposed on the palettes that is included in this error.llb, you should be aware that in any complete overhaul of error.llb, it may be wiped out, refactored or renamed... This is true of any VI in vi.lib that isn't in the palettes...

This is why we should come up with a packaging process where we can both expose hidden VIs and keep them future-proof. One way to expose them is to create wrapper merge VIs for each VI you want to expose (that only have the VI you want to expose on their diagrams), then create a package of them. This is, unfortunately, tedious work (I wonder if it would make sense to have virtual packages - packages that *refer* to VIs rather than containing them. Sort of goes against the whole idea of packages though. Just thinking out loud...) Hoovahh and I discussed this topic a couple of months ago - I'll ping him to add his 2 cents.

[Black Pearl]

One way to expose them is to create wrapper merge VIs for each VI you want to expose (that only have the VI you want to expose on their diagrams), then create a package of them. This is, unfortunately, tedious work

Wouldn't it possible to automate this by scripting?

Create a new vi and place the vi from vi.lib on the BD.

Get the copane of the vi.lib.vi and assigne the same for the wrapper vi.

Then Create all Controls/Indicators, wire them and place them on the copane.

Copy the Icon and documantation.

...

Do this with evrey vi in vi.lib

The next morning your PC will be done with it and you just need to look through what you got.

Felix

As a side note: Once I was in a hackers mood and did a scan for all non-password protected vi's in the LabVIEW dir (so not only vi.lib). Took some hours and the list is still lurking around somewhere (I didn't find the time to evaluate what treasurs I might have found)...

[crelf]

Wouldn't it possible to automate this by ...

Do this with evrey vi in vi.lib

Sure, I could use scripting, but I don't plan on releasing packages of every VI in vi.lib - that'd be a mess and very very difficult to control. It might be a good way to discover new hidden VIs, but it's not what I'm after when it comes to distributing (links to) them.

[Daklu]

I wonder if it would make sense to have virtual packages - packages that *refer* to VIs rather than containing them. Sort of goes against the whole idea of packages though.

I've considered this as well for my own internal tools. I don't think it opposes the package paradigm, although I would be sure to label it as a 'Palette' package.