Eccentric behaviour of %cn

I had a feeling this had been discussed before, and it's certainly something I encounter from time to time, but I can't find anything on the forum, so maybe it fell out the back of the forum's retention time. Anyway ...

Little application I am working up, main window contains from top to bottom: 1) a bitmap 2) a table 3) a button 4) another table. I want to centre those four components. The first three centre OK, the last one is significantly right-biased.

I know that too many %cn formats can fight each other sometimes, so I have tried moving them singly and in combination, but all that achieves is either a) nothing or b) shift to left-bias.

I also tried combining the table, button and table into one big table, with the button in the middle row and blank cells on either side of it. So ClearWin+ only has two things to centre. Was sure that would work, but no, resulting ubertable is right-biased again.

So it seems something about the second table is responsible. The first row and column are headings, achieved with hard-coded text; the remaining cells each contain the output of a %'rs format code. I have even tried telling ClearWin+ explicitly how many characters wide to make the fields for the %'rs outputs, without success.

Anyone hazard a guess why %cn would not work with a table like this? And more to the point, any suggestions for how to work around it?

OK, I nailed the villain of the piece - a surprising result, to me:

        program eccentric
        integer iomain
        iomain = winio@ ('%ca[Eccentric]&')
        iomain = winio@ ('%cn%2.2ob&')
        iomain = winio@ ('Lots and lots and lots and lots of big blahiness%cb&Blah%cb&')
        iomain = winio@ ('Blah%cb%cb')
        end program eccentric

Everything to do with the relative size of the contents of the first cell compared to others in the first column. The bigger the imbalance in favour of the first cell, the worse it gets. If all cells in column 1 are the same width, all is sweetness and light. Have not investigated if the same problem occurs if other columns are imbalanced.

So I think this is something that could usefully be fixed. And the workaround is obviously to bear this idiosyncracy in mind when designing tabel nomenclature in the meantime.

Andy

Sparge,

I had a play around this issue. It looks to me that your %2.2ob is assessed as being of zero width when the Clearwin window is set up (I couldn't work out what was happening until I added %ww[maximise], and even then, I had to put it on a wide screen to be sure). If you had a set of %ob ... %cb couplets, then the widths are considered, and the whole bunch is centred. However, if you do that, you get a gap between the boxes.

I think you see that the box complex is not centred when you have a long string in the leftmost cell - but I made your %2.2ob into %3.2ob and kept the first boxes empty - but the left edge of the box complex is still centred, not the whole.

I then wrapped your box complex in its own %ob ... %cb - and lo and behold, the whole shooting match is centred! (I used [no_border] and didn't experiment any further).

So, I think the answer to your immediate problem is to wrap the box complex in its own outer box before centering*. Not obvious, is it?

Eddie

*Edit: (%cn obviously comes before the outer %ob ... %cb !)

Hi Eddie,

Nice detective work - it's always gratifying when someone else finds one of my FTN95 issues problem sufficiently itchy that they feel obliged to scratch it on my behalf 😄 .

Wrapping the whole thing in another box is a stroke of genius. And very akin to a stroke of genius that a brilliant colleague of mine suggested, when I went to him in despair because I was trying to tell Google that when I asked for a search on the the word currant, I did indeed mean ***currant ***and not current. The solution: search on 'currant' instead. And it worked! I am a big fan of the use of quotation marks to specify an exact multi-word search term (though I am aware that it seems to be considered quaint if not risible by anyone under the age of say 30 these days). However, it would never have occurred to me that Google would interpret 'x' differently from x, for space free values of x. Just as it would never have occurred to me that ClearWin+ would interpret %ob-legit %ob/%cb stuff-%cb differently from legit %ob/%cb stuff - logic would say it ought to exacerbate the problem not ameliorate it.

Andy

Glad to be of service. I was hoping to learn something, and I did.

In my view, the problem isn't so much that the behaviour is eccentric, but that there isn't anywhere in the documentation that spells it out. So, if in FTN95.CHM it said 'Single %ob/%cb combinations respond to %cn and %rj, but %n.mob/%cb etc multiple boxes do not unless they are wrapped in a further %ob/%cb combination', then we would all assume it was a design feature, and wonder how we could make use of it!

My personal list of 'why wasn't that in the documentation?' includes:

What does, and does not, work in %dw - and hence why I should have moved to %gr sooner (this would have saved some of my hair)

If you are using full_mouse_input in %gr, you can't rely on CALLBACK_REASON and the code that underlies it to sort out the various types of clicks - instead, you need to examine the coordinates and the button state codes, and throw away most of the returned info, like in the old days of the MS mouse driver under DOS.

What happens to toolbars on a computer with LARGE_FONTS set, or when the window is resized and you haven't used %bx. ... and a lengthy list of other things that have consumed a lot of time puzzling out.

Eddie

Quoted from LitusSaxonicum So, if in FTN95.CHM it said 'Single %ob/%cb combinations respond to %cn and %rj, but %n.mob/%cb etc multiple boxes do not unless they are wrapped in a further %ob/%cb combination

That's just it, though, it's not that simple. My %n.mob/%cb etc multiple boxes nearly always *do *respond as per expectation. Just every once in a while it all goes horribly wrong. So the wrapper %ob/%cb is sufficient but not necessary for good behaviour.

The concept of 'invisible wrapping' is beautiful though - I think you could be onto something there. It prompts the corresponding idea of 'opaque glass'. If only Reggie Perrin had thought of them for his Grot shops ...

As an academic, we use 'normally' a lot in our regulations. FTN95.CHM could use this - or '... it cannot be guaranteed unless ...' which is a good let out too.

I'm pretty au fait with opaque glass. Try 'obsidian' in Wikipedia.

Eddie

Eddie,

I am already au fait with obsidian, the snowflake variety is especially pretty. Wouldn't want my windows made from it though 😉 - I was alluding to the sort of glass that works best as a see-through concept (as I'm sure you were well aware).

Sparge