Weird Behavior / FF BUG

[Mark Strickland]

This is a strange one.

I noticed on one of my big apps that sometimes a form would "disappear" when I pressed escape.  Since I was doing some special key processing I figured it was involved with that and I would debug it later.

I had a second very small project that would close the form if the cursor was in a multi-line TextBox and you pressed escape.  In this case if ended the program since it was the only form.  This is a very small utility to load a file into a Cheetah DB and had no code for special key processing.

I created a simple test project from scratch with similar fields but escape did NOT cause any problems.

I duplicated the directory where the small app with the problem was saved then I removed 100% off all added code.

THE PROBLEM STILL HAPPENS!  If you put the cursor in a multi-line text box and press ESCAPE the program ends.

I am e-mailing the project to SUPPORT.

Thanks.

[Mark Strickland]

I must have been a little "cross eyed" on my first try but I did duplicate the problem.

If you add the Multi-Line property to a TextBox the form will close if you press ESCAPE with the cursor in the text box.

I will REBOOT just to make sure things are as they seem.

Mark

[TechSupport]

Hi Mark,

This is a Windows oddity. It was discussed in the PB forums:
http://www.powerbasic.com/support/forums/Forum4/HTML/002931.html

I am working on a solution and will post as soon as I can.

[TechSupport]

Okay. Looks like the "best" solution is to modify the message pump directly. Luckily, in FireFly you have access to the message pump via the FF_PUMPHOOK. The idea is to modify the incoming message prior to it being processed. We only modify the message if the incoming message is generated via an ESC key in a multiline edit control.

Add the following code to the end of FF_PUMPHOOK:

Code Select Expand


  ' Do not process ESC keys for multiline edit controls
   Local hWndControl As Dword
   
   hWndControl = GetFocus

   If (GetWindowLong( hWndControl, %GWL_STYLE) And %ES_MULTILINE) Then
     If (msg.message = %WM_KEYDOWN) And (msg.wParam = %VK_ESCAPE) Then
        Local zText As Asciiz * %MAX_PATH
        GetClassName hWndControl, zText, SizeOf( zText )
   
        If UCase$( zText ) = "EDIT" Then    
           msg.message = %WM_COMMAND
           msg.wParam  = MakLng(%IDCANCEL, 0)
           msg.lParam  = 0
           msg.hWnd    = hWndControl
        End If
           
     End If                    
   End If


[Mark Strickland]

To paraphrase what you sometimes see in the "funny papers" ---

Windows #*(^$%^&%$

After reading the PB post it sounds line a bug that has become a feature that 99% of all programs have to "work around".  Pressing ESCAPE in a multi-line text box and ending the program (or closing a form if it is not the top level) is just not very useful.

Thanks for looking into it.  In the mean time I just "won't press ESCAPE on multi-line text boxes.

[TechSupport]

Mark,

If the pump hook approach doesn't work for you then please let me know. It seems to work okay in my test.

[Mark Strickland]

Paul,

That worked with the mods to the Message Pump.

My only other thing would be to catch the ESCAPE so I can process it like I do with the Keyboard Hook you provided recently.  That is not critical right now and I think I can figure out how to do it.  

In general my Function key processing sets a global that the KILLFOCUS events act on.  The ESCAPE key is used as sort of a "master form abort" from any field.  Other Fn keys switch tabs and some others launch special functions like HELP, or a VALUE PICK LIST to fill in a control, etc.

Thanks again for the help.  If I need more info later I will let you know.

As usual there is no better support than the author of the code.

[Roger Garstang]

Docs Claim WM_CLOSE doesn't use lParam and wParam, but in all messages where I selected to close the window they had a value...when hitting Esc in the textbox the WM_CLOSE had no values.  Perhaps this could determine when the message is sent and to ignore it.  Anyone know what the values are?  Window is closed of course when the message is received, so it is hard to see if it is a handle or something.

[Roger Garstang]

Values are the same as WM_SYSCOMMAND, so are probably mouse pos and message type.