An implemention of ITextHost wo works only with windbg

[TouEnMasm]

Hello,
Perhaps have you more idea than me.
The source code show no errors,no bug but works only with windbg and
with the flags debug (Zi,/DEBUG).
Open it with windbg and you will see.

There is only two modifies to made at this source.

use this:

IID_ITextServices  GUID <8d33f740h,0cf58h,11ceh,<0a8h,9dh,00h,0aah,00h,6ch,0adh,0c5h>>

The source use the one in uuid.lib with EXTERNDEF,after a search it isn't in this lib.

The DrawText function must be change by DrawTextEx just adding a NULL parameter.

invoke DrawTextEx,hdc,addr asciihello, LENGTHOF asciihello -1,addr rect,DT_CENTER,NULL

I have not searched for why the function don't work
There is no need of the InvalidateRect function if you made the init in the WM-CREATE Message.He is needed if you use the WM_COMMAND.Put it just before
invoke put_RTFText,bstrRTF

Also add this:

   .ELSEIF uMsg == WM_CLOSE ;return zero
      
      ;invoke MessageBox,NULL,SADR(" WM_CLOSE "),SADR("Titre"),MB_OK
      .if ppvITextServices != 0
         ITextServUnk Release
      .endif
      .if ppvITextDocument != 0
         ITextDocument Release
      .endif
      .if m_editCookie.bstrText != 0
         invoke HeapFree,Hheap,NULL,m_editCookie.bstrText
      .endif
      INVOKE     DestroyWindow, hwnd
      mov retour,0

Modifying the source take care of this:

The itextservice and ITextHost are not STANDARD COM.
They are in the textinclude.inc with the source code (see attachment here).
In the frame    ecx = this and there is no This in the prototypes

The Implem_ItextHost.inc hold the implementation of ItextHost.He have all is needed in it ,constant,data,code .To reuse it just include it in your project and you have to write the lines using it ( the init and drawing operations).

[qWord]

Should it show different colored and sized text? - If so, it works (even without a debugger).
However, to get the text visible the window must be resized (-> InvalidateRect()).

[TouEnMasm]

Yes he must show all this colored and police effects.
I have just added those lines in the WM_PAINT message:

         invoke BeginPaint,hwnd,ADDR Ps
         mov hdc, eax
         invoke GetClientRect,hwnd, addr rect   
   ajout>>>>   invoke InvalidateRect,hwnd,addr rect,FALSE
                              
         invoke DrawText,hdc,addr asciihello, LENGTHOF asciihello -1,addr rect,DT_CENTER
         
         .if INITTEXTDRAW != 0

And he can be view even by me !
Many thanks for answer

[dedndave]

there are a few problems, Yves

first, the return value in WndProc does not seem to be getting set properly for some messages
this causes the window to behave strangely
for example, if i move the cursor to the edge, i get the sizing cursor
and the sizing cursor does not go away until i move to some non-client area that resets it

second, you already have a rectangle in the PAINTSTRUCT that tells you what needs to be painted
no need to get client recatngle, there
and - you can pass a NULL parm to InvalidateRect and it will use the entire client rectangle

but, thirdly, invalidating the rectangle between BeginPaint and EndPaint is messed up
you want some external event to invalidate the rectangle and UpdateWindow
InvalidateRect tells the OS that there is a region that needs to be redrawn
UpdateWindow tells the OS that a WM_PAINT message (and maybe a few others) needs to be sent

[qWord]

The InvalidRect() should be placed at the end of the WM_CREATE-Handler thus the text get visible.

[dedndave]

huh ?
you shouldn't have to invalidate the rectangle in WM_CREATE
the OS usually sends WM_SIZE and WM_PAINT after WM_CREATE is complete
what may be missing is the standard order of...
CreateWindow
UpdateWindow

the code is split up into so many INC files that it is hard to read

[qWord]

you shouldn't have to invalidate the rectangle in WM_CREATE
the OS usually sends WM_SIZE and WM_PAINT after WM_CREATE is complete
what may be missing is the standard order of...
CreateWindow
UpdateWindow

yes you are rigth.

[qWord]

AFAICS he is using PostMessage to force WM_COMMAND, which then creates the object - after the creation, the window must be invalidated.

[TouEnMasm]

I have windows XP3.I have put InvalidateRect in various places but i couldnt view now the colored text.
I have also made minor changes in the window loop.
Seems the result is random.
The one I post couldn't be show for me...

[qWord]

When building the EXE with your SDK, the program fails to create ITextServices: "No such interface supported"?

[TouEnMasm]

The itextservice and ITextHost are not translated in the SDK.
They are in the textinclude.inc with the source code (see first post).
Take care there frame are not standard.need ecx = this and there is no this:dword  in the define prototype.
I have find the origin of the trouble.
use

IID_ITextServices  GUID <8d33f740h,0cf58h,11ceh,<0a8h,9dh,00h,0aah,00h,6ch,0adh,0c5h>>

And not the one in the uuid.lib
The InvalidateRect is at the right place in the WM_PAINT message.
Now i have no more random results.

[TouEnMasm]

I have forgotten two things
There is a modyfy to do in the sdkrc7 files CHARFORMAT2W structure
Richedit.sdk

szFaceName WORD LF_FACESIZE dup (?)  ;WORD and not BYTE
size 74h for CHARFORMAT2W

The source code is cut in parts to allow the insertion of the implemention of ITextHost without writing a single line.Just include it where you want.

[qWord]

The InvalidateRect is at the right place in the WM_PAINT message.

Definitely not! You may take a look at the taskmanger.
As said, the invalidation is (probably) needed after creation of the object or if it's state has changed.

[dedndave]

i have been using this with good success
many of the programs i have looked at have an XOR EAX,EAX after .ENDIF that is used for all handled messages
but - i like this a little better because i can return different values for different messages
for example, with WM_CTLCOLORSTATIC (et al) you return a brush handle in EAX

Code Select Expand

    mov     eax,uMsg
    .if eax==WM_CLOSE
        INVOKE  DestroyWindow,hWnd
        xor     eax,eax                                 ;return 0

    .elseif eax==WM_DESTROY
        INVOKE  PostQuitMessage,NULL
        xor     eax,eax                                 ;return 0

    .else

DefPrc: INVOKE  DefWindowProc,hWnd,uMsg,wParam,lParam

    .endif
    ret

[TouEnMasm]

The hourglass that was shown was the effect of a conflict when painting.
Here is the soluce.

   .elseif uMsg == WM_PAINT ;return 0
         invoke GetClientRect,hwnd, addr rect                  
         invoke BeginPaint,hwnd,ADDR Ps
         mov hdc, eax
         
         invoke DrawText,hdc,addr asciihello, LENGTHOF asciihello -1,addr rect,DT_CENTER
         mov eax,rect.top
         add eax,20   ;exclude the last drawing to be invalidate
         mov rect.top,eax
         ;declare this rect to be redraw
         invoke InvalidateRect,hwnd,addr rect,FALSE ;
>>>>>>>>>> now we can draw the colored without problem

I don't know why there isn't this conflict with c++.
It must be perfect now.

The last modify is here ,changed DrawText by DrawTextEx

invoke DrawTextEx,hdc,addr asciihello, LENGTHOF asciihello -1,addr rect,DT_CENTER,NULL