Author |
Topic: debug-yes;regular-no (Read 181 times) |
|
Alincon
Full Member
member is offline
Posts: 147
|
 |
debug-yes;regular-no
« Thread started on: Dec 3rd, 2017, 5:26pm » |
|
Is it possible in LBB to have a program run differently in debug mode than in regular mode - like failing to add a record to a random file?
I have posted a message similar to this one, and some of the code on the 'other' forum.
r.m.
|
|
 Logged
|
|
|
|
Alincon
Full Member
member is offline
Posts: 147
|
|
Re: debug-yes;regular-no
« Reply #1 on: Dec 3rd, 2017, 9:36pm » |
|
I should have noted that my program works as intended in LBB, regardless of mode. (yea!)
r.m.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: debug-yes;regular-no
« Reply #2 on: Dec 3rd, 2017, 10:31pm » |
|
on Dec 3rd, 2017, 5:26pm, Alincon wrote:| Is it possible in LBB to have a program run differently in debug mode than in regular mode - like failing to add a record to a random file? |
|
The only (intentional!) differences between LBB's 'normal' and 'debug' modes are as follows:
'Temporary' breakpoints (inserted by double-clicking in the left margin) cause the program to pause at that statement in 'debug' mode, but not in 'normal' mode.
A 'permanent' breakpoint (i.e. a TRACE 2 statement) causes the program to pause when in 'debug' mode but has no effect - other than a slight impact on execution time - when in 'normal' mode.
The NOMAINWIN statement is ignored in 'debug' mode, causing the mainwin always to be displayed. Does that answer your question?
Richard.
|
|
Logged
|
|
|
|
Alincon
Full Member
member is offline
Posts: 147
|
|
Re: debug-yes;regular-no
« Reply #3 on: Dec 5th, 2017, 7:19pm » |
|
(As frequently happens) the problem was really mine: I did not close the random file before closing the program. In my defense, I got no error message in LB. In LBB there was no message either, but it worked.
Evidently, LBB handles unclosed files differently.
r.m.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: debug-yes;regular-no
« Reply #4 on: Dec 5th, 2017, 7:50pm » |
|
on Dec 5th, 2017, 7:19pm, Alincon wrote:| Evidently, LBB handles unclosed files differently. |
|
LBB should automatically close files on exit; I would have thought that was normal behavior. If LB 4 doesn't work that way I am surprised, but I suppose you should not have assumed it would.
Richard.
|
|
Logged
|
|
|
|
Rod
Full Member
member is offline
Gender: 
Posts: 110
|
|
Re: debug-yes;regular-no
« Reply #5 on: Dec 6th, 2017, 07:09am » |
|
The problem was a little different to that described. The program did not END, it simply closed its window. I have not tested but I sssume LBB might behave the same way as LB. it hangs quietly in the background doing what it was instructed to do.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: debug-yes;regular-no
« Reply #6 on: Dec 6th, 2017, 08:30am » |
|
on Dec 6th, 2017, 07:09am, Rod wrote:| The problem was a little different to that described. The program did not END, it simply closed its window. |
|
Ah, that is indeed very different. In that case the file will remain open indefinitely and there is no guarantee that data written with a PRINT# or PUT# will have been 'flushed' to the actual storage device (and thus be visible to, for example, another program looking at the same file).
In fact I might expect that LBB would, if anything, be more vulnerable to that possibility, because for performance reasons it stores output data in a temporary buffer which gets written only when full (or when the file is closed).
If you need to commit data to disk without closing the file there is a 'trick' you can use in LBB:
Code:
Whilst you might expect that setting the file pointer to its current position would do nothing, it has the side-effect of flushing LBB's buffers.
Richard.
|
|
Logged
|
|
|
|
|
