Glitch at 2k in @RTSAVE

[Jerry Muelver]

Using rich edit, I found I was accumulating some cruft at the 2048 byte boundary when using @RTSAVE in text-save mode:

Code Select Expand


DEF ptext[8192]:istring
def pname:string
dirty = CONTROLCMD(win,1,@RTGETMODIFIED)
IF dirty <> 0
'RtlZeroMemory(ptext,8192)
'ptext = ""
retsave = CONTROLCMD (win,1,@RTSAVE,ptext,0)
               MESSAGEBOX win,str$(retsave),"retsave"
               MESSAGEBOX win,str$(len(ptext)),"len ptext"
ptext = left$(ptext,retsave)

I get the same results with RtlZeroMemory and ptext="" active.
retsave = 2067
len ptext = 4102
printing ptext at that point shows the text is loaded into ptext twice, with a couple of non-printing garbage characters at 2048, followed by the rest of the text, followed by the text again with the first 25 characters missing (as if the duplicate started at 2048, but was overwritten by the end of the first text copy). The len ptext is ALWAYS 4102, regardless of how many characters I add to the text ot make it "dirty". I use left$ with retsave to truncate the duplicated text, but I still have the cruft characters embedded at 2048.

If I copy all the text, and paste it twice into the control to make the file "dirty", I get 6164 for retsave, and 8102 for len ptext. The 8102 is "sticky", like the 4102, over a range of variation.

There is nothing in my code that sets anything at 2048.

Any hints for what to do next would be much appreciated. This is a deal-breaker at the end of two months of work. 

[Ionic Wind Support Team]

No idea at the moment as it has always worked for me.   I'll check MSDN for clues and get back to you.

Paul.

[Ionic Wind Support Team]

Just for the heck of it try saving it to a file first and loading into the string.  If it works then I may have an idea what is happening when saving to a string directly.

Paul.

[sapero]

I've noticed that left$ requires the string to be NULL terminated. This command first calls len() so it must be a C-string.
You don't need to zero' the whole string, just cut it after @RTSAVE:

Code Select Expand

ptext[retsave] = 0

[Ionic Wind Support Team]

And that's fine for text of a certain length.  The RE control sends data in a stream of chunks to a callback routine and I may have a bug in that internal routine that isn't concatenating the chunks properly.   Which is why I asked him to try writing it to a file with @RTSAVE to see if came out properly.

Paul.

[Jerry Muelver]

Paul, I got a clean file, the exact contents of the control, with this:

Code Select Expand


IF dirty <> 0
retlen = CONTROLCMD (win,1,@RTGETTEXTLENGTH)
RtlZeroMemory(ptext,8192)
ptext = ""
        filename = GETSTARTPATH + "rich.txt"
if(openfile(file1,filename,"W") = 0)
    retsave = CONTROLCMD (win,1,@RTSAVE,file1,0)
closefile file1
        endif
retsave = CONTROLCMD (win,1,@RTSAVE,ptext,0)
ptext = left$(ptext,retlen)
pageText[0,curpagenr] = ptext
dirtyfile = 1
ENDIF

The save into ptext, however, was still crufted at 2048. 

[Jerry Muelver]

So far, I don't see the same kind of crufting in a parallel app that uses @RTSAVE for saving from the control to a string array element as RTF.

[Ionic Wind Support Team]

Jerry,
As I had mentioned there is a possible bug with the way I am saving the text chunks to a string.  You'll need a bit more patience

Paul.

[Jerry Muelver]

I got patience! I've got other stuff to keep me busy anyway, for instance the all-RTF tool I'm working on, which led me to notice that the problem was likely only in the RTSAVE as text. Just trying to provide some clues, is all.

In the meantime, I'm off to experiment with some DICTADD stuff, like converting pointers to strings and unconverting to retrieve objects. First, I gotta learn about pointers. Then maybe something about objects. I'll be busy enough for a couple of years, here.