Now days, there's many things you'd like to ask of the underlying OS to do with your GUI application. It would be nice of VisualWorks made all of each OSes features very transparent and easy to access, but the truth is, it doesn't. So you often have to step outside of the stock interface provided by the VisualWorks VM. I've found that over the years, the most popular starting point, is OS features that manipulate windows. Having just gone through how to get at the pieces of data that the host OS seems to want to manipulate VW windows for all 3 major windowing platforms, I thought I'd pass along.

Windows

This is probably the most common and most known. Sending the message windowHandle to a VisualWorks window running under the Windows Operation System, will return a the pointer address of the Windows HWND structure. This is used by many of the Win32 APIs. It's often nice to work with the HDC of a window as well. Support for this can be found in the Win95SystemSupport object. Do ssomething like:

	winp := CVoidType void pointerType newOfAddress: aWindow windowHandle.
	hdc := Win95SystemSupport new GetDC: winp.

One thing I've noticed is that this HDC can go "stale" from time to time, seemingly after pop up menus have covered the window. If anyone knows why this is or how to get around it, I would be much obliged.

OSX Aqua (Cocoa)

You can get the handle to an NSWindow associated with a VisualWorks window by sending windowHandle to a VisualWorks Window instance when running under OSX Aqua. After that, it's just sending messsages to it to manipulate it or get other associated objects. See the previous post.

XWindows (X11)

This is the most "obscure" of the 3. X interfaces want a variety of things, and X Windows have a variety of opaque structures different APIs seem to want. Things like the Visual, or the Display, or the VisualInfo, or possibly a Drawable. At first blush, it's not obvious at all how to get this information. It turns out that by chance, sending windowHandle to a Window instance running under X11, will return the pointer address to the Drawable structure. If that's all you need, then you're set. I've never found that to be enough. What happens when you send windowHandle to a Window is that it sends key to the window's GraphicsHandle. GraphicsHandle is just an UninterpretedBytes object. And when you send key to it, it just returns the unsigned int found in the first 4 bytes of of the object. For other platforms, the GraphicsHandle is indeed just 4 bytes. So it makes sense. GraphicsHandle even "prints" itself as those first four bytes. But when you inspect the GraphicsHandle of an XWindows window, you'll find that it's actually 28 bytes big! It turns out that the VM (for X11) builds and keeps a structure of 7 elements to go along with each window instance. And the GraphicsHandle has a copy of all of those bytes in it. The structure it's mirroring is defined as:

typedef struct {
 	   Drawable drawable;
 	   GC gc;
 	   Display *display;
 	   XVisualInfo *visualInfo;
 	   q8 drawableType;
  	  q8 clipMode;
 	   XRectangle clipRectangle;
	} drawableData;

So, if you want the Display of an X11 Window under VisualWorks, you get it's handle (you may have to add an accessor for this), and send unsignedLongAt: 9 to it. or unsignedLongAt: 13 to get the XVisualInfo. Which you can in turn interogate for the Visual.