Why does DISABLED disable a SCREEN RECTANGLE instead of just the control?

[CoastalMaineBird]

I have solved this problem, but wanted to post it here for discussion.

LabVIEW 7.0, Windows.

I have a cluster: Item 0 is a custom enum control, item 1 is a string control.

Under certain conditions in my program, the string field must be disabled (and grayed out), because it's not applicable.

When I did that, I found that the enum was disabled as well. Actually, it would sometimes work if I hit the up-arrow just right, but the menu would never pop up. It worked find if the string was enabled.

The string field (item 1) had a label above the left side of it. The enum (item 0) was positioned immediately above the right side of it.

So why was item 0 disabled if item 1 was? I verified that the DISABLED property was NOT getting set to disabled (it reported 0 when I read it). There were no other property nodes to item 0.

As it turns out, it seems that when the string was disabled, there was a RECTANGLE on screen which was disabled. In spite of the fact that neither the string field not its label overlapped the enum, the fact that the enum was within the string's RECTANGLE was disabling it. The fact that the enum's up-arrow extended above this rectangle is what made it work if I hit it just right (the top 1 or two pixels, i guess). I found this out by moving the enum off to the right (out from under this rectangle.

My eventual solution was to go to the typedef for this cluster and move the enum IN FRONT of the string. I did not change the cluster order, just the physical front-to-back ordering. Now it works, with the enum back where I wanted it in the first place.

I have attached a VI which demonstrates this. I tested it on LV 7.1 / OSX and it still fails. Not sure if it's a bug, or intended behavior.

[tbob]

Very interesting find. If you move the string label to the left or right of the string, that disable rectangle will move also, and the enum will fully work. I guess the rectable of disability includes the disabled item and its label, and perhaps its caption too.

[zou]

That's just the easiet way to do it in MS Windows environment.
As you've found out, move string behind the enum will solve the problem.

George Zou
http://gtoolbox.yeah.net

[CoastalMaineBird]

Apparently the disabled part is the smallest rectangle that includes the field AND its label and caption (I tested that just now).

It's probably easiest for the runtime to have a rectangular area to consider, but why isn't it just the field itself? (Not including the label, or caption). You can't click on them to any useful result anyway, can you?

[CoastalMaineBird]

It's not strictly a Windows problem - it works the same in OS X.

[Ben]

Can't say if that is a bug. I would guess it is the nature of the beast.

If you do an "invoke node >>> get image" it will return the same rectangle you are talking about.

Hide the label, just the control shows up.

If you go into the control editor and switch to blow-torch mode you see the rectangle high-lighted.

I'm guess that the "click detect" logic does a quick range check on X and Y, starting from the front of the cluster, working toward the back until it finds a match. This is consistent with your cluster Front-to-Back order fix.

The only exception to the above mentioned methodology it that transparency is taken into concideration.

Just 2 cents,

Ben

[chilly_charly]

I also met this kind of problem each time I need to programatically move objects. The position returned by the property node is dependent on the label position. This can be so annnoying in some situations that I am obliged to check if the label is displayed, turn it off, get the control position, then turn the label back on...

CC

[CoastalMaineBird]

I'm guess that the "click detect" logic does a quick range check on X and Y, starting from the front of the cluster, working toward the back until it finds a match.

Well, maybe, but then my question is why would the "click-detector" care? You can't click on the label of a control to any useful effect (at run time). It doesn't even draw focus to the associated control. If you tab around at run time, you see rectangles around the controls, excluding the labels.

So I don't see a good reason for this behavior.

[CoastalMaineBird]

The position returned by the property node is dependent on the label position.
Now that you mention it, I've run into it when aligning controls. If you top-align two controls having labels above them, it is the labels which are aligned, not the controls. If the labels are spaced differently, then I have to hide the labels, align the controls, show the labels, and align them separately.

[rolfk]

I would say this is most probably optimation. While you can of course escalate a user event message all the way down to any of the lowest controls only to see in most cases that the control did not care about this message for whatever reasons, this adds significant delay to the event handling. So having the top level control (cluster) do a quick and dirty rectangular check to see which control should receive the message if any and only passing it to that control speeds things up significantly.

Doing anything but a rectangular area check is again a performance problem as well as a never ending story of special cases which need to be handled just this tiny bit different to the rest, and any modification for a particular situation has often several undesired consequences for other cases.

Rolf Kalbermatter