LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Mouse down? discarded filter event

Hi all!

 

I suspect a bug when discarding 'Mouse down?' filter events.

 

In this vi I set focus on my 'String Ctrl' in the timeout case. I also have a Mouse down? filter event connected to the pane with Discard set to true. I was hoping that this would prevent focus from shifting from the 'String Ctrl' when a mouse down is registered somewhere else, but when i click on the 'String Ind' focus is taken away from 'String Ctrl', only to be given back in the timeout case one second later.

 

If i add a boolean control to this code the mouse down event is discarded as I would expect. If i add a 'Mouse down?' filter event on 'String Ind' and discard it it still steels focus. Other controls such as numeric, paths etc. which need focus to get a value (as opposed to buttons) show the same behaviour.

 

I can't think of a reason why this behaviour should be.



CLA
www.dvel.se
0 Kudos
Message 1 of 6
(3,357 Views)

From what i see in your example, you truely want to simply disable mouse clicking at all for a specific time of operation.

I recommend you to toggle the mouse pointer to prevent the user from mis-using the UI.

 

Just a note:

The behavior you observe is created by the fact that the mouse pointer enables you to click any element requiring the "input" tool (the vertical '|' symbol). So clicking into any element with a text/number field will enable the user to remove the key focus from your selected string element.

That being said, you can catch all these click events and move the key focus back, but that solution seems to be inappropiate and is not scaling well for increasing number for front panel elements.

 

And a plea:

Please do not create "unstoppable" examples!

 

thanks,

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 2 of 6
(3,350 Views)

 

Thanks for your reply Norbert.

 

The application I'm developing will run on a touch screen computer. What I ultimately try to do is to discard all mouse down events that are not on visible boolean controls, keeping focus on an out-of-sight string control that will receive data from a keyboard emulated bar code scanner or rfid reader (or whatever). I want to make sure that the reading isn't interrupted by an accidental touch of the screen.

 

I would have thought that the discarded mouse down event should prevent this. Yes, setting focus right back at the string control is a workaround, it scales alright for my needs if you put it in the Pane:Mouse Down? event.

 

Not sure what you mean by toggling the mouse pointer, it seems any pointer except busy gives the behaviour, but busy doesn't let me do anything. Mind you I haven't worked much with mouse pointers, if I could set something that would allow me to push buttons but not input text I'd be delighted.

 

When it comes to "unstoppable" examples, in this case a stop button would have been discarded 🙂

 



CLA
www.dvel.se
0 Kudos
Message 3 of 6
(3,343 Views)

When talking about setting different mouse pointers, i wanted to point out that you should give feedback to the user that he is currently in a specific "operation". So it wasnt necessarily meant to automatically prevent a different usage by the user....

 

The biggest question regarding your setup:

Why do you want to have that string in an USER INTERFACE ELEMENT if the user SHOULD NOT SEE IT all?

I would store the information internally in the code, for example a shift register (or FGV if it should be accessable globally).

 

Regarding the stop button: True, you cannot press it by mouse. Still, you can tab to it and press <enter>.......

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 4 of 6
(3,337 Views)

@Norbert_B wrote:

 

The biggest question regarding your setup:

Why do you want to have that string in an USER INTERFACE ELEMENT if the user SHOULD NOT SEE IT all?

I would store the information internally in the code, for example a shift register (or FGV if it should be accessable globally).

 


 Derailing a bit here: The alternative would be the Acquire Input Data vi in a loop, limiting me to american keyboard layout and theoretically adding a risk of missed letter, or using the key down event with the need of creating (or finding) a translator between codes and ascii, with all localizations taken into concern. A string control was way easier.

 

Back on track: I still don't understand why Mouse down? filter event doesn't discard the focus change just because we have the input possibility on the clicked element.

 

Edit: Damn you Chrome/Linux/Whatever for steeling the text in the first edition of this post.



CLA
www.dvel.se
0 Kudos
Message 5 of 6
(3,332 Views)

Crossposted and continued on LAVA.



CLA
www.dvel.se
0 Kudos
Message 6 of 6
(3,264 Views)