EM_SETSEL weirdness..

[Borje Hagsten]

In a custom control editor, I decided to implement some standard
messages, like %EM_SETSEL, to make it easier to simply replace
already existing text boxes with one for unlimited text sizes, etc.

So, %EM_SETSEL has a 16 bit limit in ordinary textboxes, but since
my editor is built from scratch and I'm handling all messages myself,
I thought I could over-ride that limit. Not so!

Sending an %EM_SETSEL message with lParam or wParam larger than
Integer limit, still fails, even though I trap it all in Longs.
Strange. By changing %EM_SETSEL to my own control message, %EDM_SETSEL,
that is, %WM_USER + something, all works fine!

So, with a "CASE %EM_SETSEL, %EDM_SETSEL", the first one fails on
Longs and the last one works, even though both uses the same code,
same message handler!

Seems like there's more to messages than meets the eye..

(yes, I know about %EM_EXSETSEL, but this was to enhance already
existing textboxes with an editor for unlimited textsize, without
having to rewrite any code. Obviously not possible, since Windows
still puts its limits to these, in some weird way.. )


------------------

[Eric Pearson]

Borje --

So the "weirdness" is that EM_SETSEL works exactly as documented?

-- Eric


------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected][email protected]</A>

[Borje Hagsten]

Yep. Always surprised when that happens.. Thought that by handling
a message all by myself, in a control built from scratch (no sub- or
superclassing), it would be possible to over-ride any limits. Obviously not
possible..

BTW, could someone delete the duplicate posting? Connection broke
down for me, I tried again, using another header.. sorry for that.


------------------

[Semen Matusovski]

   #Compile Exe
   #Register None
   #Include "WIN32API.INC"
   CallBack Function DlgProc
      Select Case CbMsg
         Case %WM_INITDIALOG
            PostMessage CbHndl, %EM_SETSEL, 12345678, 87654321
         Case %EM_SETSEL
            MsgBox Str$(CbWparam) + Str$(CbLparam)
      End Select
   End Function
   
   Function PbMain
     Dim hDlg As Long
     Dialog New hDlg, "", , , 100, 100, %WS_OVERLAPPEDWINDOW Or %WS_CAPTION To hdlg
     Dialog Show Modal hDlg Call DlgProc
   End Function

------------------
E-MAIL: [email protected]

[Borje Hagsten]

Not sure if you wanted to show it works in Win2000, Semen, but I
get 16-bit "wrap-over" result even with that sample in Win98.
Following gives me two different results, wonder why..

    CASE %WM_INITDIALOG
       PostMessage CBHNDL, %EM_SETSEL, 12345678, 87654321
       PostMessage CBHNDL, %WM_USER+1, 12345678, 87654321
    CASE %EM_SETSEL, %WM_USER + 1
       MSGBOX STR$(CBWPARAM) + STR$(CBLPARAM)

------------------


[This message has been edited by Borje Hagsten (edited March 07, 2001).]

[Semen Matusovski]

Borje --
Yes, there no problems in Win2000

Did you try SDK-style under Wun98 (at first w/o IsDialogMessage) ?

[This message has been edited by Semen Matusovski (edited March 07, 2001).]

[Borje Hagsten]

Very interesting. In other words, standard messages must go through
some internal message handler before they end up at the intended
address, even though a message is sent within a function like this.

Post- or SendMessage should be using Long's (DWORDS?) all the way, but
something on the way changes this fact in Win98. Hm, I always thought
controls handled messages themselves, but this must mean that standard
controls somehow are "baked" into Windows' message handler. I mean, I'm
not targetting a standard edit control here, and still it fails.

I'll use my own messages, to avoid any more "unexpected" things..

PS. First place I noticed it was in custom editor - all SDK style.
------------------


[This message has been edited by Borje Hagsten (edited March 07, 2001).]

[Semen Matusovski]

Borje --
Something happends in query. DDT has no relation to this problem.
But CallWindowProc CodePtr(DlgProc), CbHndl, %EM_SETSEL, 12345678, 87654321 (outside query) works as expected.


------------------
E-MAIL: [email protected]

[Borje Hagsten]

No, never say it was DDT specific. It's Windows specific, something I
didn't know about before. Makes it harder to write improved controls
for simple replacement of existing ones. Wanted it to be possible to
simply snap in improved control without having to change any existing
code, but..

No big deal, I use my own messages instead - but good to know.


------------------

[Dominic Mitchell]

Borje,
The operating system modifies the wParam and lParam parameters of the
class specific messages of the system global classes(edit, listbox etc.)
so that they are in the correct format for 16-bit to 32-bit thunking.
There is a short footnote about this on page 48 in Windows95 A Developer's
Guide by Jeffrey Richter and Jonathan Locke.


------------------
Dominic Mitchell