FB II Compiler

PG PRO

Debugging

Memory

System

Mathematics

Resources

Disk I/O

Windows

Controls

Menus

Mouse

Keyboard

Text

Fonts

Drawing

Sound

Clipboard

Printing

Communication

ASM

Made with FB

TEXT

Know more about TEHANDLE


I don't know if this is the complete answer to your problem, but there is definitely one flaw in the code above which is bound to be messing _something_ up. You seem to be assuming that the first two bytes in the TextH& block consist of a short integer which gives the total length of the text (as in your line: TextLen& = {[TextH&]}.)

But that's not the case. FN TEGETTEXT returns a handle to a block that contains _only_ the text. There is no "length word" at the beginning of the block: the first 2 bytes in the block are in fact the first 2 text characters.

(You may be confusing this with GET FIELD, which returns a handle to a "ZTXT" block, which does indeed have a "length word" in its first two bytes.)

The upshot is that what you're putting into TextLen& is not the length of the text, and thus you're using the wrong values for TextLen& and IndxSize&.

There are a couple of things you can do to fix this, depending on how you intend TextH& to be interpreted.

If you want TextH& to refer to a block which _does_ have a leading text word, then change this:

TextH& = FN TEGETTEXT(teH&)

...to this:

GET FIELD TextH&, _PanelTextFld

(and then the line "TextLen& = {[TextH&]}" will work correctly). But if you intend TextH& to be a handle to the raw text (_without_ a leading length word), then replace this line:

TextLen& = {[TextH&]}

...with this:

TextLen& = FN GETHANDLESIZE(TextH&)

You'll have to think about which of these replacements you need to do. I'd say it all hinges on how your FN text2Arry is interpreting TextH& (i.e., does FN text2Arry expect TextH& to have a leading length word or not?)

Rick