ReadData and WriteData data mismatch [SOLVED]

[LiK137]

I have encountered a very strange behaviour.
I put some bytes to file. Then I open this file in HexEditor and discover that data in the file differs from data I have put.
And when I insert these data to string (at bottomost of the code) I get different length of data.

Code: Select all

sors$=Chr(48)+Chr(48)+Chr(31)+Chr(48)+Chr(48)+Chr(48)+Chr(48)+Chr(31)+Chr(78)+Chr(65)+Chr(77)+Chr(198)+Chr(143)+Chr(76)+Chr(85)+Chr(77)+Chr(31)+Chr(78)+Chr(65)+Chr(77)+Chr(198)+Chr(143)+Chr(76)+Chr(85)+Chr(77)+Chr(31)+Chr(78)+Chr(65)+Chr(77)+Chr(198)+Chr(143)+Chr(76)+Chr(85)+Chr(77)+Chr(31)+Chr(78)+Chr(65)+Chr(77)+Chr(198)+Chr(143)+Chr(76)+Chr(85)+Chr(77)+Chr(31)+Chr(48)+Chr(48)+Chr(31)+Chr(48)+Chr(48)+Chr(48)+Chr(48)+Chr(48)
sorslen=StringByteLength(sors$,#PB_UTF8)
Debug sorslen
raytSessn=CreateFile(#PB_Any,"c:\temp\samfayl.dat",#PB_File_NoBuffering)
If raytSessn
  *wMem=AllocateMemory(sorslen*1.1)
  If *wMem
    pokBaytz=PokeS(*wMem,sors$,sorslen,#PB_UTF8)
    ritnBaytz=WriteData(raytSessn,*wMem,pokBaytz)
    FreeMemory(*wMem)
  EndIf  
  CloseFile(raytSessn)
EndIf
faylen=FileSize("c:\temp\samfayl.dat")
ridSessn=ReadFile(#PB_Any,"c:\temp\samfayl.dat",#PB_File_NoBuffering)
If ridSessn
  *rMem=AllocateMemory(faylen*1.1)
  If *rMem
    ridBaytz=ReadData(ridSessn,*rMem,faylen)
    If ridBaytz
      dest$=PeekS(*rMem,ridBaytz,#PB_UTF8)
      destlen=StringByteLength(dest$,#PB_UTF8)
      Debug destlen
    EndIf  
    FreeMemory(*rMem)
  EndIf
  CloseFile(ridSessn)
EndIf  

txtVal$=[CopieDataFrom'c:\temp\samfayl.dat']
txtVaLen=StringByteLength(txtVal$,#PB_UTF8)
Debug txtVaLen

[Thunder93]

Code: Select all

; txtVal$=[CopieDataFrom'c:\temp\samfayl.dat']
; txtVaLen=StringByteLength(txtVal$,#PB_UTF8)
; Debug txtVaLen

Debug "sors$: "+sors$
Debug "  size: "+FileSize("D:\temp\samfayl.dat")
Debug "dest$: "+dest$
Debug "  size: "+destlen

State.s = "No"
If sors$ = dest$ : State = "Yes" : EndIf 
Debug "   sors$ matches exactly to dest$: "+State

nSize.l = sorslen
If destlen <> nSize : State = "Yes" : EndIf
Debug " ... does filesize match exactly bytes written: "+State

sors$: 000000NAMƏLUMNAMƏLUMNAMƏLUMNAMƏLUM0000000
size: 60
dest$: 000000NAMƏLUMNAMƏLUMNAMƏLUMNAMƏLUM0000000
size: 60
sors$ matches exactly to dest$: Yes
... does filesize match exactly bytes written: Yes

... no problem here.

[Demivec]

Code: Select all

txtVal$=[CopieDataFrom'c:\temp\samfayl.dat']

This code is not executible. Perhaps that is the source of your problem.

[LiK137]

ThanQ very much 4 replyz.
May be I didn't describe the problem briefly, sorry for that.
Let me describe detailed.
There are special unicode characters which represented by 2 characters (chr:198 & 143 or HEX:C6 & 8F)
so if You open this D:\temp\samfayl.dat You will discover that content is different than expected.

If not using special unicode chars then code works just perfect.

And I discovered that copying unicode string from clipboard to two different opened tabs in PurebasicIDE v5.30 acts differen.
in 1 tab unicode string is copied fine and debugging that string just correct.
but in another sourcecode tab instead of each unicode chars shows "?".

I solved my problem by just creating new pb document/tab, copying sourcecode to new tab, correct unicode string in the new tab, delete chr() representation of unicode string and overwriting to existing source. That was inordinary and strange bug may be.
May be should report to Fred.

(Addicted to PB)

[Demivec]

And I discovered that copying unicode string from clipboard to two different opened tabs in PurebasicIDE v5.30 acts differen.
in 1 tab unicode string is copied fine and debugging that string just correct.
but in another sourcecode tab instead of each unicode chars shows "?".

You may be experiencing using two tabs that are using different encodings. You can set the default encoding for new Source files under the preference option Compiler -- Defaults.

You can also verify the current encoding of a file under the menu File -- File Format.

There are special unicode characters which represented by 2 characters (chr:198 & 143 or HEX:C6 & 8F)
so if You open this D:\temp\samfayl.dat You will discover that content is different than expected.

This is a normal part of using different text encodings; in this case, it is between the unicode UTF-8 encoding and either ASCII or UTF-16. As part of the write process you are re-encoding the same text in a different way. When you compare the file's content (in UTF-8) and the source's contents in ASCII (assuming), only the characters values below 128 are going to be the same between the two encodings.

Please excuse these explanations if you are already aware of these things.