forums.silverfrost.com

wahorger · Joined: 13 Oct 2014 Posts: 1225 Location: Morrison, CO, USA

The following sample exhibits the anomaly, specifically, the text displayed as BOLD is not fully displayed in the window. Each line should display the word "inclusive". Those that are bold do not. I used the string that was showing this problem. Shorter strings do not appear to have this particular issue, but I did not try all of the shorter ones to discover what would work.

LitusSaxonicum · Posted: Thu Mar 24, 2022 8:36 pm Post subject:

Bill,

I can make the final 'inclusive' appear in those lines if instead of plain old %ws I use %-100ws. (The minus makes it left justified).

I suspect that there is an inbuilt limit of some kind to how big %ws can be by default.

Eddie

wahorger · Joined: 13 Oct 2014 Posts: 1225 Location: Morrison, CO, USA

Yes, if I forced it, it will show. Thing is: I shouldn't have to force it.

It's not just one place where this can happen, and specifying a wide field makes all the other (smaller) instances look odd.

This occurred originally in a subroutine that is called from literally dozens of places. Sometimes with only a few dozen characters. Other times, long strings like this.

I separated out those portions of the routine and data that made this show itself to build an example that would demonstrate the problem.

Bill

PaulLaidler · Posted: Fri Mar 25, 2022 8:53 am Post subject:

Bill

I am puzzled by this report of your experience. I don't get the reported behaviour and I have tested for both 32 bits and 64 bits.

There is nothing in the ClearWin+ code to give a clue. The internal buffer size is 1000 characters. There was a change to the code in December 2018 but the change should have no impact in this context.

mecej4 · Joined: 31 Oct 2006 Posts: 1896

I took Bill's program and, as a casual/infrequent user of ClearWin, modified it to see if I could reproduce the truncation of strings on the right. On a 1920 X 1024 display, using FTN95 8.83 /64, I found that the following program shows that behaviour.

PaulLaidler · Posted: Fri Mar 25, 2022 1:02 pm Post subject:

I get the same behaviour as mecej4 so I can investigate further.

PaulLaidler · Posted: Mon Jul 11, 2022 3:51 pm Post subject:

There is no easy fix for this within ClearWin+.

The problem is that ClearWin+ calls GetTextExtentPoint32 to get the width of the bold string but the result does not reflect the extra width required for bold or italic font. Also in this sample, the width of the window is determined by the width of the bold string. So the end of the bold string is hidden because it is outside of the window.

This effect will only happen in rare circumstances and, when it does, a possible work-around is to add white space to the end of the string. For example,

LitusSaxonicum · Posted: Tue Jul 12, 2022 10:12 am Post subject:

Paul,

Isn't the easy fix to say what %age extra space is needed for bold and/or italic, and make a note in the helpfile that due allowance, using those %ages, needs to be made? It might even be useful for the helpfile to point out that the fault is Micro$oft's!

Eddie

PaulLaidler · Posted: Tue Jul 12, 2022 1:23 pm Post subject:

Eddie

The problem is not restricted to %ws. It could potentially apply to any text (without a %) in a window.

In a sense it is a Microsoft issue in that, as far as I am aware, there is no function that provides the dimensions of a bold character string.

The only fix that I have seen involves drawing the string and then scanning the pixels to find the end. If anyone knows a simple approach then please let me know.