Error 1035 when reading VI Properties of VI subtypes that don't have

[Jim Kring]

When reading the "Is *" properties of a VI, the Property Node will output Error 1035 with the explanation that "Operation is invalid for this type of VI."

This doesn't make sense to me. Shouldn't these properties simply output FALSE if you try to read them for VI subtypes (Poly VIs, Globals, CTLs, etc.) that don't have the property? Raising an error just makes code dysfunctional -- the worst thing is that this seems to be a new behavior and is breaking my existing code.

Download File:post-17-1224467548.vi

[Dan DeFriese]

QUOTE (Jim Kring @ Oct 19 2008, 08:57 PM)

This doesn't make sense to me... Raising an error just makes code dysfunctional.

This doesn't make sense to me either. But then again, neither does throwing an error when the user cancels a file operation.

QUOTE (Jim Kring @ Oct 19 2008, 08:57 PM)

Shouldn't these properties simply output FALSE if you try to read them for VI subtypes (Poly VIs, Globals, CTLs, etc.) that don't have the property?

If these VI types don't "have" the property I would expect that the property node should reflect this fact by breaking. Similar to the way control property nodes do.

I'm curious to here what NI has to say.

~Dan

[Aristos Queue]

a. The behavior is not new for any of the three properties shown here.

b. There's a very simple principle at work here. The question "Is *" has three answers: true, false and not a valid question to ask. For example, before checking IsClone, you should have already passed an "Is VI of StandardVI type?" test. It makes code more robust in the long term. When we introduce a brand new VI type, it is much better for code to light up with errors that scream "this code has never been intended to handle this new VI type and you should visit it to explicitly handle it somehow" as opposed to silently doing something that may or may not be valid to do with that type. Here's an example: Suppose we introduce a new "recursion VI type" that explicitly allows recursion in some strange way. But there is some piece of code somewhere that does the following:

1. Traverse VIs looking for a cycle of references

2. When a cycle is found, check each VI and ask "Is 'share reentrant clones' enabled on this VI? If not, return error (recursion not allowed).

This new Recursion VI type does not have "share clones enabled". Indeed, it is never valid for this new type to even have clones. Your code is now wrong if one of these new types comes along, but if the property just says "false", you'll never know it.

For the record, there is no Recursive VI type in existence anywhere in development, but it was a hypothetical example that I came up with to illustrate this point.

[Dan DeFriese]

QUOTE (Aristos Queue @ Oct 19 2008, 10:39 PM)

The question "Is *" has three answers: true, false and not a valid question to ask...

Well, that's not very boolean!

QUOTE (Aristos Queue @ Oct 19 2008, 10:39 PM)

When we introduce a brand new VI type, it is much better for code to light up with errors that scream "this code has never been intended to handle this new VI type and you should visit it to explicitly handle it somehow" as opposed to silently doing something that may or may not be valid to do with that type.

By all means, scream loudly! However, IMHO it would be more beneficial to know this type of error at edit-time rather than get surprised at run-time... The same way property nodes behave with different control types.

In the example, the property node shows that the VI type is PolyVI... so why does the node have to provide unavailable properties?

[Jim Kring]

QUOTE (Aristos Queue @ Oct 19 2008, 08:39 PM)

a. The behavior is not new for any of the three properties shown here.

b. There's a very simple principle at work here. The question "Is *" has three answers: true, false and not a valid question to ask. For example, before checking IsClone, you should have already passed an "Is VI of StandardVI type?" test. It makes code more robust in the long term. When we introduce a brand new VI type, it is much better for code to light up with errors that scream "this code has never been intended to handle this new VI type and you should visit it to explicitly handle it somehow" as opposed to silently doing something that may or may not be valid to do with that type. Here's an example: Suppose we introduce a new "recursion VI type" that explicitly allows recursion in some strange way. But there is some piece of code somewhere that does the following:

1. Traverse VIs looking for a cycle of references

2. When a cycle is found, check each VI and ask "Is 'share reentrant clones' enabled on this VI? If not, return error (recursion not allowed).

This new Recursion VI type does not have "share clones enabled". Indeed, it is never valid for this new type to even have clones. Your code is now wrong if one of these new types comes along, but if the property just says "false", you'll never know it.

For the record, there is no Recursive VI type in existence anywhere in development, but it was a hypothetical example that I came up with to illustrate this point.

If LabVIEW wants to enforce whether the question is valid, shouldn't it be enforced at edit-time through reference wire type? What I mean is: shouldn't there be VI Server subtypes of VI, just like there are control and lvlib subtypes? It sounds like the editor is being lazy and making life harder for me.

:2cents:

[Aristos Queue]

QUOTE (Dan DeFriese @ Oct 19 2008, 11:42 PM)

In the example, the property node shows that the VI type is PolyVI... so why does the node have to provide unavailable properties?

Because all you handed us is VI Reference. The type of VI on that reference is unknown until runtime. No one originally had a need for an inheritance hierarchy of VI refnums the way we have for control refnums, so it wasn't designed into the system.

QUOTE (Jim Kring @ Oct 20 2008, 12:11 AM)

It sounds like the editor is being lazy and making life harder for me.

There is a distinct difference between a system that chose not to implement a feature and one that was never designed to support a feature.

QUOTE (Dan DeFriese @ Oct 19 2008, 11:42 PM)

IMHO it would be more beneficial to know this type of error at edit-time rather than get surprised at run-time...

Of course it would be better. You asked why it is and I told you. This should not be taken as a declaration that this is the best it could possibly be.