Posts: 2,700
Threads: 124
Joined: Apr 2022
Reputation:
134
Instead of RUN use Shell and Shell a compiled bas. You can Compile a bas and Shell that exe (to Run it) on the fly if you are careful with folders.
b = b + ...
Posts: 16
Threads: 5
Joined: Jul 2022
Reputation:
0
Thanks. Tried it:
Replaced RUN with SHELL. It didn't solve problem (still got WIN error) and when SHELLING the calling program remains open which I don't want since going between programs leaves multiple iterations of programs still open.
Also, I am not sure what you mean by "Shell a compiled bas." I am compiling using QB64.exe and running the EXEs.
(FYI the original QB programs used CHAIN because of common variables but I removed CHAIN and used RUN, but that's going to be a question for a different thread.)
A
Posts: 1,507
Threads: 160
Joined: Apr 2022
Reputation:
116
Can you share the code so we can test the issue ourselves?
Posts: 70
Threads: 7
Joined: Apr 2022
Reputation:
10
I'd say start by integrating all 3 sources in one.
Just change overlapping labels/linenumbers or break up in easier to maintain subs and functions.
Chain was used because of memory limitations.
Now with QB64 this is virtually gone.
45y and 2M lines of MBASIC>BASICA>QBASIC>QBX>QB64 experience
Posts: 16
Threads: 5
Joined: Jul 2022
Reputation:
0
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
Posts: 70
Threads: 7
Joined: Apr 2022
Reputation:
10
Thanks for your clarification.
Been there also in the 80's; used same techniques.
Your errors are strange and non-saying indeed
With refactoring of much of my old ('80-'90) code I've, in a lot of cases, rewritten the file access parts too to get things reliable.
Another point of attention is serial
45y and 2M lines of MBASIC>BASICA>QBASIC>QBX>QB64 experience