Creating a docked window

I’m looking to create a window with an attached tool panel, similar to !Draw. I’ve created two windows, one with the usual furniture, the other without any furniture which opens to the side of the first one.

How to get the second window to stick to the main window as the main window is dragged? I can’t figure out how to access or set the window position programmatically after it has been intially opened.

Thanks for the help, I’m a beginner with this!

It gets complicated.
The work is done in window open poll returns. I may not have the right solution, but I ended up opening windows 3 times – first the one with toolbars etc, then the pane window, adjusting its position while doing it, then the main again. (Though thinking about it, it might have been pane, main, pane.)

One of those opens is needed to get the pane in fromt of the main.

You need to respond to open requests for either of the windows, and I found I could use the same code for both.

Using the “Nested Wimp” is supposed to make it easier, but I couldn’t get that to work at all.

Now that we’re talking about it: what does the ‘Pane’ tick in template editors actually do? How should it be used?

what does the ‘Pane’ tick in template editors actually do?

AFAIK, it simply indicates that if the “pane” window gets input focus, the highlight should be given to the window behind it in the window stack.

I may not have the right solution, but I ended up opening windows 3 times – first the one with toolbars etc, then the pane window, adjusting its position while doing it, then the main again

That sounds complex. Assuming that your pane window can’t move of its own volition, you handle that normally. Then for the main window, you open the pane first at the stack position requested for the main window, then open the main window behind it in the same poll event. You do this by adding some logic to the Open Window event from Wimp_Poll.

Using the “Nested Wimp” is supposed to make it easier, but I couldn’t get that to work at all.

It’s a lot easier… which is why my pane handling is rusty these days.

Are we working in BASIC here? If so, I could probably put a simple example together.

Are we working in BASIC here? If so, I could probably put a simple example together.

If you have time/inclination, please do.
I use the old fashioned pane handling. It would be useful to have a simple (non-Toolbox) example of how to use the nested Wimp for doing panes.

Yes, BASIC, an example would be great.

For either the Nested WIMP, or the pane solution.

Ok, I’ll have a look – I’ve made a simple(ish) skeleton with no panes, and will see if I can do a comparison between the two methods over the weekend.

@Andrew I spotted the following link https://www.flypig.co.uk/riscos; see Button Bar. Is that what you need?

In Draw the tool pane hangs to the left of the main window, but outside. I thought the Nested Wimp only supports child windows that are within the work area or scrollbar or window furniture area of the main window.

If the Nested Wimp also supports child windows that hang outside the main window area, then I’ve not been fully aware of its capabilities.

@Andrew I spotted the following link https://www.flypig.co.uk/riscos; see Button Bar. Is that what you need?

This source has helped me to finally figuring out how to create a nicely obeying pane. Nevertheless, I would still welcome Steve’s simple example. Perhaps it will even make me understand what I fiddled together.

So as I said earlier, I got it to work by opening windows three times. Here’s how I did it. I’m not saying it’s optimal, nor can I explain WHY it works, but it does.
<pre> DEF PROCopenwindows(wimpblock%)

ENDPROC


I’ve not seen the use case, but do you really want to apply the main window scroll offsets (offsets 20 and 24) to the pane? This certainly wouldn’t be the case for the OP’s “draw-style” toolbox.

The first call to Wimp_OpenWindow looks superfluous, but I’m happy to be proven wrong.

Thanks everyone for the replies, I’ve got something working in the polling loop which uses Wimp_GetWindowState to obtain the X and Y position of the main window, checks bit 16 of the window flags to confirm the main window is open and then calls Wimp_OpenWindow on the tools window at the correct location.

Everything seems to be working well, thanks again! I have already posted my next question in a new thread…

Here is the code:

DEFPROCpoll
    SYS "Wimp_Poll",,b% TO r%
    CASE r% OF
        WHEN 1:PROCredraw(b%)
        WHEN 2:SYS "Wimp_OpenWindow",,b%
        WHEN 3
            SYS "Wimp_CloseWindow",,b%
            !b% = tools_window%
            SYS "Wimp_CloseWindow",,b%
        WHEN 6:PROCmouse_click
        WHEN 8:PROCkey_press
        WHEN 9:PROCmenu_click
        WHEN 17,18:PROCreceive
    ENDCASE

    !b% = edit_window%
    SYS "Wimp_GetWindowState",,b%

    IF b%?34 AND %00000001 THEN
        minX% = b%!4
        minY% = b%!8

        !b% = tools_window%
        SYS "Wimp_GetWindowState",,b%
        b%!4 = minX% - 100
        b%!8 = minY%
        b%!12 = 100+b%!4
        b%!16 = 600+b%!8
        SYS "Wimp_OpenWindow",,b%
    ENDIF
ENDPROC

If anyone has suggestions for improvement I’d like to hear them.

The thing I’d recommend with window panes is please don’t try to keep them on screen if the main window is off screen. Virtual desktop programs such as my !WorkSpace or !MoreDesk work by moving windows off screen when they are on different desktops, but there are a few applications which insist on keeping their tool panes on screen, which ruins the concept.

Here is the code:

Well, if it works, it works. But I’d think that checking the window state and opening the same window again and again at every wimp poll is a bit overdone. After all, the wimp poll is there to react on changes, not to infinitely calculate a static situation.

The ‘Button Bar’ example, given by Andrew McCarthy, provides a concise routine for pane handling (concise, also because the code is somewhat compressed, but it’s still readable). I can really recommend it.

The ‘Button Bar’ example, given by Andrew McCarthy, provides a concise routine for pane handling (concise, also because the code is somewhat compressed, but it’s still readable). I can really recommend it.

I tried that link, but it went to a list of software. One entry was called “Button Bar”, but it only offered screenshop or binary to download, no source code. The description of Button Bar doesn’t seem relevant to panes.

One entry was called “Button Bar”, but it only offered screenshop or binary to download

The binary contains the BASIC source – a bit confusing indeed. Search for DEFPROCmove_bar and you’ll find the routine that at least helped me figuring it out.

If anyone has suggestions for improvement I’d like to hear them.

There’s a few things that need attention…

SYS "Wimp_Poll",,b% TO r%

First, you should never be using Wimp_Poll without null events masked, unless you have a really good reason for it¹. If you’re using null events, then Wimp_PollIdle with a suitable interval is the call that you need, but since you’re not using null events at all, then you should be using Wimp_Poll and passing an event mask in R0 to disable null events from being returned to your task:

SYS "Wimp_Poll",%1,b% TO r%

As your code stands, the Wimp will be permanently sending null events to your task when it’s not doing anything else, which prevents it throttling back when idle on things like laptops (under emulation or on an ARMBook), and will drain people’s batteries in minutes…

Second, as Paul has already noted, your pane handling code should only be called on Open Window Request events, and only when it’s the main window being opened. Instead, you’re compounding the null event problem above by re-opening the two windows on every single null event – more than a bit anti-social, and probably not great for the responsiveness of other background tasks.

You’re also not keeping the pane directly above the main window in the window stack, which is at best good practice (and will have odd effects if you start to move windows to the top).

Finally, the

IF b%?34 AND %00000001 THEN

is unnecessary, as if you only do the window shuffle on Open Window Request events, the window is, by definition, open.

Untested, and very much off the top of my head, but I’d prefer the following:

DEFPROCpoll
    SYS "Wimp_Poll",%1,b% TO r%
    CASE r% OF
        WHEN 1:PROCredraw(b%)
        WHEN 2:
          IF !b% = edit_window% THEN
            PROCopen_main_window(b%)
          ELSE
            SYS "Wimp_OpenWindow",,b%
          ENDIF
        WHEN 3
            SYS "Wimp_CloseWindow",,b%
            IF !b% = edit_window% THEN
              !b% = tools_window%
              SYS "Wimp_CloseWindow",,b%
            ENDIF
        WHEN 6:PROCmouse_click
        WHEN 8:PROCkey_press
        WHEN 9:PROCmenu_click
        WHEN 17,18:PROCreceive
    ENDCASE
ENDPROC

DEF PROCopen_main_window(b%)
    LOCAL q%, width%, height%
    
    REM Ideally, you would use a second block for q%. This method is OK
    REM so long as the block passed in b% is known to always be long enough.

    q% = b% + 128
    
    !q% = tools_window%
    SYS "Wimp_GetWindowState",,q%
    
    width% = q%!12 - q%!4
    height% = q%!16 - q%!8
    
    q%!4 = b%!4 - width%
    q%!8 = b%!8
    q%!12 = b%!4
    q%!16 = b%!8 + height%
    
    IF b%!28 <> !q% THEN q%!28 = b%!28
    
    SYS "Wimp_OpenWindow",,q%
    
    b%!28 = !q%
    
    SYS "Wimp_OpenWindow",,b%
ENDPROC

You need to be careful when opening the windows up from closed, but with my code above, that’s possible with something like the following:

!b% = edit_window%
SYS "Wimp_GetWindowState",,b%
b%!28 = -1
PROCopen_main_window(b%)

The above is all untested, and off the top of my head – there’s probably plenty of things that are wrong, but it’s closer to the preferred way to do it.

I’m still working on a proper tutorial for this, but real life got in the way this weekend and it looks as if I’ve missed the boat. Is there still any interest?

¹ The only one that I can think of a single-shot “has another operation finished?” kind of use before masking them out again. For any kind of background processing operation, you should be using Wimp_PollIdle – but you’re not doing that either.

Thanks everyone, particularly to Steve for the masterclass in how to do things less horribly.

I will make the required improvements…

Anyone got any ideas about my other question, editable rotatable text in a window?

Since upgrading to a Pi4 from a Pi3, I had vague memories of a small utility that enabled a bottom bar (nested) and supported adding a sidebar to programs.

I have rediscovered the two zip files containing the program ButtonBar and supporting files MinibarSJ and SJBartVert. These add a mini-sidebar and a small bottom bar(nested) to SwiftJPEG.

The author’s website was at http://stewy.drobe.co.uk, and the program was obtainable from there; that’s why I added the ButtonBar link. Although the link is now dead, I wonder if the Wayback machine still has copies?

If unavailable from the Wayback machine and someone wanted to host them, with agreement from the author, I’d be happy to share the files.

**Edit: The app ButtonBar is accessible from https://www.flypig.co.uk/riscos

PS. On the null event point, using TaskUsage (which may also come in $.Utilities in RISC OS 5 distros – I’m not near a machine to check right now) should give an idea of the effect of masking out null events or doing processing in them.

Is there still any interest?

Oh yes, please!