Debugger Problem

[LRantanen]

I have a rather peculiar problem, which I hope somebody could give some advice.

First, when I run it in debugger, it works OK, but trying to run the compiled program causes a GPF.

However, I have been able to trace the statement where program crashes although I don't know why.

I try to explain what happens.

I have a global array of UDT's.

    GLOBAL MyRec(1 TO 9) AS tagMYREC

Program saves the information in this array to disk using following code

    ...
    hFile = FREEFILE
    OPEN sFileName FOR RANDOM AS hFile LEN = SIZEOF(MyRec)
    FOR lIndex = 1 TO UBOUND(MyRec)
        PUT hFile, lIndex, MyRec(lIndex)
    NEXT
    CLOSE hFile
    ...

Then it is read back in following code

    ...
    hFile = FREEFILE
    lIndex = 1
    OPEN sFileName FOR RANDOM AS hFile LEN = SIZEOF(MyRec)
    WHILE NOT EOF(hFile)
        GET hFile, lIndex, MyRec(lIndex)
        INCR lIndex
    WEND
    CLOSE hFile
    ...

After this following code is executed. Program crashes at CreateWindowEx (at least it never gets executed).

    GetClientRect hWndParent, rcl
    hWndList = CreateWindowEx(  %WS_EX_CLIENTEDGE, _
                                $WC_LISTVIEW,"", _
                                %WS_VISIBLE OR %WS_CHILD OR %WS_BORDER OR %LVS_REPORT OR _
                                %LVS_EDITLABELS OR %LVS_SHOWSELALWAYS, _
                                1, 1, rcl.nright - rcl.nleft- 2, rcl.nbottom - rcl.ntop - 2, _
                                hWndParent, _
                                %ID_LISTVIEW, _
                                hInst, _
                                BYVAL %NULL )

The problem is somehow connected to the reading of data back from the disk because if I change line

WHILE NOT EOF(hFile)
to

WHILE lIndex<10

everything works again. I see that my original code tries to read record number 10. Why it is doing it because I wrote only nine records to the disk. Has this something to do with the problem? I can't see how the CreateWindowEx could be involved here.

As I said in the beginning, the debugger is useless here because the original code works OK in debugger.

I certainly hope somebody can give me some advice.

TIA

Lasse Rantanen
[email protected]

[Eric Pearson]

Lasse --

I haven't tried it (because you didn't include an easily compilable example) but my guess is that when EOF is used with FOR RANDOM it works like it does with FOR BINARY. In other words, it does not return True until after a read operation has failed. RANDOM files are really just a specialized case of BINARY, where the record length is fixed. The Help File says this...

If filenum is a binary file, EOF returns TRUE only if the most recent file operation was a read operation and that operation couldn't read the requested number of bytes.

Since PowerBASIC keywords are capitalized in the Help File, "a binary file" is not exclusively limited to "OPEN...FOR BINARY". I'd nominate that sentence for clarification in the next version of the Help File, but it is technically accurate. But it could be more precise.

The reason that it works in the debugger is that $DEBUG ERROR ON is automatically used, so the debugger protects you from GPFs caused by array out-of-bounds errors. (Actually, the debugger is protecting itself. If an app GPF'd during a debugging session it would be virtually impossible for the degbugger to handle it.) When you run the EXE directly, an invalid array subscript (which is caused by the EOF loop running one extra cycle) is causing the GPF.

The CreateWindowEx function has nothing to do with anything. It's just the next line of code after the "real" error. (Sometimes a GPF report is delayed by Windows for a split second, so it might not be the very next line of code.)

-- Eric
------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>



[This message has been edited by Eric Pearson (edited February 08, 2000).]

[Matthew Berg]

The problem is somehow connected to the reading of data back from the disk because if I change line

WHILE NOT EOF(hFile)

to

WHILE lIndex<10

everything works again.

So why not change it to WHILE lIndex <= LOF( hFile ) \ SIZEOF( MyRec )?

[LRantanen]

Thank you guys,

Eric for explaining what happens and Matthew for supplying a solution.

Thank you,

Lasse Rantanen
[email protected]

------------------