Using rich edit, I found I was accumulating some cruft at the 2048 byte boundary when using @RTSAVE in text-save mode:
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. ::)
No idea at the moment as it has always worked for me. I'll check MSDN for clues and get back to you.
Paul.
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.
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:
ptext[retsave] = 0
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.
Paul, I got a clean file, the exact contents of the control, with this:
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. ???
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.
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.
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. ::)