 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Close all after crash.
| Author | Message | ||||
| Paul_L Guru  Joined: 03/03/2016 Location: United StatesPosts: 769 |
Running under DOS I had a bunch of debug files open for output, then the darn thing crashed. Some confusion ensued when I tried to figure out which files had been left open. Would a CLOSE ALL command be a good idea? Would it be a mess to implement? If you don't know which buffers are open and you type CLOSE #1, #2, #3, #4, #5, #6, #7, #8, #9, #10 <enter> would it close any buffers that were open and ignore any buffers that weren't open? Paul in NY |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3292 |
Without testing it I think that would cause an error. It can't be that hard to keep track of files that you have open! This is a programming language - so program it! Geoff Geoff Graham - http://geoffg.net |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
If you had #1 open, it 'might' close it but would certainly crash at the first unopened one. With the DOS version, simply close the window and reopen it to be sure that there are no leftovers from a crash. Jim VK7JH MMedit |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Add a subroutine to close all the files. [code] SUB ClOSEALL ON ERROR IGNORE CLOSE #1 CLOSE #2 CLOSE #3 CLOSE #4 CLOSE #5 CLOSE #6 CLOSE #7 CLOSE #8 CLOSE #9 CLOSE #10 ON ERROR CLEAR END SUB [/code] You can then use CLOSEALL to close all the files without generating any errors. Microblocks. Build with logic. |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
@Geoffg - Of course it isn't hard to keep track of which files you have open ..... if you know where you are in the code when it crashes! The DOS version will put a message on the screen giving you the line number. But if the line that crashed is in a bottom level primative procedure that is called from all over the place you need a trace. I'm trying to send all debug messages to a file so that when the program moves from DOS to a PIC without a screen I can look at the debug file, but when it crashes I have to be able to close the files to flush the file buffers then look at the file contents. @MicroBlocks - That's a nice idea Jean, except that it will have to be in a standalone program. After the crash you run CLOSEALL and flush all the buffers. Simple, thanks. Paul in NY |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
Hey Geoff, I'm sorry to be a nag but I just found this in the latest DOS manual under the OPEN fnam$ command description: "The INPUT, LINE INPUT, PRINT, WRITE and CLOSE commands as well as the EOF() and INPUT$() functions all use ‘fnbr’ to identify the file being operated on." The same line is in the earlier manuals. WRITE! Sounds like you were planning something, for random access maybe, that never got included. While I've got your attention, how big is the file buffer? I presume that it flushes automatically when it gets full. Is that correct? Have you ever considered a FLUSH or maybe COMMIT command which would write the buffer to the file without closing the file? How much memory would that use and how much of a hassle would it be for you? With just the OPEN and CLOSE commands if you want to be absolutely sure that debug stuff gets written to the disk before a potential crash you have to OPEN and CLOSE the debug file immediately before and after each critical PRINT. A FLUSH would make this simpler. Paul in NY |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
A short sub to pront the debug info is easy to do and versatile. Not sure if the syntax is correct. You could add the date and time if required and is handy when things go bump in the night. Jim VK7JH MMedit |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
Jean, shouldn't that be CONTINUE and ABORT not IGNORE and CLEAR? OPTION ERROR CONTINUE ' do something here with files if MM.ERRNO = 1 then DoSomethingToFixIt OPTION ERROR ABORT Paul in NY |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
@TassyJim -- You think like a polack! That's about what I'm doing. That's what inspired my question about FLUSH or COMMIT. Paul in NY |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3292 |
Attached is an updated version: 2017-07-18_095008_DOS_MMBasic_Ver_5.04.05_Beta_5.zip In this version it is possible to edit the program from within MMBasic. The EDIT command will edit the last file supplied on the command line or used in RUN, LOAD or SAVE. When the editor is closed MMBasic will automatically reload the program from the file. If no file has been used MMBasic will create a temporary file and delete it after. By default the editor used is Notepad but another editor can be specified by setting the DOS environment variable MMEDITOR to the path of the alternative editor. Also added to this version is the SAVE command and the FILES command will now take a search specifier (ie, FILES "*.bas"). Geoff Geoff Graham - http://geoffg.net |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3292 |
I have no idea how big it is or how it is flushed. All that is handled by Windows and it is sure to be much more sophisticated than just a simple buffer. I'm a bit disturbed by all this talk of "crashing". MMBasic should not crash - not ever. This is something that I am very big on and even the smell of an unhandled exception will have me investigating. Has the DOS MMBasic (or any other version) crashed on you? Can you post some code that causes it? I would very much prefer to eradicate any bugs that cause an exception than implement a bandage solution like FLUSH. Geoff Geoff Graham - http://geoffg.net |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
NO! NO! NO! YOUR MMBasic HAS NEVER CRASHED! It's my dopey programs that crash! I'm trying to handle too much real world physical data which gets collected very slowly. I use a bunch of bottom level functions to print stuff to files. I send some data and a buffer number to the function and it prints stuff to one of a bunch of files. Many times MMBasic finds a screwup in my code and stops, printing its error message on screen, usually from one of the low level file print functions, so the line number is useless because that function is called from hundreds of places. I'm trying to track my code progress with debug files. That's why I asked about a FLUSH command instead of an OPEN:PRINT:CLOSE routine. Is there any way to get <TRACE> or <TRACE LIST nn> to send its output to a file for subsequent review after a crash in either the DOS or PIC version? Paul in NY |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
