LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Avoid screen saver unwanted pressure

Hi,

   I have a touch panel where I want to prevent user to press button while exiting from screen saver.

At the moment, when the screen saver is on, if the user touch the screen where a control is placed, a mouse up event of that control is generated.

To avoid it, i put a big button that cover up the entire screen.

So when the user touch the screen, the button turn on, then i disable it (to prevent double touches), wait for 3 seconds and then I hide that button.

The problem is that it seems that this button does not prevent the mouse up event of the control hided by the button to be generated.

Attached an example.
Why does it generate the event for the control that is not on the top?
I would like not to change the properties of every control of my interface to make them not touchable.

Is there a way to do so? Or eventually some way to flush all event generated after the button changes value.

thank you!
 

0 Kudos
Message 1 of 19
(2,640 Views)

UPDATE:  I solved my problem using Mouse UP event on the big button instead of value change event.

But a question still remain onmy old version...Why does the mouse up event persist even if the value change is executed before?

0 Kudos
Message 2 of 19
(2,639 Views)

Using mouse up-down events can be tricky sometimes, and should be avoided unless necessary.

Disabling the big button doesn't prevent the mouse up event to be generated; rather, its management is delayed until the previous event (Value change) is finished; but, at that time, the big button is hidden, so the mouse up is caught by what is below.

You would also avoid the problem by setting the big button as "switch until released". In this case, Value change is generated on a Mouse up, so this event is not left unmanaged.

Generally speaking, I suggest you to always use "switch until released" buttons (which also allows the user to recover from a wrong click).

 

Paolo
-------------------
LV 7.1, 2011, 2017, 2019, 2021
0 Kudos
Message 3 of 19
(2,623 Views)

So you are telling me that the value change event is managed with a major priority, then the mouse up event is managed, but if I change the mechanical action to "switch until released" the problem persist.

The mouse up event i caught by the control under the big button.

I found 2 ways to solve this problem:

1) use the Mouse Up event of the big button instead of the value change

2) use the Value change event but move the action to be done outside the event structure(I don't know why, maybe 'cause the hiding of the button happen after the Mouse up event occur)

 

0 Kudos
Message 4 of 19
(2,607 Views)

UPDATE: Maybe the best solution is to put the code outside the event case, 'cause if you press twice or more the big button, with the mouse up event, it cause the mouse up events of the control under it to be caught.

 

0 Kudos
Message 5 of 19
(2,603 Views)

Sorry, I meant "switch when released", my mistake.

If the button is set "switch when pressed", Value change is fired on Mouse down, so the Mouse up event - that obviously happens later - is delayed until Value change is finished, as the panel is locked during Value change.

Paolo
-------------------
LV 7.1, 2011, 2017, 2019, 2021
0 Kudos
Message 6 of 19
(2,599 Views)

Ok, I confirm that using switch when released and value change as event work correctly but it don't avoid accidental double click.

So, to put outside of the event case the hiding is the best solution, even if I don't undestrand why it doesn't gather mouse up event in memory like it does whith the hiding inside the event structure...

0 Kudos
Message 7 of 19
(2,596 Views)

@pincpanter wrote:

Using mouse up-down events can be tricky sometimes, and should be avoided unless necessary.

Disabling the big button doesn't prevent the mouse up event to be generated; rather, its management is delayed until the previous event (Value change) is finished; but, at that time, the big button is hidden, so the mouse up is caught by what is below.

You would also avoid the problem by setting the big button as "switch until released". In this case, Value change is generated on a Mouse up, so this event is not left unmanaged.

Generally speaking, I suggest you to always use "switch until released" buttons (which also allows the user to recover from a wrong click).

 


I would actually recommend "switch/latch when released".  This is the "usual" way a button works.

 

Edit: It took me 1/2 hour to click on submit.  Please ignore my comment.  🙂

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 8 of 19
(2,594 Views)

Of course,   with any test system,  you SHOULD change the OS power profile to prevent any screen saver from popping up. 

 

Screen savers really only save CRT based displays anyway.   Unless you at MIT in the late 1980's your touch screen doesn't need a screen saver anymore. 

 

Hold it! Oh yeah,  that same MIT lab came up with LCD flat panels. 

 

This is a great question! About how old technology influences modern life.   Did you "dial" a phone number today? Have you even seen a rotary dial telephone outside of a museum?


"Should be" isn't "Is" -Jay
0 Kudos
Message 9 of 19
(2,590 Views)

Maybe it's better to say that the screen turn OFF.

It's not a screen saver, I use to call it so, but it's an energy saver option and we use to leave it enable.

So the screen turn off after some minutes and when you click the screen it turns on.

0 Kudos
Message 10 of 19
(2,584 Views)