GetOpenFileName causes an error

[jj2007]

JJ,
          Please give me the file MasmBasic.inc
          You use «include \masm32\MasmBasic\MasmBasic.inc»

Rui,
The file is part of MasmBasic, and I used it only because the library has a very powerful debugging macro. Replace the include with include \masm32\include\masm32rt.inc, and the code will assemble fine. Masm32rt.inc substiutes all lines from .586 to comdlg32.lib

Try ...

Code Select Expand

                invoke  GetOpenFileName, ADDR _ofn
         
                stc
                ret


... and you will see that you can call GetOpenFileName as often as you want, no crashes. The problem is below these lines...

EDIT: I have put lots of deb calls into your code; you can uncomment them if you have MasmBasic installed. From what I see, the crash happens in the GetOpenFileName call, but only if the section below has been processed before.
You should urgently check your usage of ebx, esi and edi. I have added a uses ebx to AbreFile, but this was not sufficient to prevent the crash. The deb macro is really useful for that...

deb usage:
   deb 1, "The first loop", ecx, esi$, edi$, MyReal10, ST(1)
   deb 2, "Second loop:", al, ecx, esi$, $My$

Rem   the debug macro preserves registers and flags
   can show FPU registers but trashes ST(6) and ST(7)
   the string content of registers (i.e. the memory pointed at) can be shown by using eax$, ecx$, esi$ etc.
   global and local variables can be shown as strings by using e.g. $buffer
   cancelling deb 1, ... does not cancel deb 2, ..., so you can test several loops in one go
   deb 1, ... deb 4, ... are being displayed, while deb 5, writes to a file:
   deb 5, "ToFile", eax, esi$, edi$ saves contents (without showing them) to DebLog.txt

[RuiLoureiro]

Jochen,
           1. Thanks for reply

           You should urgently check your usage of ebx, esi and edi.

           2. EDI usage: ONLY defined inside NxtLinFrm and GetNxtLin
                         never modified in any other place.
                         There, i have «mov edi, _pFrmBuf». _pFrmBuf is
                         defined when the prog starts (Mem is allocated ...)

              ESI usage: is modified in FindCRLF but have a limit in _LastTxtBuf

           I am quite sure theres not any problems with that registers and
           we dont need to preserve them.           

         3. Please, now, Try PrinterJJ.asm i attached. What happen ?
            I tried and i got «Memory was not freed»
           
            I did this:

; Free memory alloc and close file
CloseAll        proc
                pushfd
                ;
                cmp       _pTxtMem, 0
                je        short _n
                ;
                invoke    GlobalFree, _pTxtMem
                cmp       eax, NULL
                je        short @F               
;##############################################################################
       fn  MessageBox, _hWnd, "Memory was not freed", "Memory Error", MB_OK
;##############################################################################
@@:             mov       _pTxtMem, 0
                ;
_n:             cmp       _hFile, 0
                je        short @F               
                invoke    CloseHandle, _hFile
                mov       _hFile, 0
 
@@:             popfd
                ret
CloseAll        endp

Rui

[jj2007]

           2. EDI usage: ONLY defined inside NxtLinFrm and GetNxtLin

Rui,

esi, edi and ebx are being used by Windows APIs. You can use them only if you preserve them:

Code Select Expand

push esi
mov esi, 123
...
pop esi


If you modify them, e.g. in the WndProc or a proc called from inside the WndProc, then your code is bound to crash.

         3. Please, now, Try PrinterJJ.asm i attached. What happen ?

It crashes silently.

Will be offline for some days - I hope you can solve the mystery :thumbu

[RuiLoureiro]

esi, edi and ebx are being used by Windows APIs. You can use them only if you preserve them:

               As far as i know Windows APIs preserve them. It means i dont need to preserve
               that registers when i call a wAPI. As far as i know MS doesnt say
               you need to preserve it unless Windows APIs doesnt work properly. In
               other words, if you dont preserve them Windows APIs doesnt work properly.

I hope you can solve the mystery

               I solved it, i allocate memory when the prog starts. It is done in PrintIt

Will be offline for some days

               Jochen, thanks, and have a nice days :thumbu

 

[qWord]

               As far as i know Windows APIs preserve them. It means i dont need to preserve
               that registers when i call a wAPI. As far as i know MS doesnt say
               you need to preserve it unless Windows APIs doesnt work properly. In
               other words, if you dont preserve them Windows APIs doesnt work properly.

You must save them only inside callbacks (e.g. WndProc)