Dynamic scrollbars? Background color when scrollbars enabled

Two questions:

Question 1: Is there a mechanism by which a set of horizontal/vertical scrollbars can be added to a window at creation time?

If the window being created can fit within the screen, the scrollbars are not really needed. However, if it is too big to reasonably fit, I'd like to have the scrollbar activated. Is this even possible?

Question 2: When the scrollbars are 'forced', the additional border beyond the child window that contains both the HELP line and the scrollbars is filled with the default color (light grey) rather than the white specified for the %bg color of the main window. Is there a reasonable way to make the color uniform?

Thanks, Bill

Reply 1: It is possible but not without accessing the Windows API directly. Here is an extract from MSDN...

'You can use the CreateWindowEx function to create a scroll bar by specifying the SCROLLBAR window class. This creates a horizontal or vertical scroll bar, depending on whether SBS_HORZ or SBS_VERT is specified as the window style. The scroll bar size and its position relative to its parent window can also be specified.'

If you look at applications like Notepad, Visual Studio and Plato then scroll bars are provided when they are not needed, sometimes because they provide for splitter windows etc.. Scroll bars are tricky anyway and to get them to disappear when not needed just confounds the issue.

Reply 2: Can you provide sample code that illustrates this situation?

Paul, if I can get #2 solved, #1 becomes moot. Thanks for the reference. I figured it would be problematic.

The following code segment shows the issue. I set the background color of the child and parent window to white. I set the background color of the menu help to yellow. Just past this yellow area, the remainder of the background is light grey (the default window color). If one expands the parent window, you can see the remainder is grey. I allow my users to set the help menu text color and background color because some of them have visual color issues.

	winapp
    program main
    use mswin
    integer,external:: defg
    integer:: i=0,j,k=99,l,ii,w=0,h=0
    ii=winio@('%sh%bg[white] %^bt[test] %rd %5nl %rd',j,defg,i,k)
    jj = winio@('%ww[not_fixed_size]%sz&',w,h)
    jj = winio@('%th&',1)
    jj = winio@('%bg[white]&')
    kk = winio@('%?mn[Test[Test]][HelpText]&',defg)
    jj = winio@('%ch[vscrollbar,hscrollbar]%ff%`bg[yellow]%he',j)!
    print *,jj
    end
    integer function defg()
    defg = -7
    return
    end

It matters not whether I have help enabled. When the scrollbars are generated, the background under them (then exposed) is light grey.

Bill

I should have asked about the context for question 1. Controls like %cw, %eb and %gr have options that provide embedded scroll bars. Also in theory %hx and %vx provide scroll bars for the next control whilst %hs and %vs provide free standing scrollbar controls but I don't know if these have ever been used successfully.

I will aim to look at your sample code tomorrow.

There are various orderings that fix the problem. Here is one of them...

    winapp
    program main
    integer,external:: defg
    integer:: i=0,j,k=99,w=0,h=0
    jj = winio@('%sh%bg[white] %^bt[test] %rd %5nl %rd',j,defg,i,k)
    jj = winio@('%ch[vscrollbar,hscrollbar]&',j)
    jj = winio@('%ww[not_fixed_size]%sz&',w,h)
    jj = winio@('%?mn[Test[Test]][HelpText]&',defg)
    jj = winio@('%bg[white]&')
    jj = winio@('%th&',1)
    jj = winio@('%ff%`bg[yellow]%he')
    end

Bill,

Don't forget that there are other approaches to moving the window contents around, like changing the cursor to a 'grabber hand' and tracking the 'click and drag'.

However, I'm really writing about your users with visual colour perception difficulties. Is this mainly the infamous red-green colour blindness, or other things? If there are other problems, what are they? Are they particular to a certain person, or are they the common problem of red on blue or vice versa? It's a very important issue.

Eddie

Eddie, you are right. Colors and the ability to configure them for the user is important.

I have one (major) user who has a problem with colors, and he came up with a color scheme that worked for him. It looks rather plain, actually. I used it because it made the screen grabs easier to read in the documentation! He can distinguish RED, but only if the surrounding colors are a medium grey, for example. My former boss (long ago) was color blind in some colors, and had his wife arrange his suits in a particular order for him so his suits/shirts/pants would match. I have trouble with dark blue versus black, and dark browns can be problematic for me. All become clearer in bright sunshine (which Colorado has in abundance, thankfully!).

So, when I set a color code for an error inside of a control, I have to be sensitive to the user needs. I choose colors that are easy for me to see, and also allow the user to change those colors if they wish. Easy enough to do, actually! I am also using shapes for list-view icons to help the users identify problems in their data. Color doesn't matter, since the shape is different for each level of error.

White background is my 'default'. I don't like the light grey. It reduces the contrast for text, and I find that annoying. So when I saw the light grey after the menu help, I wondered that the heck is happening!

Paul's answer gives me options, absolutely!