MAJOR BUG in WINDOWS TextArea 2016R2 : SelTextSize and TextSize not applied correctly

Targets Windows
1

44878 - MAJOR BUG in WINDOWS TextArea 2016R2 : SelTextSize and TextSize not applied correctly

Steps: This used to work in 2016R1.1

If you set SelTextSize or TextSize, instead of the point size, the result is a lower point size.

Run the attached project : it is supposed to display 8 to 24 point size text.

When you click on the text, it displays the found seltextsize at the clicked location.

In practice, 8,10,12,14,16,18,20,24 results in 6, 7.5 , 9, 10.5, 12, 13.5, 15, 16.5, 18.

The control has become unusable.

<https://xojo.com/issue/44878>

In practice, I cannot continue work on the Windows version of my app, and will have to completely refactor for a lower version. It does not manifest in 2016R1.1.

This one is so big, it is curious it went undiscovered through Alpha and Beta testing.

2

The issue is present as well in 2016R2.1 just released !

Between that and RTFData broken, that is beyond imagination…

I have simply uninstalled 2016R2 and 2016R2.1.

4

No, I can imagine it. Xojo is a big project with a ton of targets. It’s hard to test everything every single release.

Xojo wants us to test everything. Xojo has said not to use a beta version in a production environment. Those two statements are incompatible for many of us since we are in a production environment.

I see that you are part of the beta program too. So why didn’t you see this?

I’m not trying to make fun of you as it looks like you found a serious bug. But, Xojo has limited internal testers and leans heavily on the beta tester program to find regressions. So I find it ironic that a beta tester complains that a bug wasn’t found in beta testing.

5

It is ironic, of course. But it is totally unfair towards Michel IMHO. Your post could be understood as if it is his mistake…

6

[quote=281372:@Bob Keeney]
But, Xojo has limited internal testers and leans heavily on the beta tester program to find regressions. So I find it ironic that a beta tester complains that a bug wasn’t found in beta testing.[/quote]

Hardly. Just as you don’t expect Xojo to test everything, you can hardly expect poor Michel to. Else, why did YOU not find it, being a tester of various flavours?

7

Totally unfair? Not really.

One can be a beta tester and feel remorse that you (or the collective) didn’t find this particular bug. Or, one can complain that it is ‘beyond imagination’ that this bug was not found and fixed already.

The first acknowledges that I (or we, if you will) failed. The second says that ‘they’ failed and I take no blame in it.

In my opinion, all of us in the beta system share the blame with Xojo. Xojo is not blameless because they should have given us a notice that something changed so we could have tested it (note: they may have since I was not very active in this beta cycle due to work schedule).

8

Or release once a year so we can test everything extensively ?
I doubt anyone would want that

9

One could argue that it might be nice to have unit test for the RTFData on each platform. But I’m not sure how that would work or if it would expose this particular bug.

10

[quote=281397:@Norman Palardy]Or release once a year so we can test everything extensively ?
I doubt anyone would want that[/quote]
I do. One feature release and then bug fix releases.

I really, really hate the rapid release model. One version is unusable because of a serious database bug, another because of a RTFdata bug, etc etc

It’s getting to the point where you have to choose your release depending on what features you want to use.

11

And to make my case: 2016 R2.1 is out. And R2.2 won’t be far behind.

Emergency releases have become the norm, not the exception.

I’d like to be able to rely on my tools.

12

I have found this to almost always be the case. We don’t upgrade to every version for this very reason.

We try to stick to within about a year of current release but not always. We are still actively developing on Real Studio for one client but most are between 2015 R4.1 and now.

13

[quote=281401:@Markus Winter]
It’s getting to the point where you have to choose your release depending on what features you want to use.[/quote]

It has been that way forever with this product.

14

Coincedence? :wink:

15

Yes, heavily on Pro users; not simply heavily.

Question:
How many times a quarter a Pro user created a new project ?

16

Totally.

17

Yes. My reminder to post that message appeared this morning.

18

Thats twice
I literally mean ONCE per year

19

Have you tried to use fontUnit->pixel and multiply the size result with the scale factor?

20

Michel, pls try to set the font unit of the textarea in the ide to pixels instead of points and i think the result of your program will be more satisfying.

21

Bob ; what’s gone into you ? Aren’t we kind of unfair ? I do test a lot, and am a dedicated bug reporter. It just happens so I started this project as 2016R2.1 was in FC.

Antonio : the delta between set point size and actual is not constant. I could have built an entire contraption with an equivalence table, but whenever the bug gets fixed, not only this will be futile, but it will create a new bug.

Andre : the whole point of the exercise was precisely that in order to work around the RTFData bug, I had devised a save and load routine of my own based on StyleRuns. This new bug defeated entirely my strategy.

When I started that thread, I had wasted almost a week working around the RTFData mess, just to step into the TextArea Font size horror. I have seen people a lot more frustrated for way less.

I just spent a couple hours patiently replacing the image sets by regular images in order to revert to 2015R.4.1, so I can resume productive work, and in the process, avert the dreadful DLL issues. I will probably be a lot more prudent for my next Windows project.