Font changes and automatic window sizing

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.

	winapp
        use mswin
        integer:: i
        integer,external:: my_callback
        character*260:: buff='Copy From  Project:     Quad:PINE         State:CO Map Scale: 1 1:125000 From ID=1 to 60 inclusive'
        i = winio@('%ww[topmost,no_sysmenu,no_maxminbox]&')
        i = winio@('%fn[Courier]&')
        i = winio@('%ts&',1.0d0)
        i = winio@('%ws%nl&','Copy From  Project:     Quad:PINE         State:CO Map Scale: 1 1:125000 From ID=1 to 60 inclusive')
        i = winio@('%ws%nl&',trim(buff))
        i = winio@('%bf&')
        i = winio@('%ts&',1.0d0)
        i = winio@('%ws%nl&','Copy From  Project:     Quad:PINE         State:CO Map Scale: 1 1:125000 From ID=1 to 60 inclusive')
        i = winio@('%ws%nl&',trim(buff))
        i = winio@('%fn[Tahoma]&')

        i = winio@('%ws%nl&','Copy From  Project:     Quad:PINE         State:CO Map Scale: 1 1:125000 From ID=1 to 60 inclusive')
        i = winio@('%ws%nl&',trim(buff))
        i = winio@('%sf&')
        i = winio@('%bt[Call me]&')
        i = winio@('')
        stop
        end

https://capture.dropbox.com/9gjEB6wuI9thgwud

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

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

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.

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.

   winapp
        use mswin
        integer:: i
        integer,external:: my_callback
        character*60:: buff=' Is Paradise Lost   1 Is Paradise Lost   2  Is Paradise Lost'
        i = winio@('%ww[topmost,no_sysmenu,no_maxminbox]&')

        i = winio@('%fn[Courier]&')
        i = winio@('%ts&',1.2d0)
        i = winio@('%ws%nl&',buff)
        i = winio@('%ws%nl&',trim(buff))

        i = winio@('%bf&')
        i = winio@('%ts&',1.0d0)
        i = winio@('%ws%nl&',buff)
        i = winio@('%ws%nl&',trim(buff))

        i = winio@('%fn[Tahoma]&')
        i = winio@('%ws%nl&',buff)
        i = winio@('%ws%nl&',trim(buff))
        i = winio@('%sf&')
        i = winio@('%bt[Call me]&')
        i = winio@('')
        stop
        end

A screenshot showing the output of the program:

 ![https://pasteimg.com/images/2022/03/25/wahclrw.png](https://pasteimg.com/images/2022/03/25/wahclrw.png)

Note another item that has not been mentioned so far: the first four lines display extra spaces at the left.

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

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,

  winapp
  character*66:: buff=' Is Paradise Lost   1 Is Paradise Lost   2  Is Paradise Lost  '//char(9)
  i = winio@('%fn[Courier]&')
  i = winio@('%bf&')
  i = winio@('%ws%nl',buff)
  end

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

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.