I qualify a BUTTONUP for a window in the window's CREATE handler:

equ WM_LBUTTONUP$ to 514

UnUsed=Send_Message( @Window, "QUALIFY_EVENT", WM_LBUTTONUP$, 1 )

This so I can get something to happen when I click on the window's client area. Now I want my window to be able to turn that clickability off temporarily. Naive me thought the following would work:

equ WM_LBUTTONUP$ to 514

UnUsed=Send_Message( @Window, "QUALIFY_EVENT", WM_LBUTTONUP$, 0 )

But it doesn't. why?

I don't need suggestions for workarounds.

- Oystein -

Well a test window with an On/Off button works fine here using just that qualifier so we'd look for something else interfering.

The Sprezzatura Group

World Leaders in all things RevSoft

\/\ O_ O/_ |_|_| N N - \/\ |- |_|_| - Z

Sprezzatura,

Unfortunately not solved yet. Let me spell out the details:

I have a form where I want something to happen when the user clicks the client area.

(Or rather it's when he clicks a certain BITMAP control within the client area. But I believe that goes for the same. It's the window that gets the click anyway.)

I have qualified a WM_LBUTTONUP event for the window. So it's the window's WINMSG event that makes that something happen.

What happens is that a certain dialog appears, e.g, Utility32's CHOOSEFILE dialog.

The user may exit the dialog with a doubleclick. This is what makes the problem occur. If the point in the dialog where the user doubleclicks is directly above the window client area (or the BITMAP), the window gets a new click after the dialog closes, causing the dialog to open for a second time.

If the point where the user doubleclicks the dialog is directly above a button or edit control everything is cool.

What I thought I could do was to temporarily unqualify the WM_LBUTTONUP. So I let my WINMSG do the following

- unqualify WM_LBUTTONUP

- run the dialog

- re-qualify WM_LBUTTONUP.

But it won't work.

It's possible to turn WM_LBUTTONUP off with a handler in a separate object. But it seems it's too late to turn off WM_LBUTTONUP in the same handler as the one that brings up the dialog.

Or?

- Oystein -

OK, so what happens if you make a set_property( "SYSTEM", "BLOCK_EVENTS", FALSE$ ) call around the dialog? Does that stop the click going through?

The Sprezzatura Group

World leaders in all things RevSoft

Sprezzatura,

No joy.

(Placed in a separate button handler it worked, like my un-qualifying did.)

But I don't think I could have used it if it did work. Because the dialog could have been my own OI dialog window. I don't want to paralyze that.

- Oystein -

How about a Utility( "FLUSH" ) call after the dialog has returned?

The Sprezzatura Group

World leaders in all things RevSoft

Nope.

New observation: If my doubleclicks are slow the problem always occurs. If I doubleclick fast enough it doesn't always happen. (Using Utility("FLUSH") seems to make no difference doubleclickspeedwise. Don't know if it makes a difference if the dialog is an OI dialog or a Windows dialog. I'm doing my current experiments with a Windows dialog - Utility32's CHOOSEFILE.)

- Oystein -

The problem occurs with the OI Popup too. But here Utility( "FLUSH" ) offers a cure. My un-/re-qualifying trick does not work.

- Oystein -

Oystein,

You're going to have a problem with this . The following is an excerpt from the Windows SDK:

"Only windows that have the CS_DBLCLKS style can receive WM_LBUTTONDBLCLK messages, which Windows generates whenever the user presses, releases, and again presses the left mouse button within the system's double-click time limit."

So according to this the WM_LBUTTONDBLCLK message is fired after the second WM_LBUTTONDOWN, which will kill the dialog giving your parent window focus just in time for you to lift your finger off the button and fire the second WM_LBUTTONUP which is duly processed by OI.

What you *should* be doing is catching WM_LBUTTONDOWN message and capturing the cursor too so you can check if the user has clicked 'properly'. That way you can be sure that the message you're getting is a real click.

The Sprezzatura Group

World leaders in all things RevSoft

Sprezzatura,

Thanks. I see. I'll have a try.

Another question: Why is it we (I) use WINMSG and qualify the WM_LBUTTONUP event? Why don't we (I) just use the BUTTONUP event, which is already there? I learned it from somewhere, but don't remember the reason.

- Oystein -

Sprezzatura,

What you *should* be doing is catching WM_LBUTTONDOWN message and capturing the cursor too so you can check if the user has clicked 'properly'. That way you can be sure that the message you're getting is a real click.

WM_LBUTTONDOWN works fine by itself, as well as one can expect. Thanks a lot.

I thought I knew what you meant by capturing the cursor, but realize I'm not sure. You mean use WM_MOUSEMOVE and check that the cursor didn't move too far after WM_LBUTTONDOWN?

But I don't think one can distinguish proper and improper clicks that way with certainty. E.g if you click down on an object, and slide the cursor about for a while before releasing it, most systems would still regard it as a button click, wouldn't they? As long as you release the button above the same object, that is. You can move the cursor as fast and far as you like, as long as you return to the clicked object before you release the button. It's still a button click. You can take as long time as you like. You can watch civilizations crumble. It's still a button click.

Or?

And maybe I can live with using just WM_BUTTONDOWN. Maybe I can afford to be tolerant. Perhaps there won't be so many improper clicks in practice. And perhaps the few there will be won't do much damage.

What kinds of improper clicks might there be?

One is the kind where the user has second thoughts after pressing down on an object, and moves the cursor outside the object before releasing it, hoping to nullify the click. Some people do that with buttons. But in my case there is no button.

Another is where the user means to drag something, not to click it. But there is nothing draggable, and nothing that looks draggable, in my window.

Also what happens in my app after improper clicks isn't too confusing, and certainly not destructive.

- Oystein -

Oystein,

I thought I knew what you meant by capturing the cursor, but realize I'm not sure. You mean use WM_MOUSEMOVE and check that the cursor didn't move too far after WM_LBUTTONDOWN?

By this I mean using the SetCapture and ReleaseCapture API calls that force Windows to send all mouse messages to your window regardless of where the pointer actually is. So when they release the button you'll know about it and can detect what's happening appropriately.

If you've got a copy of Slist handy look at the toolbar buttons on the SLIST_97 window - they use this same technique to detect a click (cos they are really just bitmaps and not buttons )

The Sprezzatura Group

World leaders in all things RevSoft

Sprezzatura,

Thanks.

I'll put SetCapture and ReleaseCapture on my list of things to investigate.

Unfortunately it's quite a long list I've got…

- Oystein -

View this thread on the Works forum...