Getting Error Nr 21 using SETFLAGS KAlwaysWriteASCIIFiles&am

Hi!

Here�s the complete Source-Code. Could please somebody "copy and paste"
it to it�s 9210 and have a look, if it raises the error 21 on your 9210 too.

REM OUTPROB
DECLARE EXTERNAL
INCLUDE "CONST.OPH"
INCLUDE "CONVERT.OXH"
PROC Main:
LOCAL a%,b%,v%,h%,String$(200),ret%,file$(130)
LOCAL start%,byte1%,byte2%,ende%
REM 130 is max. filename-length in EPOC ER5 (and ER6 ?)
LOCAL outfile1$(130),h1%,h2%,lenfile%,OutString$(30)
LOCAL Buffer%(8000)
SETFLAGS KAlwaysWriteASCIITextFiles&
IOOPEN(h1%,"D:\FILENAME.TXT",$0122)
IOCLOSE(h1%)
IOOPEN(h1%,"D:\FILENAME.TXT",$0123)
OutString$="Text Line 1 ���"+CHR$(KCarriageReturn&amp😉+CHR$(KLineFeed&amp😉+"Text Line 2"
REM ��� are german extended characters CHR$ 196dez, CHR$ 216dez, CHR$ 220dez
IOWRITE(h1%,ADDR(OutString$)+1+KOplAlignment%,LEN(OutString$)*2)
IOCLOSE(h1%)
CLEARFLAGS KAlwaysWriteASCIITextFiles&
ENDP

btw. I use the latest OPLDevPack (01-01-2003, 0.40(128)) on a 9210
(incl. OPL Runtime 0.40(129)).

Regards,

Luzie

same problem. But when I changed $0123 in the second ioopen to $0022, it did not crash. But this does not still write the correct characters into file. Your german characters are all written as 0x1A. I had the same problem when code page was not set to correct one with unicode files. But even adding codepage selection to your program did not help:

rem select proper codepage for unicode conversion
CP&=CVCharSetUid&😞6) rem iso8859-1
CVSelectCharSet😞CP&amp😉

I propose that you open your file in binary mode, then convert from string to ascii and write that into file, with scheme like this (maybe typos etc):

local buf1&(256),text$(255),buf1len&

rem select proper codepage for unicode conversion
CP&=CVCharSetUid&😞6) rem iso8859-1
CVSelectCharSet😞CP&amp😉

IF IOOPEN(hw%,"FILE.TXT",$0102) rem binary, write,truncate
print "Error opening file"
get
stop
ENDIF

text$="��"
buf1len& = len(text$)
CVFromUnicode😞buf1&,buf1len&,text$)
IOWRITE(hw%,ADDR(buf1&amp😉,buf1len&amp😉

IOCLOSE(hw%)

Here's a program for you to dump the files as hex.

rem file read & dump hex
DECLARE EXTERNAL

INCLUDE "CONST.OPH"
INCLUDE "CONVERT.OXH"
include "system.oxh"

PROC Main:
local F$(255),CP&
global ldata%(80)
LOCAL h%,String$(KMaxStringLen%),ret%,dia%
local n%,addr%,r$(2)

rem select proper codepage for unicode conversion
CP&=CVCharSetUid&😞6) rem iso8859-1
CVSelectCharSet😞CP&amp😉

rem FONT KFontArialBold13&,KgStyleNormal%
f$ = "d:\FILENAME.TXT"
do
f$=SyOpenFileDialog$😞f$,0,0,0)
if f$ = ""
return
endif
print "file:",f$

IOOPEN(h%,F$,$0400+$0200) rem open in random-access mode (ioseek)

addr% = 0

DO
n%=0
Ret% = 0
Ret%=IOREAD(h%,ADDR(ldata%(1)),16)
if Ret%>0
print right$("0000000"+hex$(addr%)+":",9), : addr% = addr% + Ret%
while n%<Ret%
print right$("0"+hex$(peekb(ADDR(ldata%(1))+n%)),2),
n% = n% + 1
endwh

n%=0
while n%<Ret%
if peekb(ADDR(ldata%(1))+n%) >= 32
print CVUnicode$😞ADDR(ldata%(1))+n%,1);
else
print ".";
endif
n% = n% + 1
endwh
print
else
print "******* EOF, press q to quit *******"
endif

r$=get$

until r$ = "q"

ioclose(h%)

until f$=""

ENDP

BTW. Some of the text has changed to those "Emoticons" above, I don't know why? The character sequence (2 characters) is : and (, which "looks" quite logical...

you have to check the box "disable smilies in this post" when posting 😉
Otherwise it will automaticly convert those 2 characters into the smilie

Dear Guest,

thank you lots for your help.

I�m yet cannot only display my foreign german characters
on the screen, but now I can write them into files in BINARY Mode too.

My next problem is that I have to write those characters one-by-one into the file using IOWRITE-Len 1

String$="�"

e.g. IOWRITE(h%,ADDR(String$)+1+KOplAlignment%,1)

if I use IOWRITE(h%,ADDR(String$)+1+KOplAlignment%,LEN(String$))

it writes out a 2 Byte-Unicode-Character ....

Is it possible to use arrays for doing big / fast transfers of BINARY-Data from Memory to file and from file to Memory ?

Regards,

Luzie

btw. I nearly completing my first OPL-utility LNK2TXT for the 9210 which
translates the notice-files from the 9210-desktop (UNICODE) to standard-ASCII-Files on the 9210-memory-card for fast usage on PC with a memory-card-writer etc.

LNK2TXT!!!!!! brilliant 😃
Any chance it will be opensource? 😉

Dear Dazler,

sure LNK2TXT will be Freeware inclusive
the OPL-Source-Code for the Forum-People here 😊
(Although it�s not programmed that brillant,
it works. AND: without this forum, it wouldn�t be possible).

Hope to get an Alpha-Version ready tomorrow.
(Early Beta-Version as .SIS-File without source-Code
can be found at www.aikon.ch where it�s (yet) WRONG
listed as LINK2TXT instead of LNK2TXT).

Luzie

*cough* http://www.SymbianOpenSource.com *cough*

So, here�s the source of v2.02 of LNK2TXT (Alpha-Status).

Not programmed "the procedure way",
but it works with handling Output-ASCII-binary-to-file 😊

Cheers,

Luzie

thx 😊
I'll download it tonight 😊

Luzie, I downloaded and installed this on the way to work this morning.

Nice work, and very useful. Email me offlist ([email protected]) as I've a few ideas on making it "User Friendly!"

In any case, congratualtiosn. First application?

SETFLAGS KAlwaysWriteASCIIFiles
don�t seem to be working on 9500 OPL too.
If I set this Flag, it will always IOWRITE Unicode-Characters ...

However, I�m working on a new Version of LNK2TXT for the 9500.

I�ll also try to build it into Ewan�s Core.

Maybe Ewan�s Core isn�t yet 100% working in a 9500 ?

I�ll post here, when my 9500 version of LNK2TXT is ready
(maybe a Name-Change will occur, as the Notice-Files on the 9500
aren�t named *.LNK anymore and has other format (ASCII ?)).

Luzie

Even though the first post is very old, I haven't seen this bug posted on the OPL page on sourceforge yet.

I'll check the behaviour on my own 9210 today and let you know what I find. If it's a runtime problem (which it probably is), I'll try to fix it before the next OPL release.

Just checked the code of your first post more thoroughly. It contains an error in the IOWRITE (but seeing the other posts, you already figured that out yourself 😊 ).

Instead of:

IOWRITE(h1%,ADDR(OutString$)+1+KOplAlignment%,LEN (OutString$)*2)

you should use:

IOWRITE(h1%,ADDR(OutString$)+1+KOplAlignment%,LEN (OutString$))

without the *2. At least this won't crash the runtime anymore (it now tries to read beyond the length of your string, causing the panic).

It still writes out all the German characters as $1A though. This is because OPL uses the format KCharacterSetIdentifierAscii to do the conversion to ASCII. Currently no other character sets are supported (CVSelectCharSet only works for conversion done with CONVERT.OPX, but doesn't influence the behaviour of IOWRITE and LPRINT). I will check if it's possible to include conversion to other character sets for writing ASCII text files in the OPL runtime so you won't need to fiddle around with buffers, one by one character conversion and binary files anymore.

How can I just write a simple text file, without any special char (ascii code <128)?
In other words, how can I get rid of those additional bytes after each character I write into my file?

I mean: how do I implement this?

open "C:\test.txt" for output as #1
print #1,"hello"
close 1

Thanks in advance.