A program I have been working on lately has a RichEdit control. There are 5 small files (32, 52, 90, 106 and 134 bytes respectively) which I try to load into that control by selecting one from a ComboListBox. After the desired file is chosen, the program opens the file, gets the file size, allocates memory for that size, reads the file, transfers it to the control, and then frees the allocated memory.
Everything works fine if the 52-byte file is not selected and I can keep on selecting the other four files ad infinitum in any order without any problem. However, whenever I select the 52-byte file after selecting any of the others, the program crashes within the kernel32.dll. When the 52-byte file is the first one selected, it loads without any crash; however, the crash occurs when another one is selected. :dazzled:
Such behaviour did not occur under WinXP.
Eventually, I solved that aggravation by allocating 256 bytes more than the file size :U. I did not however tried to determine what would have been the minimum amount of extra memory required to satisfy the kernel.
Ray,
How are you loading the text into the rich edit control ?
And is it a Rich Edit 1.0 or 2.0.
QuoteHow are you loading the text into the rich edit control ?
After reading the file in the allocated memory hMem
invoke SendMessage,hEdit,WM_SETTEXT,0,hMemQuoteAnd is it a Rich Edit 1.0 or 2.0.
This how I create it:
.data
CtlStyle db "RichEdit",0
szRich db "RICHED32.DLL",0
.code
WinMain proc
invoke LoadLibrary,ADDR szRich
WndProc proc
.elseif uMsg == WM_CREATE
mov edx,WS_VISIBLE or WS_CHILDWINDOW or \
WS_VSCROLL or ES_NOHIDESEL or \
ES_AUTOVSCROLL or ES_MULTILINE
invoke CreateWindowEx,WS_EX_CLIENTEDGE,ADDR CtlStyle,NULL,
edx,0,0,778,558,hWin,799,hInstance,NULL
mov hEdit, eax
Raymond
Ray,
Just a quick suggestion, try using the API SetWindowText() to load the data into the rich edit control. The one you are using is a rich edit 1.0 control and it should be trouble free in win98se.
Quote from: raymond on May 19, 2007, 03:56:34 AMEventually, I solved that aggravation by allocating 256 bytes more than the file size :U. I did not however tried to determine what would have been the minimum amount of extra memory required to satisfy the kernel.
Is the file size understated? But the formating runs past file end?
Regards, P1 :8)
Here's the message I was getting:
LIVRE caused an invalid page fault in
module KERNEL32.DLL at 018f:bff7a125.
Registers:
EAX=004116bc CS=018f EIP=bff7a125 EFLGS=00010212
EBX=0050ff54 SS=0197 ESP=0063fbec EBP=0063fc2c
ECX=0041000c DS=0197 ESI=004116bc FS=3a4f
EDX=00100000 ES=0197 EDI=000fe898 GS=3a3e
Bytes at CS:EIP:
8b 03 a8 01 74 25 25 fc ff ff 0f 8b 53 08 03 f8
Stack dump:
0063fc2c 000fe898 00411654 00000068
bff7a3a0 00410000 004116bc 000fe898
00000000 0041000c 00410000 00411654
00000040 00000000 0000050f 00000412
After further investigation, the error occurs while the LocalAlloc is being processed in the following code:
invoke CreateFile,ADDR txtbuf,GENERIC_READ or GENERIC_WRITE,0,0,OPEN_ALWAYS,0,0
mov hFile,eax
.if eax == INVALID_HANDLE_VALUE
ret
.endif
invoke GetFileSize,hFile,0
mov filesize,eax
; add eax,1
invoke LocalAlloc,0,eax
Changing to GlobalAlloc made NO difference. Using LPTR instead of 0 also made NO difference. The problem could be repeated time after time whenever the opening of one of the two smaller files was followed by opening a larger file. It never would occur while cycling only through the three larger files at random.
Uncommenting the add eax,1 (or anything larger) is sufficient to avoid the error!!!! :dazzled:
MYSTERIOUS
Raymond
Try using "EM_STREAMIN" rather than WM_SETTEXT - it also handles all of the buffering, so you don't need to allocate.