Its purpose is to provide a tooltip for when the text is too long to fit into the pane

How does the compiler know that the text has exceded the limit of the pane ?_________________''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... "

Howvever I don't find any mention of the ClearWin function SB_GETRECT in the on-line manual, where is it actually documented ?

The other point, for the API's you quote, is the perennial question 'how do you go about writing the FORTRAN 'wrapper' lines ?'
Like the ones you sometimes quote on posts..
Some simple guidelines (for idiots in my case) and concrete examples would be very useful to have in the Help manuals, to open up to less savvy users like myself how to use API's when a particular ClearWin+ function doesn't exist.

I've googled around the WwW before to try to find some instructions, even just some actual examples, but without the slightest success.

Oh, almost forgot, why is it a lot easier in 'C' ?
Surely the steps in the procedure you outline are the same ?_________________''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... "

Since programming is an interest, but by no means my main occupation, I tend to like things that are, or look like, Fortran, and dislike delving into MSDN, where the language is rather alien. So, it may be easier for Paul to do it in C (my emphasis) - but for me it isn't.

It did look to me that the new %sb might be the answer to something that I have been mulling over for some time, and that is adding a status bar to a particular application. As I noted earlier, a status bar ‘balances’ the appearance of a window, and the sizegrip balances the generally leftwards weighting of the bar itself. (My apps usually have the whole of the client area of the main window devoted to a %gr graphics area).

After spending a bit of time programming, it dawned on me that I was making a rod for my own back. I find that if what I want to do is difficult, then it is because I’m trying to reinvent the wheel, and do something in an original way – not in a tried-and-tested Windows way. The particular application has input and output files, and I thought that I’d put the filenames, complete with path information, on the status bar.

This is the problem: the boxes are fixed in size, and do not resize if the window is resized. Moreover, if I make allowance for the maximum path-and-filename length for the first name, then the second name starts a long way across the bar.

The boxes in a status bar are ideal for some smallish data items, for example coordinates and very short messages - not potentially great long path names. It also seems a little difficult to get things right-justified.

Of course, the answer turned out to be simpler than I had thought: Do it myself using drawing commands at the bottom of the %gr window! Actually, this is my normal response to just about anything – such as drawing a movable toolbar. It seems to also be the way to draw the status bar any way I want to! (And the tools are there in Clearwin+, and have been for a long time.

The trick, if it is a trick, to get my file names in is to user-redraw the status bar as well as the other contents of the graphics region when there is a resize event, and if the paths and filenames are too long for the space available, which is the full width of the window minus my own window dressing, then I can abbreviate the file name-and-path and position them in a way I can't when using %sb.