07-17-2022, 02:34 PM
Thank you for the responses. I did "solve" the problem but I want to reply to you both first.
To SMcNeill:
It would not be beneficial to give the source code since the programs require a specific directory structure and data files to execute properly. Also, what turned out to be the offending program is probably around 4000 lines long.
To mdijkens:
A bit of background on the programs would be useful here:
I started developing a "suite" of interrelated programs starting in the mid 80's. Because of QB program size restrictions I used $INCLUDE often as well as compiling multiple .BAS modules at into a single EXE.
The result has been about 60+ fairly large BAS programs compiled into around 40+ EXEs all using CHAIN (to go to other modules) for COMMON variables. I will probably be changing that.
To see if converting to QB64 was a job I wanted to tackle I "converted" 3 programs enough to run. So to your point, trying to combine them (all 60+) into one module was a thought I had but there are so many overlapping labels and line numbers as well as contradictory/reused variable names that I would give up if that was the only route.
--->
Now as to the original reason for this thread, after much insertion of my own debugging code and many recompilings of the larger of the 3 programs I was able to narrow the cause of the error down to several lines of code:
FIELD #10, 80 AS LG$
also
GET #1, rn
and perhaps I will still find others.
Strangely I didn't get the error every time one of these lines was executed.
If I REM these lines the error disappears completely. So it had something to do the the file I/O or access.
I rewrote some code before these lines which OPENed the file, unREMed the offending lines, and now it works fine.
I don't know why I didn't just get a more specific RUN TIME I/O error with error line # instead of the generic and extremely unhelpful Windows "program stopped responding" message.
Again, thanks for the replies. Will probably post more questions later.
A
To SMcNeill:
It would not be beneficial to give the source code since the programs require a specific directory structure and data files to execute properly. Also, what turned out to be the offending program is probably around 4000 lines long.
To mdijkens:
A bit of background on the programs would be useful here:
I started developing a "suite" of interrelated programs starting in the mid 80's. Because of QB program size restrictions I used $INCLUDE often as well as compiling multiple .BAS modules at into a single EXE.
The result has been about 60+ fairly large BAS programs compiled into around 40+ EXEs all using CHAIN (to go to other modules) for COMMON variables. I will probably be changing that.
To see if converting to QB64 was a job I wanted to tackle I "converted" 3 programs enough to run. So to your point, trying to combine them (all 60+) into one module was a thought I had but there are so many overlapping labels and line numbers as well as contradictory/reused variable names that I would give up if that was the only route.
--->
Now as to the original reason for this thread, after much insertion of my own debugging code and many recompilings of the larger of the 3 programs I was able to narrow the cause of the error down to several lines of code:
FIELD #10, 80 AS LG$
also
GET #1, rn
and perhaps I will still find others.
Strangely I didn't get the error every time one of these lines was executed.
If I REM these lines the error disappears completely. So it had something to do the the file I/O or access.
I rewrote some code before these lines which OPENed the file, unREMed the offending lines, and now it works fine.
I don't know why I didn't just get a more specific RUN TIME I/O error with error line # instead of the generic and extremely unhelpful Windows "program stopped responding" message.
Again, thanks for the replies. Will probably post more questions later.
A