boolean (reference) and boolean are incompatible

[max_]

hello Yamaeda thank you for another attmept at explaining this to me.

I have to disagree. It's not like that in other languages. At least not in those that I came across.

Yes, there are properties, but they are all defined in the class. The class is the type. There's no additional "strictness" that is applied or not.

I can take a general reference and it would accept references of all kinds.

I can set the type to element class and it will only accept elements. It restricts the references that can be given to the subVI.

And I can go further down the inheritance chain to restrict the range of accepted references even further.

But suddenly, when I go down to Boolean, I cannot use this methodoligy anymore.

I have to use the "add datatype" to further restrict the possible references.

I do not understand why there are these two ways of achieving the same thing (or what I think is the same thing).

In other languages, there would be just another subclass (or interface or whatever).

[GerdW]

Hi max,

you can use a general/non-strict reference to a boolean control. In this case the value property is using a variant as i/o because the boolean isn't defined regarding all of it's properties (mainly the switch mode). When you define that boolean with all it's properties you get a strict reference and a real boolean value property…

With boolean controls  this boils (mainly) down to the used switch mode of the control. Latching modes behave different than switching modes and have their shortcomings, hence the two types of references.

Do your other languages support those different switching modes with their influence on DATAFLOW behaviour? If yes, how?

[max_]

Sorry Gerd for resignating, but this conversations seems to be going in circles.

I understand what it is doing, but my question is why this is not possible by specifying the class.

As mentioned earlier, the fact that there can be more specialised versions of Boolean (that deal with things differently) could be modeled with classes, just like Boolean itself is a more specialised version of an Element.

I cannot answer your question clearly, because I don't know what "dataflow" means in LV terms.

It's used like a buzzword.

To me, dataflow means data "moves" through the program. It's passed from one part to another one.

In many languages this is done with functions (methods, procedures, etc.) that take parameters and possibly manipulate them, return values etc.

The "switching mode" just defines how a value changes that'S returned by a function. I don't see how that can come in the way.

And it doesn't really matter, either. My question is about the API that I can access and why the differently switching buttons (however that is achieved internally) need a form of specification that is not achieved with classes but some other way, namingly("define datatype")

[GerdW · Accepted solution]

Hi max,

I don't know what "dataflow" means in LV terms.

it is explained in the LabVIEW help. Just in the Fundamentals section. It's a buzzword, because it describes HOW LabVIEW executes your WHOLE program…

The "switching mode" just defines how a value changes that'S returned by a function.

Nope. It describes WHEN and HOW LONG the value of a boolean button is changed!

The switching modes are also explained in the LabVIEW help!

why the differently switching buttons … need a form of specification

Because of their properties like the switching mode!

They may have the same look on the FP. They use the same datatype, hence they all create references to a generic boolean control. BUT they may show completely different behaviour thus requiring strict references…

To summarize:

When using a new IDE you most often can use the same or very similar schemes/names/structures. But you also have to learn about specific terms/behaviour/differences of that new IDE. LabVIEW behaves different to other IDE when it comes to UI handling and program flow…

[max_]

My question remains unanswered.

I repeatedly asked why the specification of a different switching mode is not described by a class.

I repeatedly get the unrelated answer "it is this way to describe the different switching modes".

I did not ask why there is a differentiation between Buttons, I asked why this differentiation is not done in a different way.

I tried to rephrase the question several times, never receiving an actual answer.

This last part of this thread is very unsatisfying.

I am well aware of the necessity to understand new concepts.

This was the very purpose of me asking my question here.

My attempts at trying to understand the new concept failed.

I was given answers in the form "this is the way it is, because of some internal logic", which is not what I asked for.

I asked why this differentiation is not defined in another way (with a subclass of Boolean, for example instead of "define datatype")

I feel like this is a waste of time (for everybody involved)

[GerdW]

Hi max,

I asked why this differentiation is not defined in another way (with a subclass of Boolean, for example instead of "define datatype")

You should discuss that question directly with NI R&D, but not in the public forum…

As I'm not an NI engineer I can only guess. And I guess one reason for that behaviour might be: even when it looks like OOP it is no real OOP. Those reference class tree was introduced very early in LabVIEW development, long before any (user usable) OOP-feature was added to LabVIEW. But again: NI R&D might explain this more detailed (and without guessing around)…