Alright,

My proggy is stuck on OPENFILENAME now... sometimes it works and sometimes it doesn't.. out of friggen nowhere, and I'm getting seriously mad...

My wild guess is that the .data? and .data section are going crazy again... Earlier posts said that it could be fixed with an ALIGN something parameter...

Anyone can give me some decent help regarding this ?

TIA,
JC


Changed the Title so searching for it won't get any misleading hits

;)
Posted on 2002-04-06 15:58:45 by JimmyClif
Jimmy,

I have found OPENFILENAME to be unproblematic, reasonably straight forward stuff to use. Perhaps you could post some of the code so others can see what is happening.

Regards,

hutch@movsd.com
Posted on 2002-04-06 16:13:30 by hutch--
hutch--

Yes, OPENFILENAME is respectively unproblematic...

here's the code I used:



mov ofn.lStructSize, SIZEOF ofn
push hDlg
pop ofn.hwndOwner
push hInstance
pop ofn.hInstance
mov ofn.lpstrFilter,o$ FilterString
mov ofn.nMaxFile, 256
mov ofn.lpstrFile,o$ szTemp
mov ofn.Flags,OFN_FILEMUSTEXIST or OFN_NOLONGNAMES or \
OFN_NOCHANGEDIR or OFN_PATHMUSTEXIST
invoke GetOpenFileName,a$ ofn
.IF eax==TRUE
mov ax,ofn.nFileOffset
lea edx,szTemp
add edx,eax
invoke lstrcpy,a$ LevelDatFileName,edx
.ELSE
mov eax,TRUE
ret
.ENDIF


Substitute a$ and o$ for ADDR respectively OFFSET
szTemp is 256 bytes big. and I put ofn OPENFILENAME <?> in .data?

I edited a bit to get some higher readability
Posted on 2002-04-06 16:37:21 by JimmyClif
hutch--

I found the little bugger which drove me nuts for hours...

It's not documented but when I added a

mov dword ptr ,0

before the call to GetOpenFileName it now works all the time.

---

I was persuaded that it was incorrectly aligned again, just like the error I had with QueryPerformanceCounter a while ago...

Well, thanks a lot tho ;)

JimmyC
Posted on 2002-04-06 16:57:26 by JimmyClif
Yesterday I had very weird errors using GetOpenFileName. Like you said, sometimes it didn't shop up. Eventually, the background of my programs memu became black like the system was out of resources, the program crashed a few times and finally the system rebooted itself which rarely happens with my machine.. I don't know if it all came because of that code but I never had similair problems.
The solution was putting a zero length string (one null byte) into the buffer for the filename. As I used a buffer from stack it was filled with random stuff. Clearing it beforehand did solve the problems.
However since your using a buffer from the .data? section it should have been initialized to zero bytes already. :confused:

Thomas

Edit: I saw you already found the problem :grin:
Posted on 2002-04-06 16:57:52 by Thomas
LOL... thanks Thomas...

Windows is weird sometimes :grin:
Posted on 2002-04-06 17:01:22 by JimmyClif




.IF eax==TRUE
mov ax,ofn.nFileOffset
lea edx,szTemp
add edx,eax
invoke lstrcpy,a$ LevelDatFileName,edx
.ELSE
mov eax,TRUE
ret
.ENDIF

Also, I'd change the first mov of above to a movzx.. otherwise you can't then reliably use the whole eax as source if you just wrote to ax.
Posted on 2002-04-07 04:33:01 by Maverick
Sure I can :) as I only mov something into ax after being sure that
the whole eax equals 1 :grin:
Posted on 2002-04-07 12:36:52 by JimmyClif
since the buffer is used for both input and output, it's not too strange
that you have to properly initialize it before calling the Get*FileName
functions - but it's very easy to overlook :).
Posted on 2002-04-07 12:52:25 by f0dder

Sure I can :) as I only mov something into ax after being sure that
the whole eax equals 1 :grin:
I wouldn't do that.. because you're making assumptions here. The SDK says that the return value is either zero or non-zero.. if in the current(s) Win32 implementations you get 1, it doesn't mean that in other (e.g. future) implementations they won't return -1, still being the documented "non zero", in place of 1.

Then hunting the bug down will be a bit painful. It's not that MOVZX is gonna make your code slower anyway, so I'd rather be on the safe side.
Posted on 2002-04-07 17:32:46 by Maverick
PS: I saw you're checking against a symbol, TRUE, which if EQU 1 then would make your code safe.

Then I'd just not use TRUE=1, but only check if result is zero or non-zero. ;)

It's just safer, considering what the SDK states.

Anyway.. it's just a advice coming from years of bughunting, take it softly. ;)
Posted on 2002-04-07 17:36:01 by Maverick
Maverick,

I guess you're right... hrm.. I was sure the return value was supposed to be 1 when succesfull... but having checked back I see you're right... It says non-zero upon success... Guess I can be lucky that as result I get 1 out of it :)

Anyway.. thanks for the suggestion... I updated my code already.

Cheers,
JimmyClif
Posted on 2002-04-07 17:51:38 by JimmyClif
Hi Jimmy :)
Never trust Microsoft.. things may change over time ;P

BTW: does anybody know if it is *officially documented* anywhere which CPU registers Windows functions will not change? (i.e. commonly known to be EBX,ESI,EDI,EBP)


Was this info discovered or documented?
Posted on 2002-04-07 17:58:16 by Maverick