crelf

QUOTE (Phil Duncan @ Sep 1 2008, 11:32 AM) Amen!

QUOTE (Norm Kirchner @ Aug 31 2008, 07:27 PM) You've got my vote! * * Disclaimer: I can't vote.

QUOTE (Aristos Queue @ Aug 31 2008, 09:40 PM) That's the best description I've heard of lvlibs so far :thumbup:

Do you want to open and edit the code (you need the same or a higher version of the LabVIEW development environment to do that), or do you want to just run a built executible (you need the same version of the LabVIEW Run Time Engine)? They are two very different needs that require two vrey different things. So, to ask Mark's question again: QUOTE (mballa @ Aug 29 2008, 09:45 AM)

QUOTE (Michael_Aivaliotis @ Aug 31 2008, 01:30 AM) It is indeed.

QUOTE (Jim Kring @ Aug 30 2008, 11:51 AM) Well said Jim - that's what I was trying to get at.

QUOTE (HChandler @ Aug 29 2008, 06:03 PM) OK - I'll play the devil's advocate: If I understand what you're saying, your hatred toward NI isn't justified - you chose the design pattern, and now you have to sleep in it

QUOTE (Ton @ Aug 30 2008, 07:47 AM) I don't see anywhere inthat post where Stephen says that - are you sure you're linking ot the right post? Anyway, are you sure that a VI doesn't know it's scope? It knows that it's a member of a library/class/etc, so I'm not convinced that it doesn't know it's public/private scope as well...b QUOTE (JDave @ Aug 30 2008, 12:54 AM) The http://forums.lavag.org/-t11537.html&view=findpost&p=49250' target="_blank">Icon Editor I created allows for placing images in the corners. Just so I'm clear - I'd prefer that the icon not atually be edited, I want the scope/re-entrancy/etc glyphs to be on a layer above the base icon, so the image information isn't destroyed by the glyph (eg: if I make a VI re-entrant and then I make it non-re-entrant, then I want the original icon that was under the re-entrant glyph to be preserved).

codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0" WIDTH="384" HEIGHT="304">

QUOTE (PaulG. @ Aug 29 2008, 03:03 PM) have a great weekend. http://www.detroitjazzfest.com/' rel='nofollow' target="_blank">I know I will!

QUOTE (Michael_Aivaliotis @ Aug 29 2008, 01:47 PM) :thumbup: Very cool

QUOTE (PaulG. @ Aug 29 2008, 01:08 PM) What version of LabVIEW are you using? Can you post a VI that you're having this issue on?

QUOTE (jives @ Aug 29 2008, 11:29 AM) To clarfiy: you don't actually want to disable the front panel, but you don't want it shown - is that right?

QUOTE (Aristos Queue @ Aug 29 2008, 11:21 AM) I definately agree that seeing the scope when using the VI as a subVI would satisfy most of my use cases, and I'd be very happy if just that functiaonlity was introduced. That said, I think having the scope displayed during development of the item would serve to remind me where it is in the scope of things, eg: "Oh crap, I'd meant to set this as private to this lvlib, but there's no key glyph". I know that info is available in the project explorer and when I'm thinking scope then it's relative to a context there, but as the VIs are scope aware (they know what they belong to) I figure it wouldn't be too difficult to include a scope glyph on the VI somewhere?

QUOTE (Anders Björk @ Aug 27 2008, 10:12 AM) I've seen tag clouds that are 3D, but not as you might imagine: the font of the tag is proportional to the number of instances of the tag. It's pretty simple, but it's very effective.

QUOTE (Phil Duncan @ Aug 28 2008, 11:02 PM) No worries

QUOTE (PJM_labview @ Aug 28 2008, 10:00 PM) You're not alone - I would like the ability to added a dynamic glyph to the VI icon, and then I can see scope when they're subVIs. It's be nice to have the colors of those glyphs be the same as the class too...

Use VIPM. 2 projects might grow to more projects, and maybe your internal developer base will grow too - I suggest you spend the time setting it up right so it's not painful down the track...

If you haven't read Christina's blog entry on Linked Tunnels, then go there first. It's obvious to me now, but did you know that Linked Tunnels can have more than one output tunnel linked? For example: create a case structure with one input tunnel and two output tunnels. Click on the first output tunnel and link it to the input tunnel. Now, click on the second input tunnel and link it to the the input tunnel. Viola! Both output tunnels are now linked to the same input tunnel

QUOTE (mballa @ Aug 28 2008, 04:17 PM) I think Norm got some video this year...

QUOTE (jdunham @ Aug 28 2008, 01:44 PM) Right - don't ignore everything. Even if you think you know all the errors that a node might generate, there may be one or two important ones that you don't know about. That's why you should also use the "ignore errors inside node" option for methods/properties. All of these things are powerful, but you've got to think about when are where to use them. QUOTE (ASTDan @ Aug 28 2008, 02:12 PM) So how about it. Error Handling Techniques at NI week 2009 by crelf! Sure - remind me when NI's calling for presentation submissions and I'll put my hand up for it. QUOTE (jzoller @ Aug 28 2008, 02:05 PM) Maybe someone knows, is there a way to attach a custom handler or callback to the automatic error handler? (I would occasionally like to inspect, or even modify, my program state when the automatic error handler pops up.) I don't know of a way to do it without editing the VI in vi.lib... That said, I know several folks who replace the General Error Handler with thier own custom versions.

QUOTE (ASTDan @ Aug 28 2008, 01:14 PM) I don't mean that primative specifically - I mean any of the primatives that do formatting (and coincidentally don't have their error clusters in the LL and LR corners). I think most people forget about those because either they assume that what their inputs are always going to be appropriate, or they forget about the error clusters due to the primative's connector pane layout. QUOTE (ASTDan @ Aug 28 2008, 01:14 PM) I guess Error Handling architectures pros and cons. For example I have an "Error" case in my state machine. I have built a Reuse Error VI that can handle standard and User created Errors. This admiditly is probably simplistic but I found it works for what I do. I have seen people put their Error handling in another loop. I think Peter Blume Promotes this. I think this is a good idea but for smaller projects....I don't know if the overhead is worth the functionality. I also think loggering errors to a text file is a good idea. (Need to create reuse vi for that. Again on my list) Each of those patterns have their merits, but none of them are catch-alls. I suppose what I'm trying to say is that I haven't found an error handling pattern that's completely scalable across the breadth of projects that I do, so I've created two or three reusable components that I can select during the design phase of a project. I'm not saying that a completely scalable holy grail is out there, just that I haven't found it

QUOTE (Phil Duncan @ Aug 28 2008, 12:11 PM) QUOTE (Phil Duncan @ Aug 28 2008, 12:11 PM) I get a very helpful explanation. The full text reads like this: "An error occurred loading VI "Real Inverse Matrix (LU).vi". LabVIEW load error code 21: An external subroutine required for execution could not be found. Ahhh - that's important - sis you enable analysis support when you installed the RTE? EDIT: gmart got there before me

QUOTE (TobyD @ Aug 28 2008, 12:05 PM) Good point. The answer is "it depends". We have a reuse component that filters errors, so you can implicitly force it to ignore specific errors rather than not wiring up error clusters.

QUOTE (Yair @ Aug 28 2008, 12:30 PM) I love that it's folded