One of my codes crashes PbWin 8.04

[Keith Waters Member Find all posts View Profile Close Keith Waters]

PbWin 8.04 crashes when I attempt to compile one of my programs that compiles ok with 8.03.

Error signature:
AppName: pbwin.exe AppVer: 0.0.0.0 ModName: pbwin.exe
ModVer: 0.0.0.0 Offset: 00028d00

In an attempt to isolate the problem, I’ve replaced the contents of WinMain by simply msgbox "Hello".

The program has a number of include files. I began commenting out the #INCLUDE statements one by one. At first, this made no difference as the compiler still crashed. Then I removed one further #INCLUDE and the program compiled. “Ah – something wrong in that file”, I thought.

I was wrong. I then uncommented that same #INCLUDE (checked that compiler still crashed) and commented out another one of the remaining #INCLUDE statements – program compiled ok. In other words, I can now comment out any one of the remaining #INCLUDE and the program compiles – which one I choose doesn’t matter.

Further experiment – don’t comment out that last randomly picked include so the code still crashes compiler. Now add the following empty subroutine and the program compiles ok.

SUB LazyElephant ()
END SUB

It is position sensitive. Adding this LazyElephant subroutine after the last uncommented #INCLUDE makes no difference. It has to be inserted either before all #INCLUDE or somewhere in their midst.

Any ideas?
Keith

[norbert doerre Member Find all posts View Profile Close norbert doerre]

You don't tell much about the code leading to crash of PB.
The symptoms You describe with few words remind me on a situation I just experienced two days ago - after six years the first time.

I guess You to create a NEW .bas file from scratch and then retype or piecewise copy/paste the code. Leave out all .inc files except winapi and compile. You will notice that at first everything will run OK - perhaps except some debugger notes coming from incomplete coding.
Then simply add one .inc after the other maintainig the correct order.
As soon as You notice a crash the bug is probably inside that .inc file.
If You don't notice a crash, then in Your former source code there may be one or more lines containing unallowed chars, like ALT-0255 or similiar.
I experienced just this using copy/paste with XP Prof.

[Keith Waters Member Find all posts View Profile Close Keith Waters]

Ok – I’ve narrowed it down to one include file the contents of which is as follows.

$BRAND_FILE      = "ABC_Logo.bmp"     'Name of brand image file
$BRAND_RESOURCE  = "ABC_LOGO.BMP"     'Name of brand image resource

FUNCTION SaveAsHtml (BYVAL hWnd    AS DWORD,  BYVAL style    AS LONG,_
                     BYVAL sDirSrc AS STRING, BYVAL sDirDest AS STRING,_
                     BYVAL sName   AS STRING, BYVAL sHtml    AS STRING) AS LONG
  LOCAL sBuff AS STRING

  TRY
    FILECOPY sDirSrc + $BRAND_FILE, sDirDest + $BRAND_FILE
  CATCH
  END TRY

  sBuff = sHtml
  REPLACE "RES:" + $BRAND_RESOURCE WITH $BRAND_FILE IN sBuff
  FUNCTION = File_Save (hWnd, %MB_RETRYCANCEL, sDirDest + sName, sBuff)

END FUNCTION

When I comment out the TRY, CATCH, END TRY (it is redundant anyway, as MCM will no doubt tell me) the program compiles. When I leave it in, PbWin8.04 crashes.

I tried what you suggested Norbert and made a fresh include file. That didn’t make any difference. Strangely, if I paste the contents of the file into my main file and comment out the #INCLUDE, I get no problem. The compiler crash only occurs when the SaveAsHtml function is in the include file.

[Michael Mattias Member Find all posts View Profile Close Michael Mattias]

I don't use TRY..CATCH... FINALLY (but I want to start)...

.. however....

In the help for TRY..CATCH..FINALLY, the {error-handling statements} for the CATCH is in squiggly brackets, meaning mandatory.

You might try putting 'something' in the CATCH area, e.g. "Dummy=0"

Yes, if 'something' is required then this would be a bug in the compiler (missed edit) , but nothing is perfect.

MCM

[Keith Waters Member Find all posts View Profile Close Keith Waters]

Nope – it’s not that. Just tried sBuff = “” in the CATCH area.

I can’t help feeling this problem is not entirely due to this single include file. One of the files that is #INCLUDEed before the one we’ve just talked about contains simply,

$TGF_KEYWORDS = "ARC,ARCTO,CIRCLE,END,GO,GOTO,HOLE,ORIGIN,PAPER,SHAPE,SIZE,START,TRACE,TURN,TURNTO"
$TGF_METACOMS = "#INCLUDE"

When I copy the contents of this file into the main file and comment out the #INCLUDE the program compiles. Again, the crash only occurs if the include file is used. There are 66 included files in total.

Added:
And yet there is something significant about the include file (the one with the TRY/CATCH). If I place my aforementioned LazyElephant subroutine any where before the #INCLUDE, the program compiles. Place it after the #INCLUDE and the compiler still crashes.

[Michael Mattias Member Find all posts View Profile Close Michael Mattias]

The simple bottom line here is, the compiler should never abort: it should either compile your program file or report an error doing so.

And, since this is a third-party application for which you do not have source code, your best - and possibily only - source of satisfaction is the publisher.

ZIP up all the files needed to 'not compile' and send to [email protected]. That's why they are there.

If there is a bug in the compiler (and with a GPF occurring that's pretty much a given, since it shouldn't do that), your effort will ensure that a fix is made and will be provided all of us at some point in the future.

MCM

[norbert doerre Member Find all posts View Profile Close norbert doerre]

Keith,
I'm still convinced that the compiler is working OK.
I told You already that last weekend I had a similiar crash with only one single very short line of code, - see in the forum.
I pasted only a few lines of code from a snipped into my project.
Hereafter, the compiler crashed.
I commented out one line by the other, until I found the bug in a single line of code which was refused from beeing compiled, even if it looked correct.
I tried to find the bug anywhere else but not inside this line. After some hours of searching I simply deleted the line and rewrote it.
Compilation is error free now. There existed an Alt-0255 char inside this line, and I can't remember ever to have coded that.

[Keith Waters Member Find all posts View Profile Close Keith Waters]

Norbert

Perhaps I should have posted an update here before. I followed Michael’s advice and sent the zipped up code to PowerBasic support. They tracked the problem down to one line in one of my include files. The file simply contains equate settings to suppress compilation of sections in the following included CommCtrl.inc. Commenting out the offending line fixes the problem. Retyping the line does not fix the problem. The offending line is

%NOANIMATE = 1

In other words, commenting out the line means that the animation control section of CommCtrl.inc is included in the compilation whereas it would not be included as I had it. I do not use the animation control in my program.

The program uses Win32api.inc, CommCtrl.inc, and ComDlg.bas, which is a heavily modified form of an older supplied ComDlg.inc. PB Support notes that if the unmodified PB supplied versions of these files are used, there are compiler errors but no crash. The problem has been logged with their R&D department for further investigation.

I think Michael’s point is valid, that is the compiler should never abort: it should either compile your code or report an error.

Keith

[Larry Kruse Member Find all posts View Profile Close Larry Kruse]

I also have (had) code that behaved the way Keith described. It worked fine in 8.03, but produced the identical error in 8.04. BTW after clearing the Microsoft window, the compiler didn’t close out but reported “Cannot access resource compiler results.”

I just tried commenting out the offending %NOANIMATE = 1 and it solved the problem for me also. Thank you.