No announcement yet.

EM_SETSEL weirdness..

  • Filter
  • Time
  • Show
Clear All
new posts

  • EM_SETSEL weirdness..

    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.. )


  • #2
    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>
    "Not my circus, not my monkeys."


    • #3
      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

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



      • #4
           #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]


        • #5
          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

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


          • #6
            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).]


            • #7
              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).]


              • #8
                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]


                • #9
                  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.



                  • #10
                    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
                    Dominic Mitchell
                    Phoenix Visual Designer