Can anyone help me?
I put a RichEdit control in a dialog box in the resource file like this:

IDD_DIALOG1 DIALOG 0, 0, 437, 208
CAPTION "Rich Test"
FONT 8, "MS Sans Serif"

When i run the program and try to read text from file into the RichEdit using EM_STREAMIN message, previos text disappears, but newly open text from file does not display.

Here is my StreamIn callback function:

StreamIn PROC dwCookie:DWORD, pbBuf:LPBYTE, cb:LONG, pcb:LPDWORD
invoke ReadFile, dwCookie, pbBuf, cb, pcb, NULL
mov eax,
StreamIn ENDP

File opens reads successfully and the StreamOut function works perfectly, but I have this problem using StreamIn.

Is there anything I have to do with the Rich Edit control before or after streaming?
I use RichEd20.dll

And one more question.
How about using Streams to highlight syntax? Is it as slow as changing charformat for selected text?

Tanx in advance.
Posted on 2002-06-03 02:56:13 by Vaxon
what format do you have streamed in ?
TEXT or RTF - if RTF there is maybe an structural error in the RTF syntax. Otherwise you might have an error in your stream callback proc. Can you post the essentials of it here?
Posted on 2002-06-03 04:26:57 by beaster
I use SF_TEXT format.
I attached my program zipped.
Posted on 2002-06-03 04:31:51 by Vaxon
one oddity I can see is, that you dont return NULL in your callback proc.
Return Value

The return value is zero to continue to the stream operation, or nonzero to abort it.
since I dont use MASM I cannot check this out for you...
Posted on 2002-06-04 03:51:06 by beaster
heres a working streamin proc (in C and for richedit 1.0 only!)

DWORD CALLBACK editstreamcb(DWORD dwCookie, LPBYTE pbBuff, LONG cb, LONG FAR *pcb)
int i;

i = lstrlen(pStrings[ABOUTTEXT] + g_dwCnt);
if (i > cb) {
*pcb = cb;
memcpy(pbBuff,pStrings[ABOUTTEXT] + g_dwCnt,cb);
g_dwCnt = g_dwCnt + cb;
return 1; // continue
} else {
*pcb = i;
memcpy(pbBuff,pStrings[ABOUTTEXT] + g_dwCnt,i);
return 0; // done

- in this example no file is read, just a "very long" string (its a rtf resource)
- the dword pointer pcb points to should be filled with the number of bytes read.
- the documentation beaster has mentioned seems to be wrong. 1 continues and 0 says "done".

Posted on 2002-06-04 07:17:44 by japheth
I haven't translated japheth's c source yet, but beaster's suggestion fixes the problem. Maybe I missed something, but why were you returning the offset of pcb in eax?
Posted on 2002-06-04 09:03:10 by Will
There is a full working rich text editor in the MASM32 example code that does all of this stuff correctly, the same technique works for both richedit 1 and 2+3.


Posted on 2002-06-04 09:33:35 by hutch--
How come I always look at the new examples right after installing a new masm package and then completely forget about them?
Posted on 2002-06-04 10:25:39 by Will
Yes, the problem was in that value in eax.
And I can't explain why I wasn't returning 0 in it.
Just thought there should be something instead of 0.
I guess I'm just stupid
Thank you all for helping!!!
Gonna read the example now...
Posted on 2002-06-04 15:38:03 by Vaxon