Huge problem with StyledText.RTFData on Windows

44852 - Huge problem with StyledText.RTFData on Windows

OS: Windows 10

Xojo: Xojo 2016r2

Steps: I just bumped into a major bug with Styled TextArea and StyledTextRTFData.

My app saves the content of the TextArea.StyledText.RTFData at the end of the session and and loads it back when it starts again. No issue whatsoever on Mac, but on pc, each tie the text is loaded again point size is much lower, until it gets impossible to read.

I modified the styledtext example to show it. Load the attached project, and click “Save & reload”.

The button save and reload simply placed StyledTextRTFData in a string (buffer), and set the TextArea StyledText.RTFData to the same content.

Each time the button is pressed, size diminishes.

Expected Result:
Text saved loads identical

Actual Result:
point size dimishes when loaded again

none simple

I have seen my content of sloppy implementations on the Windows side of Xojo and usually find a workaround, but this is surely the cherry on the cake !

This is probably (not sure) related to the issue I found which caused me to put my PDF class on hold.
The font metrics between OSX and Windows are different, not to mention they are inconsistent in converting from Pixels to Points to Inches to Millimeters.

It MIGHT be that Xojo is sharing some of those internal functions and what you are seeing is a cumulative rounding error

This is much worse, actually. Not the usual differences.

I created a sample RTF document in WordPad that has a succession of sizes from 10 to 24.

I attached it to the case.

The problem is not simply that size is smaller, it is also quite inconsistent. Line 1 is some like 4, and it goes up to 11 or so, before reverting to 4, and so on. There is absolutely no logic.

It would take creating a new RTF interpreter to work around this one.

Half year ago I spend the time to build a nice rich-text-control based on the TextArea using StyledRTFdata. I managed to have it working quite well for windows, with some help of an MBS plugin. Unfortunately, it did not work the same for Mac and the RTF-string was significantly different.
Since my application is for Mac and Windows and both versions connect to the same live database, this was a blocking issue of course.
Next I also had problems copying and pasting to and from other RTF wordprocessors like the Microsoft Wordpad due to RTF-implementation -bugs of the textarea-control.
Long story short: I’ve quit with this control as a rich-text-editor in my project and switched to HTML-edit of @Tim Parnell .
Anyway, HTML is preferable above RTF, I think.

Well, sometimes, you simply can’t go HTML.

and a bug is a bug :frowning:

OK. Now, on PC, I save in my own format, using styleruns. Took a couple hours elaborating that, but the bug should be gone tomorrow.

I really did not feel like redoing in HTML the entire custom controls based on TextArea.

What about Bob’s Formatted Text Control?

I have a license, but it is far from a simple replacement. I developed a complex custom control around TextArea, and it would take a lot of work.

Did you try StyledText.RTFDataMBS?
That is using my own plugin code.

While TextArea.RTFDataMBS uses the OS functions.

[quote=281013:@Christian Schmitz]Did you try StyledText.RTFDataMBS?
That is using my own plugin code.

While TextArea.RTFDataMBS uses the OS functions.[/quote]

I did, but still it was not possible to show the RTF made with the Windows-application exactly the same in the Mac version of the same application and visa versa. This was a requirement since the Windows- as well as the Mac-version are going to be mixed in one company and both connect to the same database.

Probably the RTF implementations by OS are different and the textarea-control doesn’t interpret and behave exactly the same for Windows and Mac.

I just tried the demo, which I found to be a bit quick and dirty and copying the code into another word-processor did not give me the reassuring feeling.

Impressive. Please let us know

Well, I started from the StyledText example. My format is super simple. Styleruns are separated by a separator character, then in each stylerun, I record bold/Italic/Underline/Fontsize/Font/Color/and the text, with a separator character in between. I then encodeBase64 the entire series of styleruns to preserve endofLine, and record that. Then upon next run, I do the reverse operation.

RTFData and RTFDataMBS are completely unusable under 2016R2. Christian told me his plugin was simply asking the system, but frankly I have a lot of doubts, since in 2015R4.1 either RTFData or RTFDataMBS work flawlessly on the same machine, under the same version of Windows 10. To me, it looks more like some major issue with Xojo.

RTFDataMBS used to work fine with Windows 7, and 2015R4.1

Never thought this way, but yes, think it’s going for restricted purposes. Success with the implementation and perhaps it leads to a control which is salable.

Well, it is only a workaround, until RTFData is fixed. But right now, it works as expected.