Silverfrost Forums

Welcome to our forums

Status bar %sb

25 Apr 2019 1:34 #23550

The help file states somewhat confusingly:

Modifiers

** Tilde (~) - indicates that the first panel of the status bar is to be used for help strings.**

Description N is optional. When N > 1, it specifies the number of panels and iar is an integer array specifying the width (in average characters) of each panel in turn. The width of the last panel is set automatically to extend to the right hand edge of the window. When N is not provided, iar is also omitted, resulting in just one panel.** A grave accent can be applied and indicates that the first panel of the status bar is to be used for help strings.**

Not that it matters, because the truth can be established by some simple trials.

My question is: Is there a way of determining at runtime how many characters are (roughly) available in a status bar ?

Eddie

25 Apr 2019 2:13 #23551

Eddie

I have corrected the help file but this is probably not in time for the next release.

ClearWin+ does not currently provide a simple way to get the current size of a given panel in the status bar.

The information is available via a call to SendMessage by using the HWND of the status bar and SB_GETRECT. If you want to try this then the first step would be to test to see if %lc works for %sb.

25 Apr 2019 3:16 #23552

Paul,

Thanks. SET_STATUS_TEXT@ doesn't appear to be in the Library Reference either.

When is the next version due?

Eddie

25 Apr 2019 5:28 #23553

We are working on it right now.

26 Apr 2019 5:44 #23554

I assume that there's a check built into %sb which flags an error...

No check is carried out.

26 Apr 2019 1:49 #23555

Paul,

I followed up the suggestion, and it isn't a lot of help. I came across SBARS_SIZEGRIP - that is something that puts the sizing icon in the bottom rhs of the window. Aesthetically, when the client area extends to the bottom of the window, the window looks a bit unbalanced, and even when a status bar is in use, (because everything is clustered to the left), the 'size-grip' is a nice feature, even if it is rather obsolete as all window edges are resizable these days.

I also saw that the status bar can have tooltips. My suggestion is therefore for:

%sb[sizegrip][tooltips]

I'm not much of a fan of straying outside Clearwin+, as you probably guessed.

I probably didn't express myself well in the original post. What I really want to do is find out how much capacity the status bar has before I invoke winio@('%sb so that I don't simply program invisible stuff off the end. I know this will be wrong for different logical dpi settings, so it will need to be assessed conservatively. Perhaps it's a question of running some tests and measuring using my onscreen pixel ruler: 'RulerByGeorge!'

Eddie

PS. Just about everything I write is run fullscreen, because the maximum number of pixels is required for the best graphical interaction.

26 Apr 2019 3:52 #23556

Eddie

I have made a note of your request/suggestion.

28 Apr 2019 1:19 #23559

Paul,

Many thanks for considering this.

Eddie

29 Apr 2019 12:26 #23560

I've done some measurements, and with a standard dpi setting, the text typically has a length that equates to about 5.3 pixels per character.

I run a dual monitor setup, with two 1920x1080 screens side by side. When my app with a %sb is launched, the statusbar doesn't have a 'sizegrip' If I move the window to straddle the two monitors, the window extends laterally, and the status bar then shows a 'sizegrip', which then remains part of it even if the window is shrunk back to fit on one screen. Weird.

Eddie

1 May 2019 12:24 #23563

Eddie

I have had a look at this.

SBARS_SIZEGRIP does not appear to do anything useful. If the window can be resize then you get the gripper anyway. If the window can't be resized then SBARS_SIZEGRIP adds the gripper but you can't use it to resize the window.

I will see if anything can be done with tooltips.

1 May 2019 4:08 #23564

Eddie

The SBARS_TOOLTIPS style is rather limited. Its purpose is to provide a tooltip for when the text is too long to fit into the pane. When the pane is big enough the tooltip does not appear. The tooltip is simply a copy of the text in the pane and the user sets this by calling set_status_text@.

This will probably not work with the first pane and %`sb where menu item info is controlling the content of the pane.

I have added this style but it may not be of much interest to users.

3 May 2019 8:41 #23576

Hi Paul,

Thanks for looking at this.

Eddie

3 May 2019 1:22 #23579

I don't know. It's all in the Windows API.

3 May 2019 2:52 #23580

If I wanted to know if a string will appear without truncation within a pane then I would do something like...

  1. get the width of the pane via SendMessage and SB_GETRECT,

  2. get the device context of the status bar using GetDC,

  3. get the width of the text I want to display via GetTextExtentPoint32,

  4. test if the text width is ⇐ the pane width.

You can probably do this in Fortran but it's a lot easier in C.

8 May 2019 8:47 #23588

Can anyone else help John with the details?

8 May 2019 4:48 #23589

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.

Eddie

Please login to reply.