[BUG] Button down event (2!=2 ?!?!)

[Wiebe@CARYA]

Hi,

This is a weird bug...

The Button should be "2" when the right mouse button is clicked. The
indicator inside the event says "2", but the one outside says "1"...

It's even weirder if you put a compare between it. E.g. Compare the Button
in with "2". The values can be probed, and even when the both say "2", the
output is false.

Has this been reported jet? Has anyone found a solution?

Regards,

Wiebe.




[Attachment Button Down Bug (even worse).vi, see below]


[Attachment Button Down Bug.vi, see below]

[BJD1613]

Yes this does appear to be a bug... Ben and I had fun looking at this. Ben said that he thanks you for the excitement this morning. We did find a temp solution for you though. It appears that there is a race condition in the even structure. By placing a sequence structure around the code and making it execute before the right terminal is updated seems to correct your problem. Look at the example posted.

[Wiebe@CARYA]

Well, putting a case between the wire makes it work correctly...

Regards,

Wiebe.


"Wiebe@CARYA" wrote in message
news:4152c3ab@newsgroups....
> Hi,
>
> This is a weird bug...
>
> The Button should be "2" when the right mouse button is clicked. The
> indicator inside the event says "2", but the one outside says "1"...
>
> It's even weirder if you put a compare between it. E.g. Compare the Button
> in with "2". The values can be probed, and even when the both say "2", the
> output is false.
>
> Has this been reported jet? Has anyone found a solution?
>
> Regards,
>
> Wiebe.
>
>
>
>



[Attachment Button Down Bug (Workaround).vi, see below]

[EdDickens]

The problem is, you have selected the 'Mouse Down?' event. The question mark indicates that this is a filter event instead of a standard event.

On the right side of the event structure, you have wired a 1 to the 'Button' terminal. The filter events capture the event, but allow you to modify it before it is passed to the application. So the 1 on the right hand 'Button' terminal is forcing the 'Button' value to a 1 regardless of what value is actually generated. Change that constant to any other value and the Button indicator will only display this new value.

This is the correct action for the Filter event. All you need to do is edit the event case to the 'Mouse Down' action.

Ed

[EdDickens]

This solution worked because you moved the indicator inside thh event case, so it gets written to before the Button value is modified by the filter event.

Simply changing the event from 'Button Down?' to 'Button Down' fixes the problem on the original VI.

Ed

[Ben]

Hi Ed,

There appears to be two issues illustrated in this example.

1) Without data flow forcing the execution order, the "1" can (and in this case does) get written before the value is read.

2) In execution highlighting, it shows that a "2" is not equat toa "2"!

Issue #2 is an "unexpected behavior" (?bug?).

Ben

[BJD1613]

I agree that when you change the event type this corrects the problem. What I see that is misleading is when you have the event as a filter event and you run in execution highlighting you see 2 and 2 go into the equal function and then false comes out. but when i put a sequence structure around that code 2 and 2 equal true. Even though we are writing a 1 to the terminal on the right a 2, (according to exe highlight.) is coming into the equal function.

[Wiebe@CARYA]

Well, it seems to be normal this way. I'm still sure that it's not how it
should work.

Anyway, other filterring events behave the same, so at least it's
consistent...

Regards,

Wiebe.


"Wiebe@CARYA" wrote in message
news:4152c3ab@newsgroups....
> Hi,
>
> This is a weird bug...
>
> The Button should be "2" when the right mouse button is clicked. The
> indicator inside the event says "2", but the one outside says "1"...
>
> It's even weirder if you put a compare between it. E.g. Compare the Button
> in with "2". The values can be probed, and even when the both say "2", the
> output is false.
>
> Has this been reported jet? Has anyone found a solution?
>
> Regards,
>
> Wiebe.
>
>
>
>



[Attachment Key Down Bug.vi, see
below]

[Wiebe@CARYA]

Hi,

I came up with a sequence structure myself (see the other thread). The
problem is definitely not
a race condition, not a normal one anyway. 2 should always be 2...

The way I placed the sequence structure also fixes the problem, but
shouldn't fix it if it where a race condition.

Changing to Mouse Down was not desirable in my case. I used this structure
to catch the Mouse Down in a tree (the bug appears with all "mouse down?"
events, also in controls). When a right mouse button is clicked, I want to
do something with the right clicked item. But in the "mouse down?" event,
the item is not changed jet, so I use a signalling value change.

Then, in the "value change" event, I check if the value was changed with a
left or a right button click.
That didn't work as it should.

Again, placing the sequence structure helps.

Regards,

Wiebe.


"Ed Dickens" wrote in message
news:50650000000500000011CA0100-1079395200000@exchange.ni.com...
> This solution worked because you moved the indicator inside thh event
> case, so it gets written to before the Button value is modified by the
> filter event.
>
> Simply changing the event from 'Button Down?' to 'Button Down' fixes
> the problem on the original VI.
>
> Ed

[EdDickens]

I didn't look at it before with execution highlighting on.

You're correct, issue #2 is a bit odd, though I still think it's doing what it's programmed to do. And that is, force the 'Button' value to 1.

The problem is in the displaying of the 'Button' value either in a probe or when execution highlighting is turned on. This is definitely �unexpected behavior� and makes troubleshooting difficult. The issue is which value should be displayed. Without forcing dataflow, the value in memory is obviously modified by the filter terminal since the equal function is operating on a 1 and a 2. So, to me at least, the probe and execution highlighting values are wrong and this should be fixed. (!bug!)

Ed