From: Steven E. Harris
Subject: CL implementation to process Windows messages
Date: 
Message-ID: <q94vezmh7yt.fsf@chlorine.gnostech.com>
Are there any CL implementations for Windows that allow one to process
Windows messages, similar to the idiomatic Win32 message pump loop? I
don't necessarily mean the literal

  GetMessage()
  TranslateMessage()
  DispatchMessage()

function equivalents, but maybe even a way to register to receive
callbacks in CL for a specific message ID?

I have an application that needs to receive certain operating system
notifications that arrive as Windows messages (e.g. WM_DEVICECHANGE).
To receive them in my current C++ program, I create a hidden window
and run a pumping loop as described above to catch a subset of
interesting messages broadcast to all active windows.

Most of the application running above this loop -- waiting for and
reacting to these events, among others -- could be written in CL. It
would be great to move the whole Windows message processing business
into CL.

If that proves to be impossible, I suppose I could do something like
winnow the C++ program down to one that writes small messages across a
socket, and run a CL program listening on the socket to receive these
messages. That's just extra complexity that I'd rather avoid.

Advice would be most welcome.

-- 
Steven E. Harris

From: Jack Unrue
Subject: Re: CL implementation to process Windows messages
Date: 
Message-ID: <bnrql1pr4cuok210db9h6jp1mc7jdoe9ro@4ax.com>
On Mon, 24 Oct 2005 15:22:00 -0700, "Steven E. Harris" <···@panix.com> wrote:
>
>Are there any CL implementations for Windows that allow one to process
>Windows messages, similar to the idiomatic Win32 message pump loop? I
>don't necessarily mean the literal
>
>  GetMessage()
>  TranslateMessage()
>  DispatchMessage()
>
>function equivalents, but maybe even a way to register to receive
>callbacks in CL for a specific message ID?

http://cl-cookbook.sourceforge.net/win32.html

has a very good overview and examples.  The actual FFI forms that
you use will depend on your particular CL.  You'll have to translate
the code you currently have that registers the Win32 window class,
in addition to defining the call-outs for the API and the structs.
I believe Corman Lisp provides those out-of-the-box, and a couple of
the OSS implementations have had contributions that demonstrate how
to do it.

-- 
Jack
From: Andreas Thiele
Subject: Re: CL implementation to process Windows messages
Date: 
Message-ID: <djjoom$9g7$02$1@news.t-online.com>
"Steven E. Harris" <···@panix.com> schrieb im Newsbeitrag 
····················@chlorine.gnostech.com...
> Are there any CL implementations for Windows that allow one to process
> Windows messages, similar to the idiomatic Win32 message pump loop? I
> don't necessarily mean the literal
>
>  GetMessage()
>  TranslateMessage()
>  DispatchMessage()
>
> function equivalents, but maybe even a way to register to receive
> callbacks in CL for a specific message ID?
>
> ...

Of course you can do so. Lisp has a foreign language/function interface 
(called FLI or mostly FFI). With a few FFI definitions you have access to 
TranslateMessage et al.. I did this once with clisp and LispWorks, but I'm 
sure nearly any Lisp offers FFI.

Andreas
From: Kenny Tilton
Subject: Re: CL implementation to process Windows messages
Date: 
Message-ID: <Q7h7f.614$u43.445@twister.nyc.rr.com>
Steven E. Harris wrote:
> Are there any CL implementations for Windows that allow one to process
> Windows messages, similar to the idiomatic Win32 message pump loop? 

As Andreas suggested, just do the FFI thing. But to answer your 
question, AllegroCL's Common Graphics API makes it easy to snag win32 
messages. I would be surprised if LW's CAPI were any different, though 
it might take digging into internals since CAPI is portable across OSes. 
Try me by email if you want pointers on exactly how our code does it, or 
(going on deep recall) apropos on "process-" in the CG package (allowing 
internal symbols to be safe).

-- 
Kenny

Why Lisp? http://wiki.alu.org/RtL_Highlight_Film

"I've wrestled with reality for 35 years, Doctor, and I'm happy to state 
I finally won out over it."
     Elwood P. Dowd, "Harvey", 1950
From: Steven E. Harris
Subject: Re: CL implementation to process Windows messages
Date: 
Message-ID: <q94y84he5s7.fsf@chlorine.gnostech.com>
Kenny Tilton <·······@nyc.rr.com> writes:

> As Andreas suggested, just do the FFI thing.

That's a daunting proposal, but I get the idea.

> But to answer your question, AllegroCL's Common Graphics API makes
> it easy to snag win32 messages.

This looks like the right sort of thing. I found the Franz Allegro CL
documentation for Common Graphics�, and there's a section entitled
"Handling Low-Level WinAPI Messages" that makes my goal sound simple
to achieve.

[...]

> Try me by email if you want pointers on exactly how our code does
> it, or (going on deep recall) apropos on "process-" in the CG
> package (allowing internal symbols to be safe).

Thanks. I'll first have to get an Allegro trial version set up again
to do some experimenting.


Footnotes: 
� http://www.franz.com/support/documentation/7.0/doc/cg/cg-events.htm

-- 
Steven E. Harris
From: Steven E. Harris
Subject: Re: CL implementation to process Windows messages
Date: 
Message-ID: <q94zmoxclc9.fsf@chlorine.gnostech.com>
"Steven E. Harris" <···@panix.com> writes:

> I'll first have to get an Allegro trial version set up again to do
> some experimenting.

It turns out that WM_DEVICECHANGE is not mapped to a generic function
in ACL7, or at least it's not called something like
win:WM_DEVICECHANGE. I couldn't find any other catch-all handler that
might allow one to trap a message for which no method (yet) exists.

That was all sounding too easy.

-- 
Steven E. Harris
From: Kenny Tilton
Subject: Re: CL implementation to process Windows messages
Date: 
Message-ID: <kzG7f.3109$u43.2055@twister.nyc.rr.com>
Steven E. Harris wrote:
> "Steven E. Harris" <···@panix.com> writes:
> 
> 
>>I'll first have to get an Allegro trial version set up again to do
>>some experimenting.
> 
> 
> It turns out that WM_DEVICECHANGE is not mapped to a generic function
> in ACL7, or at least it's not called something like
> win:WM_DEVICECHANGE. I couldn't find any other catch-all handler that
> might allow one to trap a message for which no method (yet) exists.
> 
> That was all sounding too easy.
> 

Once more into the breach! I think the next layer down will let you trap 
arbitrary messages.hmmm, I had the CG source under our license, could be 
hard to find without that. Give Franz support an email if you are still 
in the hunt. I believe they will take reasonable Qs such as this even 
from trial users. Tell them His Royal Kennyness sent you.

-- 
Kenny

Why Lisp? http://wiki.alu.org/RtL_Highlight_Film

"I've wrestled with reality for 35 years, Doctor, and I'm happy to state 
I finally won out over it."
     Elwood P. Dowd, "Harvey", 1950
From: Kenny Tilton
Subject: Re: CL implementation to process Windows messages
Date: 
Message-ID: <435F366B.1050201@nyc.rr.com>
[on cll as well]

Steven E. Harris wrote:

> "Steven E. Harris" <···@panix.com> writes:
> 
> 
>>I'll first have to get an Allegro trial version set up again to do
>>some experimenting.
> 
> 
> It turns out that WM_DEVICECHANGE is not mapped to a generic function
> in ACL7, or at least it's not called something like
> win:WM_DEVICECHANGE. I couldn't find any other catch-all handler that
> might allow one to trap a message for which no method (yet) exists.
> 
> That was all sounding too easy.
> 

This was the deal under ACL 5.1. I see in ACL7 window-procedure is still 
there and exported. Happy hunting:

(without-package-locks
  (defmethod cg::window-procedure :after ((w ArchosWindow) msg wparam 
lparam)
    (case msg
      (#.WM_COPYDATA
       (format t "~&ArchosWindow sees WM_COPYDATA")
       (WM_COPYDATA w wParam lParam))
      ))
  )

You of course must determine the numeric value of WM_DEVICECHANGE and 
test for that.

-- 
Kenny

Why Lisp? http://wiki.alu.org/RtL_Highlight_Film

"I've wrestled with reality for 35 years, Doctor, and I'm happy to state 
I finally won out over it."
     Elwood P. Dowd, "Harvey", 1950
From: Andras Simon
Subject: Re: CL implementation to process Windows messages
Date: 
Message-ID: <vcd8xwgmrnr.fsf@csusza.math.bme.hu>
Kenny Tilton <·······@nyc.rr.com> writes:

> Steven E. Harris wrote:
> > Are there any CL implementations for Windows that allow one to process
> > Windows messages, similar to the idiomatic Win32 message pump loop?
> 
> As Andreas suggested, just do the FFI thing. But to answer your
> question, AllegroCL's Common Graphics API makes it easy to snag win32
> messages. I would be surprised if LW's CAPI were any different, though
> it might take digging into internals since CAPI is portable across
> OSes. 

(quite OT in this context, but) So is CG:

| IDE on Linux (Preview) -- The IDE is the Allegro CL Integrated
| Development Environment. It works in concert with a windowing system
| called Common Graphics. It has been available for Allegro CL's
| MicroSoft Windows product for many years. It is now available on x86
| Linux platforms running Allegro CL 8.0.

http://www.franz.com/products/allegrocl/ACL_8.0_beta.lhtml

Andras
From: Michael J. Ferrador
Subject: Re: CL implementation to process Windows messages
Date: 
Message-ID: <5Lo7f.8039$SH6.6764@trndny08>
"Steven E. Harris" <···@panix.com> wrote in message
····················@chlorine.gnostech.com...
> Are there any CL implementations for Windows that allow one to process
> Windows messages,

/dev/windows & clipboard ? in cygwin (clisp avail)

http://www.cygwin.com/cygwin-ug-net/using-specialnames.html
From: Steven E. Harris
Subject: Re: CL implementation to process Windows messages
Date: 
Message-ID: <q94u0f5e5du.fsf@chlorine.gnostech.com>
"Michael J. Ferrador" <·····@yahoo.com> writes:

> /dev/windows & clipboard ? in cygwin (clisp avail)

I use CLISP on Cygwin, but had never noticed the /dev/windows special
device. Unfortunately, documentation is scarce on how to actually use
/dev/windows. Presumably one can wait on it and read something like an
(HWND, UINT, WPARAM, LPARAM) tuple; that's only a guess.

The message I'm looking to trap only gets directed to active windows,
so the polling thread must have created at least one window in order
to receive the message. I don't know if Cygwin has an active window
handle under the covers, but some initial testing here doesn't show
any messages arriving. Having access to a message queue is therefore
not enough in this case, though the simplicity of the idea is quite
appealing.

-- 
Steven E. Harris
From: Surendra Singhi
Subject: Re: CL implementation to process Windows messages
Date: 
Message-ID: <k6g1qkxd.fsf@netscape.net>
"Steven E. Harris" <···@panix.com> writes:

> Are there any CL implementations for Windows that allow one to process
> Windows messages, similar to the idiomatic Win32 message pump loop? I
> don't necessarily mean the literal
>
>   GetMessage()
>   TranslateMessage()
>   DispatchMessage()
>
> function equivalents, but maybe even a way to register to receive
> callbacks in CL for a specific message ID?

wxCL uses wxWidgets's event handling library, and I think (but am not very
sure) it allow this to be done, and even there are equivalents for the above
functions.   

-- 
Surendra Singhi
http://www.public.asu.edu/~sksinghi/index.html

,----
| "O thou my friend! The prosperity of Crime is like unto the lightning,
| whose traitorous brilliancies embellish the atmosphere but for an
| instant, in order to hurl into death's very depths the luckless one
| they have dazzled." -- Marquis de Sade
`----
From: Steven E. Harris
Subject: Re: CL implementation to process Windows messages
Date: 
Message-ID: <q94fyqpcil6.fsf@chlorine.gnostech.com>
Surendra Singhi <·········@netscape.net> writes:

> wxCL uses wxWidgets's event handling library, and I think (but am
> not very sure) it allow this to be done, and even there are
> equivalents for the above functions.

Thanks for the suggestion. I just spent a few minutes browsing the
wxWidgets manual.� You're right that the basic framework is there, but
this library also fails to include the Windows message I need to trap
(WM_DEVICECHANGE).  Perhaps that event still gets delivered to some
default handler, but I didn't see yet how one can intercept such a
message, and have access to the various structures associated with its
interpretation.


Footnotes: 
� http://www.wxwindows.org/manuals/2.6.2/wx_contents.html

-- 
Steven E. Harris
From: David Steuber
Subject: Re: CL implementation to process Windows messages
Date: 
Message-ID: <87ek695kdf.fsf@david-steuber.com>
"Steven E. Harris" <···@panix.com> writes:

> Are there any CL implementations for Windows that allow one to process
> Windows messages, similar to the idiomatic Win32 message pump loop? I
> don't necessarily mean the literal
> 
>   GetMessage()
>   TranslateMessage()
>   DispatchMessage()
> 
> function equivalents, but maybe even a way to register to receive
> callbacks in CL for a specific message ID?

OS X' Carbon API works somewhat differently, but there are certain
similarities.  For example, specific events are ultimately identified
by a pair of integers.  Here, CLOS' eql specialization is your
friend.  At least it worked out nicely for me:

  http://www.david-steuber.com/Lisp/OSX/Carbon/

It sure beats using a CASE (or COND).

My code is getting old in the sense I haven't touched it in several
months.  It is also for Carbon, not Win32 and I have been using
OpenMCL's FFI directly.  Still, if you are working at such a low level
you might get some ideas about how the basic principle can be adapted
to Win32.

-- 
http://www.david-steuber.com/
The UnBlog: An island of conformity in a sea of quirks.
The lowest click through rate in Google's AdSense program.
----------------------------------------------------------------------
From: Stefan Scholl
Subject: Re: CL implementation to process Windows messages
Date: 
Message-ID: <f25bp8jrecgq$.dlg@parsec.no-spoon.de>
On 2005-10-25 00:22:00, Steven E. Harris wrote:
> Are there any CL implementations for Windows that allow one to process
> Windows messages, similar to the idiomatic Win32 message pump loop? I
> don't necessarily mean the literal
> 
>   GetMessage()
>   TranslateMessage()
>   DispatchMessage()
> 
> function equivalents, but maybe even a way to register to receive
> callbacks in CL for a specific message ID?

Sounds like a Job for Corman Lisp http://www.cormanlisp.com/
Check out the examples directory.
From: Frank Buss
Subject: Re: CL implementation to process Windows messages
Date: 
Message-ID: <1ie0yvreb364l.4opntvnf2imz.dlg@40tude.net>
Steven E. Harris wrote:

> Are there any CL implementations for Windows that allow one to process
> Windows messages, similar to the idiomatic Win32 message pump loop?

I've written a program for LispWorks, where you specify your own Window
callback function and which handles all messages, see 
http://www.frank-buss.de/lisp/canvas.html

It uses a patched version of UFFI (because of missing callback support),
but should work with minor modifications with other Lisp implementations,
too.

-- 
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de