Hi!

Squeak's foreign function interface is great (it's not as good as Dolphin's 
but IMHO nicer than what VisualWorks offers).  I so tried yesterday night 
to create real Windows windows - perhaps as a first step towards native 
widgets.

I was amaized about the speed of Andreas' Win32 demo displaying rectangles 
and ellipses using GDI functions.  Finally my expensive graphics card could 
show its features and didn't had to copy boring bitmaps ;-)

On Windows, every control as well as true windows (Java would call them 
Frames, Morphic SystemWindows) are created using that mega-complex 
CreateWindowExA() function.  I implemented it and after working around some 
problems, it worked like a charm.  First my problems and how I solved them, 
then my questions.

I declared the function using Win32Window were the API specification 
required an hWnd.  Then I called the function using nil which I hoped would 
be replaced by 0 which again is the hWnd for the desktop.  This however 
didn't work.  Only after I replaced Win32Window with long, I could use nil 
as parameter.  Why isn't this automatically converted?  That's better in 
Dolphin.  There's a Object>>asParameter method which deal with all that 
conversions.

Then I had the problem to supply a hInstance and a window class name.  I 
barely remember that there was a way to get the current hInstance via some 
obsure API call sequence but that was too difficult and I used Spy++ to 
determine the current value which I then coded by hand.  It would be nice 
if there's some way to get the value from the VM.  I think, it gets it 
passed by Windows when WinMain is called.

The WindowClass now was really difficult.  For frame-like windows, one need 
one's own structure registered with a special function call.  Of course I 
could have created that structure object and probably even registered - I 
didn't try (is it possible to allocat memory for such structures which is 
garanteed not to move?) - but that structure needs a pointer to a Windows 
callback function which is then called by Windows for all windows events 
(like WM_MOUSEDOWN etc).  This is actually the key to real event 
handling.  One has to assume that this method is called asynchronly but 
only once.

Is there any way to specify a Squeak method as such a (often called) 
call-in function?  I didn't see how to do that.  Without that, it's 
unfortunately not much what one could do with FFI.

As I had already Spy++ running, I noticed that Squeak's main window is of 
class SqueakWindowClass and so I used that name for my test.  The funny 
thing is, that know if you try to close that new window, you get the "Quit 
without saving?" question...

Adding a pushbutton to that new client window then was easy again.

However, even without callbacks, it might be possible to come up with a 
good solution towards more native windowing support.  I don't know exactly 
how to do this, but one could create a special DLL which registers a 
special WindowProc (that callback thingy) written in C which keeps track of 
mouse buttons pressed, mouse position and the keys pressed - very similar 
to the way, Squeak's own windowing code already works.

However, it should then signal a semaphore for every event received and a 
Squeak process would wait for that signal, reading the event prepared by 
the supporting C code.  Instead of polling mouse buttons and having a small 
queue for key strokes I'd however use one unified queue of event data 
stored in Smalltalk arrays.  So you could not only receive mouse events and 
keyboard events but also window events like window iconified or the fact 
that a window got the focus or was resized.

I'd like to know whether it is possible to establish this kind of 
connection between a C DLL and the Smalltalk code and how to do this.  If 
there's a better solution, I'd of course also be interested in that.

bye
--
Stefan Matthias Aust  //  Bevor wir fallen, fallen wir lieber auf