Using CONTROL SEND to highlight text not working

[Gary Beene]

When I try to use the Control Send to highlight text, nothing happens. But when I use Control Post, the highlighting works fine.

Why would that be? Here's the test code I tried.

   #Compile Exe
   #Include "win32api.inc"
   Global hDlg As Dword
   Function PBMain() As Long
      Dialog New Pixels, 0, "Highlight",300,300,125,100, _
                                      %WS_SysMenu, 0 To hDlg
      Control Add TextBox, hDlg, 100,"Edit Me!", 10,10,100,20
      Control Add TextBox, hDlg, 200,"Edit Me 2!", 10,40,100,20
      Dialog Show Modal hDlg Call DlgProc
   End Function

   CallBack Function DlgProc() As Long
      If Cb.Msg = %WM_Command Then
         If Cb.Ctl = 100 And Cb.CtlMsg = %EN_SetFocus Then
'            Control Send hDlg, 100, %EM_SETSEL, 0, -1 
            Control Post hDlg, 100, %EM_SETSEL, 0, -1  
         ElseIf Cb.Ctl = 200 And Cb.CtlMsg = %EN_SetFocus Then
'            Control Send hDlg, 200, %EM_SETSEL, 0, -1  
            Control Post hDlg, 200, %EM_SETSEL, 0, -1  
         End If
      End If
   End Function

If anything, I expected SEND to work immediately, and POST to possibly have some delay.

I read several posts here which indicated SEND would work but I'm not getting the expected results.

[Michael Mattias]

Your problem is, the control is doing more AFTER it gets WM_COMMAND/EN_SETFOCUS and likely whatever you are doing here is being undone/re-done later..

For example, when an edit control gets the focus, the default action is to... select all the text. (which is what you are attempting to do?)

(I just went thru this 'in what order does each notification arrive' last week with the edit portion of a combobox control. In my case I wanted to "UNDO" the default action, so I POSTED an EM_SETSEL to control after CALLing SetFocus (which SENDS a WM_COMMAND/EN_SETFOCUS before returning).

[Gary Beene]

Michael,

Is your comment true?

For example, when an edit control gets the focus, the default action is to... select all the text.

When I remove the DlgProg completely in the example above, alternately selecting the textboxes does not highlight the text (which is what I want to do).

I've seen that when I create a textbox, the text is automatically highlighted the first time, but not when I simply select between various textboxes on a dialog.

And thanks for the response. It gives me a place to start looking.

[BOB MECHLER]

   #COMPILE EXE
   #INCLUDE "win32api.inc"
   GLOBAL hDlg AS DWORD
   FUNCTION PBMAIN() AS LONG
      DIALOG NEW PIXELS, 0, "Highlight",300,300,125,100, _
                                      %WS_SYSMENU, 0 TO hDlg
      CONTROL ADD TEXTBOX, hDlg, 100,"Edit Me!", 10,10,100,20
      CONTROL ADD TEXTBOX, hDlg, 200,"Edit Me 2!", 10,40,100,20
      CONTROL SET FOCUS hdlg,100
      CONTROL SEND hDlg,100,%EM_SETSEL, 0, -1
      DIALOG SHOW MODAL hDlg CALL DlgProc
   END FUNCTION

   CALLBACK FUNCTION DlgProc() AS LONG
     SELECT CASE CBMSG
       CASE %WM_CTLCOLOREDIT
         CONTROL POST CBHNDL, GetDlgCtrlID(CBLPARAM), %EM_SETSEL, 0, -1
         'CONTROL POST CBHNDL, CB.CTL, %EM_SETSEL, 0, -1
     END SELECT
   END FUNCTION

This will select the first field and clicking or tabbing to the other field will highlight it too. The remarked out line using CB.CTL or CBCTL doesn't do the same thing for some reason.

This is ver 9 of PB. With a couple of tweaks it works in 7.04 also

BOB MECHLER

[Michael Mattias]

alternately selecting the textboxes ...

A control is not 'selected.' It may gain the keyboard focus.

You should be able to highlight the text by *Posting* an EM_SETSEL message directly to the edit control, which is what you are doing with CONTROL POST.

If that is not working darned if I know why not, but I'm not a DDT guy. Then again maybe it *is* working and you just have to force a redraw somehow AFTER that EM_SETSEL has been processed.

Try calling InvalidateRect () and UpdateWindow() for the control AFTER posting the EM_SETSEL. That will put a WM_PAINT in the queue and those always go last. (I'd probably try CONTROL REDRAW to see if that happens AFTER the EM_SETSEL message is recieved, but I would not be surprised if that redrew immediately).

[colin glenn]

Tabbing from control to control works just fine in either case, using the mouse fails with the SEND because the caret needs to be positioned where the click occurred in the text AFTER the SEND occurs, there's yet another message sent to the control which PLACES the caret at the position clicked on by the mouse. So POST works because it gets stacked onto the message queue AFTER the mouse click processing.

Makes sense?

[Gary Beene]

I'm sorry guys, but sometimes things take a really long time to sink in. When I read your comments the first time I simply didn't catch on to what you were telling me. Perhaps now that I've had more programming time with PowerBASIC under my belt, the answer simply fit better with my understanding of how it all works (that's a polite way of saying I was to stupid/uneducated at the time to understand the import of what I was being told).


Colin - Yes, it makes sense. Nothing I read suggested it would be (or not be, for that matter) that way, but your explanation that the sequence of events isn't as straight-forward as I might have expected seems to be the case.

Bob - Your code with %WM_CtlColorEdit works. Again, nothing I have read would have suggested use that message but it seems to be late enough in the message stream that the EM_SetSel will work as advertised.

As for the CB.Ctl, the Help file clarifies that while CB.Ctl is the control ID for a %WM_Command message, it's value of Lo(Word,wParam) doesn't return the control ID for a %WM_CtlColorEdit message. For WM_CtlColorEdit, lParam is a handle for the edit control, which is why the GetDlgCtrlID code you gave me works fine.

Thanks for your code - sorry it took me so long to actually realize that it works, and why.

Michael - your hint also didn't sink in enough at the time for me to understand what was going on. Tonight I was rereading the posts and for whatever reason they all made sense. It's like a second reading of a technical book - you have to learn a minimum of information before you can realize the value of other knowledge. Thanks to you, too, for your guiding comments.

To the world at large - it still irritates the fool out of me that some seemingly should-be-common knowledge doesn't seem to be in the primary reading materials I've been directed to rely on. It could be that I simply missed this one in my reading, but it's happend a lot since I started using PowerBASIC. Not that any of us would want to read a book of all knowledge (who knows how many page that would be!), but I would like to read the book entitled "What Gary Beene needs to know!". That would be a book worth reading!

[Rodney Hicks]

To the world at large - it still irritates the fool out of me that some seemingly should-be-common knowledge doesn't seem to be in the primary reading materials I've been directed to rely on.

A tad facetious here but if it's common knowledge, why put it in the documentation? But I assume that you meant put it in the documentation until it is common knowledge.

When you purchased PowerBASIC you became part of a very interesting group of individuals that is divided into two camps.

In one camp you have Bob Zale and his crews keeping up with the needs of the other camp, yet leading the other camp, with his product development.

The customer base makes up the other camp, and we send in our New Feature Suggestions(NFS) and our suggestions for change(documentation as an example) and we use Bob's product each to our own ends. Now I know that I have sent in more than 20 NFS alone in the last two years, and if everyone did that many, the 4000 + customers would have supplied 80,000+ NFS, not to mention Suggestions for Change. On top of this Bob can and does a very good job of anticipating the other camps needs and wants so that the camp members can meet their 'ends'.

Now the folks in the second camp are refugees from all kinds of other systems, DOS, OS2, VB, C, and various other Basic dialects.

So to make PB work most efficiently, Bob keeps the documentation as simple and straightforward as possible(considering the human element), and if using the documentation doesn't provide the answer, well Bob has given us something that does provide the answer in well over 99.9 % of times.

He gave us these Fora!

We must have the patience and wisdom to use them.

Gary, you have been a great help to some of those that came after you, and you have been a great help to some that were here before you. In your own fashion you have helped Bob by helping others.

This method is really a good 'common sense' method to handle the myriad of details, and if you see the logic to this, then you are a PBer, no matter whence you came.

[Barry Erick]

Control Redraw ?