My first attempt ever at a win32 app (with mostly borrowed sample code)
has one tiny little problem: no client messages, just NC non-client
messages. GetClientRect shows a nice fat client rect (minus small
amounts for non-client areas like the frame and caption.
I am doing this from Lisp, and I will be exploring if this is an
artifact of my implementations handling of events (I'll try a different
win32 Lisp vendor). But I thought I would check here if this is a known
newbie gaffe. Google groups did not show anything.
Here is the class def:
(defun register-class ()
(macrolet ((wc-sv (slotname)
`(get-slot-value wc-p 'wndclass ',slotname)))
(with-cstring (cn-p *class-name*) ;;; ec bc :external-format
*external-format*)
(with-foreign-object (wc-p 'win:wndclass)
(setf (wc-sv style) (logior cs-hredraw cs-vredraw))
(setf (wc-sv lpfnWndProc)
(ff-register-callable 'cglwndproc))
(setf (wc-sv cbClsExtra) 0)
(setf (wc-sv cbWndExtra) 0)
(setf (wc-sv hInstance)
(win:GetModuleHandle (make-null-pointer 'lpctstr)))
(setf (wc-sv hIcon) 0)
(setf (wc-sv hCursor) (win:LoadCursor 0 IDC-ARROW))
(setf (wc-sv hbrBackground) (1+ color-window))
(setf (wc-sv lpszMenuName) 0)
(setf (wc-sv lpszClassName) cn-p)
(let ((rslt (win:RegisterClass wc-p)))
(if (/= rslt 0)
rslt
(error (format nil "~&RegisterClass failed in reg-class.
Error: ~a"
(win:GetLastError)))))))))
Here is the toplevel driver:
(defun cl-user::test-w32 ()
(let ((w (make-os-window *class-name* "Helloworld" 640 480)))
(win:ShowWindow w win:SW_SHOW)
(win:UpdateWindow w)
(with-foreign-object (msg msg)
(let ((msga (pointer-address msg)))
(do ()
((not (win:GetMessage msga 0 0 0))
(progn (print :bye-bye)
(get-slot-value msga 'msg 'wParam)))
(print `(getmess ,msga))
(win:DispatchMessage msga))))))
Here is the wndproc:
(ff-defun-callable :stdcall :long cglwndproc
((hwnd hwnd) (msg :unsigned-long) (wparam :unsigned-long) (lparam
:unsigned-long))
(cond
((= msg win:WM_PAINT) (os-render hwnd)) ;;; (cgl-window-render
(os-to-cgl-window hwnd)))
((= msg win:WM_NCLBUTTONUP) (multiple-value-bind (fv fh)
(floor lparam 65536)
(setf *hwxy* (cons fh fv)))
(win:InvalidateRect hwnd (make-null-pointer 'win:rect) 1))
((= msg win:WM_LBUTTONDOWN) (print '(bingo lbutton!!!!!!!!!!!!!!!))
(multiple-value-bind (fv fh)
(floor lparam 65536)
(setf *hwxy* (cons fh fv))))
;; #+console ((= msg wm-destroy) (win:PostQuitMessage 0) 0)
(t (print `(unknown msg ,msg ,wparam ,lparam))
(win:DefWindowProc hwnd msg wparam lparam))))
The debug output shows all the NC messages sailing by, no client
messages. I am thinking something about maybe the class definition says
"no client", or I am leaving out some enabling SetXyz api call.
Again, GetClientRect shows a nice (nearly) 640x480 rectangle.
TIA.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
"Kenny Tilton" <·······@nyc.rr.com> wrote in message
·····················@nyc.rr.com...
> My first attempt ever at a win32 app (with mostly borrowed sample
code)
> has one tiny little problem: no client messages, just NC non-client
> messages. GetClientRect shows a nice fat client rect (minus small
> amounts for non-client areas like the frame and caption.
>
Sorry if this is over-simplistic, but you did say this was your first
win32 app and the terminology can be confusing at first.
Are you sure you are clicking in the client area? Click in the center
of the window, not the title bar or the border.
Darren Abbott wrote:
> Sorry if this is over-simplistic, but you did say this was your first
> win32 app and the terminology can be confusing at first.
No problem. I cannot be underestimated!
>
> Are you sure you are clicking in the client area? Click in the center
> of the window, not the title bar or the border.
Yes, I am in the client area. I run similar sample code in a different
Lisp and all is well.
Here's a fun clue: clicking in the title bar works funny. My favorite
symptom: clicking about an inch to the left of the minimize, maximize,
and close icons causes the minimize icon to hilite/unhilite as clicked!
But it does not work, and clicking directly on any of the three is a no-OP.
Another thing: I went ahead and processed the WM_NCLBUTTONUP message,
moving my "hello world" TextOut to the place clicked. Kinda. The text
moves around, but ends up an inch or so to the right and below of where
I clicked.
Since Lisps vary in how they talk to C, I am thinking now that either on
the way into my wndproc (more likely since that is where I set the
next-text-out global) I am getting bad info which I then pass along to
DefWindowProc (probably screwing it up further).
Nice to have some leads to chase down, and your post just made the light
go on, tho I noticed all this hours ago. Doh!
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Kenny Tilton <·······@nyc.rr.com> wrote:
| My first attempt ever at a win32 app (with mostly borrowed sample
| code) has one tiny little problem: no client messages, just NC non-
| client messages. GetClientRect shows a nice fat client rect (minus
| small amounts for non-client areas like the frame and caption.
When you handle the non-client mouse messages, do you pass them to
DefWindowProc (you should do)? I can't read Lisp so I can't tell for myself.
--
Tim Robinson, MVP (Windows SDK)
Tim Robinson wrote:
> Kenny Tilton <·······@nyc.rr.com> wrote:
> | My first attempt ever at a win32 app (with mostly borrowed sample
> | code) has one tiny little problem: no client messages, just NC non-
> | client messages. GetClientRect shows a nice fat client rect (minus
> | small amounts for non-client areas like the frame and caption.
>
> When you handle the non-client mouse messages, do you pass them to
> DefWindowProc (you should do)? I can't read Lisp so I can't tell for myself.
Yes, thx, that was something I was worried about. But I have a print
diagnostic right before the call to DefWindowProc so I have some
confidence those are getting in there.
I /do/ get a WM_PAINT, btw, so maybe my report that I get no client
messages at all is misleading? I say that cuz there is a WM_NCPAINT
message. Hmmm.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Kenny Tilton <·······@nyc.rr.com> wrote:
| Yes, thx, that was something I was worried about. But I have a print
| diagnostic right before the call to DefWindowProc so I have some
| confidence those are getting in there.
|
| I /do/ get a WM_PAINT, btw, so maybe my report that I get no client
| messages at all is misleading? I say that cuz there is a WM_NCPAINT
| message. Hmmm.
OK, so it looks like there's some other problem with your code. Unless
there's a Lisp expert reading c.o.m-w.p.win32, you're better off translating
your code to C or sticking with comp.lang.lisp.
--
Tim Robinson, MVP (Windows SDK)
I don't have time today to play with your code but the first thing that
pops out for me is your (lack of) return values in the wndproc. Ensure
you return zero's when you've handled a message.
Jeff
Hey, Jeff. You probably recognize your code. Works fine on LW, but by
the time I got thru mangling it switching to UFFI and ACL I lost the
client messages. Right now I am trying to break that into two steps:
first get it working UFFI-ized but still LW, then go for ACL. Might just
work if I introduced a dumb mistake.
Jeff Caldwell wrote:
> I don't have time today to play with your code but the first thing that
> pops out for me is your (lack of) return values in the wndproc. Ensure
> you return zero's when you've handled a message.
Oh. That explains the zero I took out. :) Not like me, actually. I
usually figure things are there for a good reason, especially a zero
just sitting there. Damn. and I have been occasionally worrying about
that. I'll get that back in there, maybe I am telling Win32 I handled an
NC message so it never gets converted to a client message.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Kenny Tilton wrote:
>
> Hey, Jeff. You probably recognize your code. Works fine on LW, but by
> the time I got thru mangling it switching to UFFI and ACL I lost the
> client messages. Right now I am trying to break that into two steps:
> first get it working UFFI-ized but still LW, then go for ACL. Might just
> work if I introduced a dumb mistake.
>
> Jeff Caldwell wrote:
> > I don't have time today to play with your code but the first thing that
> > pops out for me is your (lack of) return values in the wndproc. Ensure
> > you return zero's when you've handled a message.
>
> Oh. That explains the zero I took out. :) Not like me, actually. I
> usually figure things are there for a good reason, especially a zero
> just sitting there. Damn. and I have been occasionally worrying about
> that. I'll get that back in there, maybe I am telling Win32 I handled an
> NC message so it never gets converted to a client message.
>
> --
>
> kenny tilton
> clinisys, inc
> http://www.tilton-technology.com/
> ---------------------------------------------------------------
> "Cells let us walk, talk, think, make love and realize
> the bath water is cold." -- Lorraine Lee Cudmore
Actually, you should return the following:
- if you pass the messsage to DefWindowProc(), return the result from
DefWindowProc()
- otherwise, return a value consistant with the Windows API
documentation
for the message in question. These are usually, but not always,
zero.
Norm
Jeff Caldwell <·····@yahoo.com> wrote:
>I don't have time today to play with your code but the first thing that
>pops out for me is your (lack of) return values in the wndproc. Ensure
>you return zero's when you've handled a message.
I wouldn't do that...
I'd call DefWindowProc, and return whatever it returns. i.e. in C++,
return DefWindowProc(hwnd,msg,wParam,lParam)
or in LISP, it'd be something like this:
(((())(((setq (())((( blah fun ))()() fun setq seqp))())() car())(
cadr())())())(
:)
--
Lucian
Lucian Wischik wrote:
> Jeff Caldwell <·····@yahoo.com> wrote:
>
>>I don't have time today to play with your code but the first thing that
>>pops out for me is your (lack of) return values in the wndproc. Ensure
>>you return zero's when you've handled a message.
>
>
> I wouldn't do that...
>
> I'd call DefWindowProc, and return whatever it returns.
No, I am doing that for messages I choose not to handle. But for
messages I do handle I was not returning 0.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Kenny Tilton <·······@nyc.rr.com> wrote:
>No, I am doing that for messages I choose not to handle. But for
>messages I do handle I was not returning 0.
Be careful... the tendency to return 0 if you handle it is just a
tendency, not a rule, and there are exceptions. Really, for every
single message that you handle, you should be reading the docs for it
to see what you should return. See WM_INITDIALOG for instance.
Also, the question of "handling" is a bit vague. It's just like in
object-oriented programming when you inherit from a class, and you're
never sure if you should be calling the ancestor method or not. The
tendency (again not the rule!) is that for almost all messages you can
call the ancestor method at the end of your own handling, and return
whatever the ancestor method returns. And again there are exceptions,
like WM_PAINT and WM_ERASEBKGND.
--
Lucian
"Tim Robinson" <···························@nowhere.com> wrote in message
····················@ID-103400.news.dfncis.de...
| Kenny Tilton <·······@nyc.rr.com> wrote:
| | Yes, thx, that was something I was worried about. But I have a print
| | diagnostic right before the call to DefWindowProc so I have some
| | confidence those are getting in there.
| |
| | I /do/ get a WM_PAINT, btw, so maybe my report that I get no client
| | messages at all is misleading? I say that cuz there is a WM_NCPAINT
| | message. Hmmm.
|
| OK, so it looks like there's some other problem with your code. Unless
| there's a Lisp expert reading c.o.m-w.p.win32, you're better off translating
| your code to C or sticking with comp.lang.lisp.
Hehehe, when I recall some people were punning me for posting Fortran in
compwin32... ;-)
Just kidding -- the question is indeed on-topic, but Lisp is
really, uh... oh... kind of odd for an unaccustomed eye :-).
--
Jugoslav
___________
www.geocities.com/jdujic
Oops. And here is the create window:
(defun make-os-window (class-name window-name width height)
(with-cstring (cn-p class-name)
(with-cstring (wn-p window-name)
(let ((hwnd (win:createwindowex 0 cn-p wn-p
(logior ws-visible ws-overlappedwindow)
cw-usedefault cw-usedefault width height
0 0 (win:GetModuleHandle (make-null-pointer
'lpctstr)) 0)))
(when (zerop hwnd)
(error (format nil "CreateWindow failed. GetLastError is ~a"
(win:GetLastError))))
hwnd))))
kt
Kenny Tilton wrote:
> My first attempt ever at a win32 app (with mostly borrowed sample code)
> has one tiny little problem: no client messages, just NC non-client
> messages. GetClientRect shows a nice fat client rect (minus small
> amounts for non-client areas like the frame and caption.
>
> I am doing this from Lisp, and I will be exploring if this is an
> artifact of my implementations handling of events (I'll try a different
> win32 Lisp vendor). But I thought I would check here if this is a known
> newbie gaffe. Google groups did not show anything.
>
> Here is the class def:
>
> (defun register-class ()
> (macrolet ((wc-sv (slotname)
> `(get-slot-value wc-p 'wndclass ',slotname)))
> (with-cstring (cn-p *class-name*) ;;; ec bc :external-format
> *external-format*)
> (with-foreign-object (wc-p 'win:wndclass)
> (setf (wc-sv style) (logior cs-hredraw cs-vredraw))
> (setf (wc-sv lpfnWndProc)
> (ff-register-callable 'cglwndproc))
> (setf (wc-sv cbClsExtra) 0)
> (setf (wc-sv cbWndExtra) 0)
> (setf (wc-sv hInstance)
> (win:GetModuleHandle (make-null-pointer 'lpctstr)))
> (setf (wc-sv hIcon) 0)
> (setf (wc-sv hCursor) (win:LoadCursor 0 IDC-ARROW))
> (setf (wc-sv hbrBackground) (1+ color-window))
> (setf (wc-sv lpszMenuName) 0)
> (setf (wc-sv lpszClassName) cn-p)
> (let ((rslt (win:RegisterClass wc-p)))
> (if (/= rslt 0)
> rslt
> (error (format nil "~&RegisterClass failed in reg-class.
> Error: ~a"
> (win:GetLastError)))))))))
>
> Here is the toplevel driver:
>
> (defun cl-user::test-w32 ()
> (let ((w (make-os-window *class-name* "Helloworld" 640 480)))
> (win:ShowWindow w win:SW_SHOW)
> (win:UpdateWindow w)
> (with-foreign-object (msg msg)
> (let ((msga (pointer-address msg)))
> (do ()
> ((not (win:GetMessage msga 0 0 0))
> (progn (print :bye-bye)
> (get-slot-value msga 'msg 'wParam)))
> (print `(getmess ,msga))
> (win:DispatchMessage msga))))))
>
> Here is the wndproc:
>
> (ff-defun-callable :stdcall :long cglwndproc
> ((hwnd hwnd) (msg :unsigned-long) (wparam :unsigned-long) (lparam
> :unsigned-long))
> (cond
> ((= msg win:WM_PAINT) (os-render hwnd)) ;;; (cgl-window-render
> (os-to-cgl-window hwnd)))
> ((= msg win:WM_NCLBUTTONUP) (multiple-value-bind (fv fh)
> (floor lparam 65536)
> (setf *hwxy* (cons fh fv)))
> (win:InvalidateRect hwnd (make-null-pointer 'win:rect) 1))
> ((= msg win:WM_LBUTTONDOWN) (print '(bingo lbutton!!!!!!!!!!!!!!!))
> (multiple-value-bind (fv fh)
> (floor lparam 65536)
> (setf *hwxy* (cons fh fv))))
> ;; #+console ((= msg wm-destroy) (win:PostQuitMessage 0) 0)
> (t (print `(unknown msg ,msg ,wparam ,lparam))
> (win:DefWindowProc hwnd msg wparam lparam))))
>
> The debug output shows all the NC messages sailing by, no client
> messages. I am thinking something about maybe the class definition says
> "no client", or I am leaving out some enabling SetXyz api call.
>
> Again, GetClientRect shows a nice (nearly) 640x480 rectangle.
>
> TIA.
>
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
From: Chris Double
Subject: Re: stupid newbie trick: non-client messages only
Date:
Message-ID: <uu1f3ozzr.fsf@double.co.nz>
I don't know what's causing your problems but here are a couple of
things:
> (do ()
> ((not (win:GetMessage msga 0 0 0))
> (progn (print :bye-bye)
> (get-slot-value msga 'msg 'wParam)))
> (print `(getmess ,msga))
> (win:DispatchMessage msga))))))
You don't call TranslateMessage. In my MixWin framework for Corman
Lisp I have the following as the main message loop:
(defun standard-message-loop ()
(let ((msg (ct:malloc (sizeof 'MSG))))
(do ()
((not (GetMessage msg NULL 0 0)))
(TranslateMessage msg)
(DispatchMessage msg))))
> ((= msg win:WM_PAINT) (os-render hwnd))
What does OS-RENDER do? Does it return '0' which you need to do if
WM_PAINT is processed.
> ((= msg win:WM_NCLBUTTONUP) (multiple-value-bind (fv fh)
> (floor lparam 65536)
> (setf *hwxy* (cons fh fv)))
> (win:InvalidateRect hwnd (make-null-pointer 'win:rect) 1))
Also need to return '0' if handling the message.
> (t (print `(unknown msg ,msg ,wparam ,lparam))
> (win:DefWindowProc hwnd msg wparam lparam))))
>
> Again, GetClientRect shows a nice (nearly) 640x480 rectangle.
Can you see the client area at all? Is it a white background color?
The code I use for Win32 programming in Corman Lisp is available at:
http://radio.weblogs.com/0102385/2002/06/01.html#a126
It includes support for ActiveX controls. You might be able to get
some ideas of how to handle the message loop from that.
Chris.
--
http://www.double.co.nz/cl
Chris Double wrote:
> I don't know what's causing your problems but here are a couple of
> things:
>
>
>> (do ()
>> ((not (win:GetMessage msga 0 0 0))
>> (progn (print :bye-bye)
>> (get-slot-value msga 'msg 'wParam)))
>> (print `(getmess ,msga))
>> (win:DispatchMessage msga))))))
>
>
> You don't call TranslateMessage. In my MixWin framework for Corman
> Lisp I have the following as the main message loop:
>
> (defun standard-message-loop ()
> (let ((msg (ct:malloc (sizeof 'MSG))))
> (do ()
> ((not (GetMessage msg NULL 0 0)))
> (TranslateMessage msg)
> (DispatchMessage msg))))
Done, thx. No diff, tho.
But before we sweat this too much, here is a big honking Bad Sign: it
finally dawned on me that it was not a Good Thing that the window title
shows about twenty garbage characters after the correct title. But the
corresponding taskbar tab shows the name correctly.
So in a deeper sense, nothing works. :) You know, when I look at ACL
source for Common Graphics, nothing looks easy. Always about a hundred
or two extra lines of code just to call the win32 api. otoh, ACL was
much easier to interface with FreeGlut (in C) than was LW. Go figger.
LW seems to be working. Maybe I'll try Corman next, just for a change of
scenery aggravation-wise.
>
>
>> ((= msg win:WM_PAINT) (os-render hwnd))
>
>
> What does OS-RENDER do? Does it return '0' which you need to do if
> WM_PAINT is processed.
fixed. no diff.
>
>
>
>> ((= msg win:WM_NCLBUTTONUP) (multiple-value-bind (fv fh)
>> (floor lparam 65536)
>> (setf *hwxy* (cons fh fv)))
>> (win:InvalidateRect hwnd (make-null-pointer 'win:rect) 1))
>
>
> Also need to return '0' if handling the message.
in this case my gaffe was OK since I would want the default proc to
handle this. But I take this out completely and there is no diff.
>
>
>> (t (print `(unknown msg ,msg ,wparam ,lparam))
>> (win:DefWindowProc hwnd msg wparam lparam))))
>>
>
>
>>Again, GetClientRect shows a nice (nearly) 640x480 rectangle.
>
>
> Can you see the client area at all? Is it a white background color?
Yes, and 'os-render successfuly textouts "hello world".
>
> The code I use for Win32 programming in Corman Lisp is available at:
>
> http://radio.weblogs.com/0102385/2002/06/01.html#a126
>
> It includes support for ActiveX controls. You might be able to get
> some ideas of how to handle the message loop from that.
Thx. I have poked thru your code in the past, I'll check it out again.
But that garbage in the window title has me thinking the message madness
is just one manifestation of a more general problem, or that some
runtime issue early in the sequence is messing things up for everything
that follows.
I also have very sick things going on in the title bar, such that a
click almost anywhere gets treated as a mousedown in the minimize
control. Chya. These windows are DOA, I gotta look at the window class
definition or something.
Thx for the input. I'll go look at you code now.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
From: Chris Double
Subject: Re: stupid newbie trick: non-client messages only
Date:
Message-ID: <ulm0ep6jm.fsf@double.co.nz>
Kenny Tilton <·······@nyc.rr.com> writes:
> But before we sweat this too much, here is a big honking Bad Sign:
> it finally dawned on me that it was not a Good Thing that the window
> title shows about twenty garbage characters after the correct
> title. But the corresponding taskbar tab shows the name correctly.
The calls that you use to create the window title and class name, etc
that are stored in the C structures might be something you need to
look at. For example:
(with-cstring (cn-p class-name)
(with-cstring (wn-p window-name)
(let ((hwnd (win:createwindowex 0 cn-p wn-p
(logior ws-visible ws-overlappedwindow)
cw-usedefault cw-usedefault width height
0 0 (win:GetModuleHandle (make-null-pointer 'lpctstr))
0)))
(when (zerop hwnd)
(error (format nil "CreateWindow failed. GetLastError is ~a"
(win:GetLastError))))
hwnd))))
When the function containing this code returns have the c strings been
garbage collected or deleted? Does this matter? Ditto with similar
things done in the RegisterClass function. These structures hold the
pointer to the c-string and may not work correctly if they are
subsequently deleted without its knowledge. Can you try some way of
making them visible or locked down by Lisp so they don't get freed or
moved?
What you are seeing with the title bar makes me thing something like
this may be the problem.
Chris.
--
http://www.double.co.nz/cl
Strictly in the for-what-it's-worth column, when I was getting my
Windows code up and going the first time, I had garbage (Asian character
set characters, actually) in the window title. I had to pay lots of
attention to the functionNameA or functionNameW version that I called
... the whole single-byte / double-byte character system thing. When
calling from Lisp, that's not handled as automatically as it is from
Visual C++, and a mix-up can result in a ...W function being given an
...A string.
Jeff
Chris Double wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>But before we sweat this too much, here is a big honking Bad Sign:
>>it finally dawned on me that it was not a Good Thing that the window
>>title shows about twenty garbage characters after the correct
>>title. But the corresponding taskbar tab shows the name correctly.
...
> When the function containing this code returns have the c strings been
> garbage collected or deleted? Does this matter? Ditto with similar
> things done in the RegisterClass function. These structures hold the
> pointer to the c-string and may not work correctly if they are
> subsequently deleted without its knowledge. Can you try some way of
Jeff Caldwell wrote:
> Strictly in the for-what-it's-worth column, when I was getting my
> Windows code up and going the first time, I had garbage (Asian character
> set characters, actually) in the window title. I had to pay lots of
> attention to the functionNameA or functionNameW version that I called
> ... the whole single-byte / double-byte character system thing. When
> calling from Lisp, that's not handled as automatically as it is from
> Visual C++, and a mix-up can result in a ...W function being given an
> ...A string.
Yes, last night as I considered the problem it did seem as if there was
A&W at the root. Sorry.
Having your working code to look to has been great. btw, the TextOut of
hello world was doing an extra character, the null terminus. I added:
:null-terminated-p nil
to the foreign string conversion as a cute way of getting the returned
count to be of just the displayed chars. This is Ok because TextOut (the
only use of the converted string) goes by its length argument, not the
null terminus. I could also have just subtracted one from the length. :)
This Lisp-C thing is getting interesting. Painful, frustrating, and
interesting. After porting your stuff to (a) UFFI and (b) ACL I hit a
dead end. This was surprising because ACL had spoken to FreeGlut much
more easily than LW -- but at the time I conceded LW's gripes were
valid, while yearning for ACL's Just Working without having everything
spelled out so precisely as LW was requiring.
So when I hit a dead end I split the task and tried to do just UFFI
while staying in LW. This time when LW complained it was helping me
identify FF typing issues. And I had to alter UFFI a little to get that
:unicode external format in there, and to hard-code the "W"s where FLI
had the :dbcs encoding option.
I had great hopes that back in ACL everything would now Just Work. Nah,
but I like Chris's idea of worrying about GC of these string params. As
long as I have a lead to follow I am always happy. The bad news is that
even under LW I get one extra character (the null) displaying in the
window title. grrrrrr.....
Jeez, at some point I would like to work on Cello. :) And seriously,
pretty soon if I can get just one win32 CL talking to <gasp> win32 I
might declare victory and move on, let afficionados of other CLs worry
about other CLs.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Chris Double wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>But before we sweat this too much, here is a big honking Bad Sign:
>>it finally dawned on me that it was not a Good Thing that the window
>>title shows about twenty garbage characters after the correct
>>title. But the corresponding taskbar tab shows the name correctly.
>
>
> The calls that you use to create the window title and class name, etc
> that are stored in the C structures might be something you need to
> look at. For example:
>
> (with-cstring (cn-p class-name)
> (with-cstring (wn-p window-name)
> (let ((hwnd (win:createwindowex 0 cn-p wn-p
> (logior ws-visible ws-overlappedwindow)
> cw-usedefault cw-usedefault width height
> 0 0 (win:GetModuleHandle (make-null-pointer 'lpctstr))
> 0)))
> (when (zerop hwnd)
> (error (format nil "CreateWindow failed. GetLastError is ~a"
> (win:GetLastError))))
> hwnd))))
>
> When the function containing this code returns have the c strings been
> garbage collected or deleted? Does this matter? Ditto with similar
> things done in the RegisterClass function. These structures hold the
> pointer to the c-string and may not work correctly if they are
> subsequently deleted without its knowledge. Can you try some way of
> making them visible or locked down by Lisp so they don't get freed or
> moved?
>
> What you are seeing with the title bar makes me thing something like
> this may be the problem.
I like it. I can create a window class corresponding to the os-window,
then store the converted title C string in a slot so (I'll check) it
does not get garbage-collected. thx.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore