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.