Window listing and manipulating windows in workbench 3.x

[edmayn]

Hi,

I have two questions:

1. How should I go about getting a list of all windows on the current screen?

I have read through the intuition.library and workbench.library functions and I can't seem to find a function or a combination of functions which would return a list of current windows on a given screen and their IDCMPs.

2. Can I assume that when I have a list of these window IDCMPs I can manipulate the geometry and placement of the windows? Or am I approaching this using the wrong tools, so to speak?

[Leffmann]

For a given screen, you can enumerate its windows by looking at the FirstWindow member, and the NextWindow member for each successive window.

When you have found the window you're looking for, you can f.ex. use Intuition ChangeWindowBox() to control its size and position.

[nogginthenog]

The Screen struct has a linked list of Windows. see: screen->FirstWindow

[thomas]

Actually you must not manipulate anything that does not belong to your program.

If you do it, you have to keep in mind that there is no way to prevent a window from closing before you can manipulate it. In this case the window pointer you are using becomes invalid and your program will crash. Or do something bad in memory which belongs to another program.

To get a list of windows on a screen you can start with screen->FirstWindow and follow window->NextWindow until you got all. Protect this by a call to LockIBase() before you start and UnlockIBase() when you are ready. Be aware that you must not call any intuition.library function between LockIBase and UnlockIBase.

IDCMPs are not involved. Many windows don't even have an IDCMP.

Also be aware that there are borderless windows, backdrop windows and such whose position and size you might not want to change.

It's dangerous to fiddle with things that are not under your control.

[edmayn]

Thank you everyone for the awesome information. Enough to get me experimenting.

I was planning to write some code which would manipulate windows on demand (also those owned by other programs) so they would tile in a non-overlapping way (i.e. a tiling window manager), but your advice Thomas confirmed my suspicion that this might be very hard with AmigaOS. Some other tiling thing might come of it still.

I'll begin experimentation, which will probably involve some pretty dangerous fiddling and return if I produce anything interesting, or get hopelessly stuck.

[idrougge]

To put things in perspective, even Commodore's own FKey commodity makes spurious assumptions about legal pointers.

[Minuous]

It should be a safe enough operation as long as Forbid()/Permit() are used to prevent the window being closed in the interim.

[Daedalus]

Forbid()/Permit() can help avoid dangerous situations, but try not to use them any longer than is absolutely necessary.

I would suggest being especially careful of resizing windows that aren't meant to be resized, or not to the sizes you might require by tiling. A good idea might be to only resize those windows that have the WFLG_SIZEGADGET bit set in the Flags field, and *always* respect the min and max window size settings.

Bear in mind that some programs might not set safe max and min values simply because they don't expect to be resized due to not having a resize gadget in the bottom right corner. If you make a window larger than was intended, it could end up larger than the bitmap it's displaying for example, giving you garbage on screen or possibly causing crashes. Making it smaller could result in a program drawing over the borders, also resulting in display issues and potential crashes.

[Cylon]

Whatever you try to code, have a look at WinZoom first. Maybe this is what you're looking for. No need to invent the Wheel twice. ;-)
ftp://aminet.net/util/cdity/WinZoom.lha

[edmayn]

Thanks Cylon.

Actually, I found a tool I had previously overlooked:

http://aminet.net/package/util/wb/windowtiler21b

It does exactly what I want and works flawlessly. A very nice piece of software, which I can recommend.

I have written the programmer Doug Dyer an email and asked if he is willing to share the source code, as I'm really interested in how he managed to control the windows so efficiently. It is probably very unlikely that he is reachable by the email he was using 22 years ago, so does anyone here by any chance know Doug Dyer or know how to reach him?

[Retro1234]

If exist a program to list all open windows id be intrested.

[Minuous]

Scout can list all open windows.

[Cylon]

http://aminet.net/package/util/wb/listwindows
coincidentally uploaded two days ago???

[Retro1234]

I'll check it out
What I want to do is have a reboot script for things like WHDload then after load Workbench again and open all the windows you had open.

[bubbob42]

I'm planning to add an ARexx-Port to the next WinZoom-version, which should help to automate things, like window presets for each screen, etc.

[Daedalus]

If you're just looking to remember the Workbench windows that were open (and not applications etc.), and have Workbench 3.9, I wrote a set of scripts a while back that does just that. You place a script in the WBStartup drawer, and it opens the saved windows at the saved locations. It also adds a menu item to the Tools menu which lets you snapshot the current window setup. If it's not exactly what you want, it might be of use to you for writing your own version. RememberOpenDrawers on Aminet

[edmayn]

I wrote a little window lister program as an exercise to get familiar with the intuition library. It lists windows, their size an coordinates, on the Workbench screen only:

#include <stdio.h>
#include <string.h>
#include <proto/intuition.h>

int main(void)
{
  struct Screen *screen;

  // Lock workbench
  if(screen=LockPubScreen("Workbench"))
    {
      struct Window *window;
      ULONG ilock;
      int winnr = 0;

      ilock=LockIBase(0);

      // Loop through windows on screen
      for (window=screen->FirstWindow;
           window;
           window=window->NextWindow)
           {
             // Not really interested in Workbench window information
             if (!stricmp(window->Title,"Workbench")==0)
               {
                 printf("%s %d\n%s  \"%s\"\n%s %4d\n%s %d\n%s %8d\n%s %8d\n",
                         "Window:", winnr,
                         "Title:", window->Title,
                         "Width:", window->Width,
                         "Height:", window->Height,
                         "x:", window->LeftEdge,
                         "y:", window->TopEdge);

                 // Increment window id
                 winnr++;
               }
           }

      // Unlock IBase and screen
      UnlockIBase(ilock);
      UnlockPubScreen(0,screen);
    }

  return 0;
}

I've begun rearranging windows and I will share some code when its functional.

[thomas]

window->Title might be NULL, so your program may cause Enforcer hits. In fact the Workbench window does not have a title, so your stricmp does not work anyway and causes a hit.

Also this program causes a deadlock because the console handler does LockIBase, too (at least with KongCON) and output to the window will wait for the console while the console waits for the lock.

[edmayn]

Thanks for the feedback Thomas.

The workbench window does have a title.

Here is a screenshot with the stricmp if commented out:


And here is one with the stricmp enabled again:


You do have point with the empty window titles and I will check for it and set a default title.

I'll see what I can do to avoid the deadlock you mention in regards to KingCON (and probably other console handlers).

[thomas]

Originally Posted by edmayn

The workbench window does have a title.

Not if used as backdrop.