The MASM Forum

General => The Workshop => Topic started by: TouEnMasm on July 19, 2020, 05:29:44 PM

Title: RICHEDIT diferences between RICHEDIT50W and RichEdit20A
Post by: TouEnMasm on July 19, 2020, 05:29:44 PM
Hello,
I have write two search proc who works ,one with RICHEDIT50W,one with RichEdit20A.
Now I want to change the richedit control off a prog written for the RichEdit20A.
He accept the change but the search dialog box find nothing.
I don't remenber what are exactly the function who don't work with the RICHEDIT50W.
This to avois to change all the code,any idea ?.
Title: Re: RICHEDIT diferences between RICHEDIT50W and RichEdit20A
Post by: jj2007 on July 19, 2020, 06:58:28 PM
Dump all content to a buffer and use instr()
Title: Re: RICHEDIT diferences between RICHEDIT50W and RichEdit20A
Post by: TouEnMasm on September 23, 2020, 06:11:25 PM

After search a while,I found that EM_FINDTEXTEX (ANSI version) need UNICODE string.
Quote
   PuPo ptexte,findtext.lpstrText                            ;save adress of ANSI string
   invoke AtoU,findtext.lpstrText                            ;UNICODE version
   mov findtext.lpstrText,eax
   INVOKE     SendMessage, Hredit, EM_FINDTEXTEX, FRFlags, addr findtext
   PuPo findtext.lpstrText,ptexte                             ;Avoid lost of chain in the dialog box
   .if eax != -1      ;rien trouve
      jmp FoundIt
   .endif
Title: Re: RICHEDIT diferences between RICHEDIT50W and RichEdit20A
Post by: jj2007 on September 23, 2020, 07:22:42 PM
Check if you defined Unicode somewhere.

QuoteThe richedit.h header defines FINDTEXTEX as an alias which automatically selects the ANSI or Unicode version of this function based on the definition of the UNICODE preprocessor constant.
Title: Re: RICHEDIT diferences between RICHEDIT50W and RichEdit20A
Post by: TouEnMasm on September 23, 2020, 11:53:34 PM
I have tested this
Quote
   IFDEF UNICODE
      ECHO UNICODE
   ELSE
      ECHO ANSI
   ENDIF

output :     ANSI
no doubt with :     INVOKE     SendMessage, Hredit, 44Fh, FRFlags, addr findtext

It's a bug and surely not the only one



Title: Re: RICHEDIT diferences between RICHEDIT50W and RichEdit20A
Post by: jj2007 on September 24, 2020, 12:42:29 AM
If you use RichEdit?0W, then the control expects Unicode strings independently of the message version.
If you use RichEdit?0A, then the control expects strings depending on the message version.

You may call it a bug, of course, but I suspect that in Micros**t's eyes it's a feature.
Title: Re: RICHEDIT diferences between RICHEDIT50W and RichEdit20A
Post by: mineiro on September 24, 2020, 05:34:13 AM
Maybe CreateWindowExW instead of CreatewindowExA?
Maybe SendMessageW instead of SendMessageA?
Title: Re: RICHEDIT diferences between RICHEDIT50W and RichEdit20A
Post by: jj2007 on September 24, 2020, 07:59:02 AM
Maybe? Maybe you could write some code and tell us what you found? That is what I did...

Quote from: jj2007 on September 24, 2020, 12:42:29 AM
If you use RichEdit?0W, then the control expects Unicode strings independently of the message version.
If you use RichEdit?0A, then the control expects strings depending on the message version.
Title: Re: RICHEDIT diferences between RICHEDIT50W and RichEdit20A
Post by: TouEnMasm on September 24, 2020, 05:24:10 PM
I don't know what is a  "RichEdit?0W" ,the sdk answer to this:
Quote
IFNDEF _RICHEDIT_VER
_RICHEDIT_VER   equ   < 00810h>
ENDIF
cchTextLimitDefault   equ   < 32767>
MSFTEDIT_CLASS   equ   <"RICHEDIT50W">
; NOTE:  MSFTEDIT.DLL only registers MSFTEDIT_CLASS.  If an application wants
; to use the following RichEdit classes, it needs to load riched20.dll.
; Otherwise, CreateWindow with RICHEDIT_CLASS will fail.
; This also applies to any dialog that uses RICHEDIT_CLASS
; RichEdit 2.0 Window Class
; On Windows CE, avoid possible conflicts on Win95
CERICHEDIT_CLASSA   equ   <"RichEditCEA">
CERICHEDIT_CLASSW   equ   <"RichEditCEW">
RICHEDIT_CLASSA   equ   <"RichEdit20A">
RICHEDIT_CLASS10A   equ   <"RICHEDIT">
IFNDEF MACPORT
RICHEDIT_CLASSW   equ   <"RichEdit20W">
ELSE
RICHEDIT_CLASSW   equ   <"RichEdit20W">
ENDIF ; MACPORT 
IF ( _RICHEDIT_VER GE 00200h)
IFDEF UNICODE
RICHEDIT_CLASS   equ   < RICHEDIT_CLASSW>
ELSE
RICHEDIT_CLASS   equ   < RICHEDIT_CLASSA>
ENDIF ; UNICODE
ELSE
RICHEDIT_CLASS   equ   < RICHEDIT_CLASS10A>
ENDIF ; _RICHEDIT_VER >= 0x0200

I insist  "MSFTEDIT.DLL only registers MSFTEDIT_CLASS"

It's like that in my code

Quote
;hInstance dd 0   
crichedit   DB "RICHEDIT50W",0 ;'RichEdit20A',0
Hreditdll    dd 0   
RichEdDLL      db "msftedit.dll",0 ; 'riched32.dll',0      ;version 3 pour XP RichEdit44.dll

%ECHO VERSION_RICHEDIT _RICHEDIT_VER      >>>>>>>>>>  VERSION_RICHEDIT  00810h



Title: Re: RICHEDIT diferences between RICHEDIT50W and RichEdit20A
Post by: jj2007 on September 24, 2020, 07:49:54 PM
Quote from: TouEnMasm on September 24, 2020, 05:24:10 PM
I don't know what is a  "RichEdit?0W"

I'll help you, Yves: In programming, the question mark often indicates that one character needs to be substituted. In this case, it means "the logic applies both to RichEdit20W and RichEdit50W"

QuoteMSFTEDIT_CLASS   equ   <"RICHEDIT50W">
RICHEDIT_CLASSW   equ   <"RichEdit20W">
Title: Re: RICHEDIT diferences between RICHEDIT50W and RichEdit20A
Post by: TouEnMasm on September 24, 2020, 10:47:32 PM
Ok,many thanks for that.
I have already verify all the little details who can generate a problem (even using or not Iricheditole) .
Two things are certain.
**** Loading msftedit.dll, you can only use the RICHEDIT50W class,if not ,no richedit (very clear).
****Using hexadecimal code,it couldn't be an another message than EM_FINDTEXTEX = WM_USER + 79 ;44Fh, EM_FINDTEXTEXW   ;47Ch.
Seems that i have no other choice to wait a correction from microsoft. :mrgreen:
Perhaps if someone had a piece of code in ansi using EM_FINDTEXTEX  without using unicode ???
my code is in 32 bits,but there is a poor chance it work in 64
Title: Re: RICHEDIT diferences between RICHEDIT50W and RichEdit20A
Post by: jj2007 on September 25, 2020, 12:48:18 AM
Quote from: jj2007 on July 19, 2020, 06:58:28 PM
Dump all content to a buffer and use instr()

That is one solution. The other one is to convert your Ansi or Utf8 string to Unicode.