file stream problem!

Login to reply to this topic.
Thu, 2008-02-07 11:20
Joined: 2007-11-12
Forum posts: 17

im trying to parse text tagged in xml format received from a bluetooth rfcomm channel...i was trying to store this text into a file before parsing it, i got my parser to work fine when i used a xml file that i had already created but when i try to write the received strings into the file there are some random characters written in the beginning of the file...i can't figure out why those gibbrish characters r being written in the file...my code is like this,

        RFileWriteStream writer;
        writer.PushL();
        User::LeaveIfError(writer.Replace(CCoeEnv::Static()->FsSession(),
                        KTempFilePath, EFileWrite));

        writer << KTempString();
        writer.CommitL();
        writer.Pop();
        writer.Close(); 


Thu, 2008-02-07 12:08
Joined: 2007-12-19
Forum posts: 49
Re: file stream problem!

Maybe I'm wrong but as I remember if you write data from descriptor to stream first it saves descriptor length and next it writes descriptor data.

Thu, 2008-02-07 12:13
Joined: 2005-11-20
Forum posts: 1242
Re: file stream problem!

Yes, using RFileWriteStream and using the "<<" operator definitely does not do what you want and need.

To find out what you really need, you must get clear about encodings. You must know how the data that you receive over Bluetooth is encoded, and you must encode your text file in the right way.

The text file is easy: XML almost always works with Unicode in UTF-8 encoding, so you have to write that.

About Bluetooth, I don't know, it might be that you receive UTF-8 as well, but it might also be that KTempString() in your code fragment delivers what is the usual Symbian way of handling Unicode data internally, i.e. UTF-16. If the latter is true, you need to apply CnvUtfConverter::ConvertFromUnicodeToUtf8 before writing to file.

For writing the resulting (8-bit) descriptor data into a file, you can use RFileWriteStream alright, but you use this method:

void WriteL(const TDesC8& aDes,TInt aLength);

and you will have to write your line ends (if you want them) yourself.

Not handling Unicode encodings correctly is perhaps *the* Number 1 way to completely ruin your data Smiling


René Brunner

Fri, 2008-02-08 07:58
Joined: 2007-11-12
Forum posts: 17
Re: file stream problem!

well i tried writing simple descriptors itself instead of the BT data...but i find that the problem still persists even when i write something as simple as _LIT( KTempString, "Hello");...there's something that i must be missing here surely.

Fri, 2008-02-08 08:23
Joined: 2005-11-20
Forum posts: 1242
Re: file stream problem!

"How* did you write those simple descriptors? As I said, using "<<" is the wrong way in your situation.


René Brunner

Fri, 2008-02-08 09:14
Joined: 2007-11-12
Forum posts: 17
Re: file stream problem!

well i just followed the instructions for streams at this forum http://www.newlc.com/topic-8648...it looked simple enough...isn't there a function WriteL() i could use?

Fri, 2008-02-08 09:28
Joined: 2005-11-20
Forum posts: 1242
Re: file stream problem!

isn't there a function WriteL() i could use?

Funny you ask that, I gave you already one in my post. Just look.

And I looked ahead that, once you have solved the problem of finding the right method to write your data instead of the "<<" operator, you will most certainly run into encoding problems, if you are not aware of them.

Maybe that was a little too fast...


René Brunner

Fri, 2008-02-08 11:38
Joined: 2007-11-12
Forum posts: 17
Re: file stream problem!

well i finally got it to work...using RFile gave no problem...so i converted the 16 bit desc. to 8 bit as you said and wrote the file...but i still wonder what the problem with streams was...

Fri, 2008-02-08 12:16
Joined: 2007-12-19
Forum posts: 49
Re: file stream problem!

When you write descriptor which contains e.g "Hello" to stream via operator << or WriteL it writes to file:

Offset in file:    Type:        Description:
0000                 TInt32        Descriptor length
0004                 TChar      Descriptor data, in this case "Hello"

It, is so called descriptor serialization. Thanks to that you can use operator >> to read this descriptor without passing how long is the descriptor which you want to read.

  • Login to reply to this topic.