Re: reading status channel in ML
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
	lda prefs_filename_length
	ldx #<prefs_filename
	ldy #>prefs_filename
	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  
	jsr open_status_channel
	jsr read_status_channel
;	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.