silverdr_at_inet.com.pl
Date: 2006-04-10 19:14:01
On 2006-04-10, at 18:22, Steve Judd wrote:
>> Of course, both of your sample have one "problem": They depend
>> upon the
>> error channel sending a CR as last character. Although they do,
>> "theoretically", it would be clearer to wait until EOF is signalled.
>
> Could be, I suppose. But I think it's pretty standard, and I
> haven't seen
> it fail.
I admit I also used it the same way. Probably because I've seen it
done so in many places. This doesn't mean it has to be the "right"
way. Of course I also haven't seen it fail.
>
>> Well, I tend to disagree again. Although this works, I would
>> change the
>> order: First CLRCHN, then CLOSE. It seems the "right" order to me to
>> first "detach" from a file (sending UNTALK or UNLISTEN), and THEN
>> closing it, than the other way around. Remember: If you close the
>> file,
>> from an API's point of view, you still are outputting to that file,
>> although it is already closed.
>
> Well, what if I've already called CHKOUT to output elsewhere?
>
> But hey, if another way is more personally satisfying, and works, I
> say go
> for it.
>
> Wait, what are we talking about again? ;)
The problem was that some supposedly simplest things made me lose
almost one whole night due to strange, unexpected behaviour of the
status channel handling.
lda prefs_destination_device ; lfs - the same as output device number
tax ; device number
ldy #$02 ; secondary adress of #0 - read access
jsr SETLFS
lda prefs_filename_length
ldx #<prefs_filename
ldy #>prefs_filename
jsr SETNAM
jsr OPEN
lda prefs_destination_device ; again, I am lazy but know that the
lfn is the same
jsr CLOSE
; jsr CLALL
; lda $b7
; pha
; lda #$00
; sta $b7
lda prefs_destination_device ; now it is really the device number
needed
jsr open_status_channel
jsr read_status_channel
jsr CLRCHN
; pla
; sta $b7
lda prefs_destination_device
jsr CLOSE
; jsr CLALL
lda status_message_buffer
ldx status_message_buffer+1
cmp #"6" ; checking for error
bne error_opening_output_file ; # 62 - FILE NOT FOUND
cpx #"2" ; which is the expected
bne error_opening_output_file ; as NO error
Please note the lines commented-out. Now, if I remove both CLALLs and
leave $b7 handling, I get _empty_ status message. If I leave the
CLALLs and remove $b7 handling - I get 30, SYNTAX ERROR in the
status. I get expected results (#00 or #62) only if I leave both of
them in place, while I'd expect that _none_ of those should be
actually required.
P.S. that makes me also wonder: If I OPEN() a file on the disk and it
is not there (i.e. ERR #62) do I still need/am supposed to CLOSE() it?
--
The secret of happiness is total disregard of everybody.
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.