my mp3Player is almost done now - but beta-tests showed me, that it is completely incompatible to winNT-based OS'.
drwatson creates an error protocoll (shown below). on my win98 (the developing area) it works perfectly.

if you look at it, you'll notice, the error (access fault) is generated in the GetKeyStateW-API. it is used with the common dialoges for opening and saving. i dont use it and so I can't prevent the use of it:

(this is only the most important seeming part of the protocoll)


eax=004a2f08 ebx=00000019 ecx=000b0302 edx=00470588 esi=0012fda4 edi=004a2fbc
eip=77e8307f esp=0012fd08 ebp=0012fd38 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000202


Function: DrawStateW
77e83060 ff7514 push dword ptr [ebp+0x14] ss:0102e73e=????????
77e83063 ff7510 push dword ptr [ebp+0x10] ss:0102e73e=????????
77e83066 56 push esi
77e83067 ff75f8 push dword ptr [ebp-0x8] ss:0102e73e=????????
77e8306a ffd1 call ecx
77e8306c 8b4df8 mov ecx,[ebp-0x8] ss:0102e73e=????????
77e8306f 8945fc mov [ebp-0x4],eax ss:0102e73e=????????
77e83072 e898f3feff call IsWindow+0x75 (77e7240f)
77e83077 85c0 test eax,eax
77e83079 0f842a010000 je DrawStateW+0x14e0 (77e831a9)
ERROR ->77e8307f f6437bc0 test byte ptr [ebx+0x7b],0xc0 ds:00efea1f=??
77e83083 0f8520010000 jne DrawStateW+0x14e0 (77e831a9)
77e83089 83fe2f cmp esi,0x2f
77e8308c 0f86a0000000 jbe DrawStateW+0x1469 (77e83132)
77e83092 83fe37 cmp esi,0x37
77e83095 0f840e010000 je DrawStateW+0x14e0 (77e831a9)
77e8309b 83fe39 cmp esi,0x39
77e8309e 0f8405010000 je DrawStateW+0x14e0 (77e831a9)
77e830a4 81fe10010000 cmp esi,0x110
77e830aa 0f84f9000000 je DrawStateW+0x14e0 (77e831a9)
77e830b0 81fe32010000 cmp esi,0x132
77e830b6 0f83d7000000 jnb DrawStateW+0x14ca (77e83193)
Posted on 2002-11-27 13:00:27 by hartyl
IsWindow might modify the content of the ebx register under WindowNT.

ds:00efea1f looks weird to me.

Just save it before and restore it after IsWindow()
(IsWindow+075h ???)

h.
Posted on 2002-11-27 15:38:40 by hitchhikr

IsWindow might modify the content of the ebx register under WindowNT.

eh? why should iswindow (the one in user32.dll) do that?

things to look out for:
- register preservation in wnd-/dlgproc
- stack misalignment (not the case here, it seems)
- uninitialised data passed to api functions

you might search the board as well, there've been some similar threads.
Posted on 2002-11-27 16:37:16 by Tola
byte ptr ,0xc0
ebx here is used to point a memory address... did you preserve ebx before you used it?
Posted on 2002-11-27 18:58:39 by stryker
Hi all.

Hartyl, also make sure you are passing values allowed by NT. In my case I was passing 0ffffh to the set background color API call:

invoke SetBKMode, HDC, OPAQUE
invoke SetBKColor, HDC, 0ffffh

In Windows 9x it worked fine, but on NT all fonts appeared as black squares instead of letters.

After a lot of debugging I changed it to:

invoke SetBKMode, HDC, OPAQUE
invoke SetBKColor, HDC, 0fffh ;one less "f"

And now the text displays correctly on both 9x and NT.

But now I have another problem, when I print one letter on top of another, the last overwrites the former when I display it on a window on both 9x and NT, or when I print it on 9x, but when I print it on NT, the first letter shows thru the transparent areas of the second one!!!

Later...
Posted on 2002-11-28 05:46:28 by CarlosM7
nah! i think i didn't express me right;
this error happens, when using the open/close-common dialogbox under NT/2000/XP. i only use GetOpenFileName and after the dialog appears, this error is caused. so it happens in an api-call, done by the dialogbox (proc). i can't modify this code. hmmm... to find out the problem, the OPENFILENAME-struct shoulda be useful. this is how i defined it in the .data-section



ofn OPENFILENAME <SIZEOF(OPENFILENAME),NULL,NULL,offset loadfilter,0,0,1,\
offset files,MAXFILE,NULL,NULL,offset initdir,NULL,\
OFN_PATHMUSTEXIST or OFN_FILEMUSTEXIST or OFN_ALLOWMULTISELECT or OFN_EXPLORER,\
NULL,NULL,NULL,NULL,NULL,NULL>

//the definition of the prototype of the OPENFILENAME-struct
typedef struct tagOFN { // ofn
DWORD lStructSize;
HWND hwndOwner;
HINSTANCE hInstance;
LPCTSTR lpstrFilter;
LPTSTR lpstrCustomFilter;
DWORD nMaxCustFilter;
DWORD nFilterIndex;
LPTSTR lpstrFile;
DWORD nMaxFile;
LPTSTR lpstrFileTitle;
DWORD nMaxFileTitle;
LPCTSTR lpstrInitialDir;
LPCTSTR lpstrTitle;
DWORD Flags;

WORD nFileOffset;
WORD nFileExtension;
LPCTSTR lpstrDefExt;
DWORD lCustData;
LPOFNHOOKPROC lpfnHook;
LPCTSTR lpTemplateName;
} OPENFILENAME;


any mistakes in there?
Posted on 2002-11-28 12:43:41 by hartyl
You need to insert the hinstance information.
Posted on 2002-11-28 18:53:52 by roticv
i haven't tried it yet, but the error and the possible solution seem to go together...
but, Win98 generates no error without the hInstance-info (btw, i insert the owner during the program, but not the instance...) and WinXP/NT/2000 does? interesting...
Posted on 2002-11-29 13:18:54 by hartyl
newest beta-tests showed, that that changed nuts... nice idea, but it wasnt the problem.
any further suggestions?
Posted on 2002-11-29 13:39:51 by hartyl
i have just noticed, that i have a winXP-partition on another computer, so i could beta-test it on my own and tracked down
the problem to this piece of code:
i thank everyone who tries to read into my code!



/*this one gets the files-string of the GetOpenFileName-func, reads it out and adds the information to a "list" (a struct with the
information and a pointer to the next item). the WriteID3 actually inserts the id3-tag info into the entry of the list specified.*/

appendList proc
LOCAL strings:ptr DWORD
LOCAL num:DWORD

lea esi,files
xor ebx,ebx
scan_string: ;gets the number of files selected (multiselect)
mov al,[esi]
inc esi
test al,al
jnz scan_string
inc ebx
mov al,[esi]
test al,al
jnz scan_string
shl ebx,2
invoke LocalAlloc,LMEM_FIXED or LMEM_ZEROINIT,ebx ;gets some memory to store pointers to the file's name
mov strings,eax
xor ebx,ebx
lea esi,files
mov edi,strings
get_ptr:
mov dword ptr [edi+ebx*4],esi
inc ebx
@@:
mov al,[esi]
inc esi
test al,al
jnz @b
mov al,[esi]
test al,al
jnz get_ptr
mov eax,dword ptr [edi]
invoke lstrcpy,addr initdir,eax
mov eax,root
scan_root2:
assume eax:pentry
mov ecx,eax
mov eax,[eax].n
test eax,eax
jnz scan_root2
mov num,ebx
mov ebx,01
mov edx,strings
add_file:
push ebx ;counter
push ecx ;last entry
push edx ;strings
invoke LocalAlloc,LMEM_FIXED or LMEM_ZEROINIT,sizeof(entry) ;grab a new item
pop edx
pop ecx
pop ebx
assume ecx:pentry
mov [ecx].n,eax ;the next item is the new one
mov ecx,eax
assume ecx:pentry
lea edi,[ecx].path
mov esi,dword ptr [edx]
invoke lstrcpy,edi,esi ;copy path of files-buffer to path of listitem
lea esi,backslash ;add a backslash
invoke lstrcat,edi,esi
lea edi,[ecx].file
mov esi,dword ptr [edx+ebx*4]
invoke lstrcpy,edi,esi ;copy filename of files-buffer to file of listitem
invoke WriteID3,ecx ;this func does not cause an error
compare:
inc ebx
cmp ebx,num
jb add_file
invoke LocalFree,strings ;finally free the pointers after prcessing
mov byte ptr [files],00
invoke lv_draw,addr listview ;re-draw the listview
ret
appendList endp
Posted on 2002-11-30 04:40:44 by hartyl