Re: WinCon.DLL; nested structures

Doug,

>Are some Win32 constants not defined in WinCon.DLL ..? I had trouble using
>some functions, namely ScrollWindow and ScrollWindowEx.

We could never define all of them! However, your question is mixing two
concepts: constants and api calls. Both ScrollWindow and ScrollWindowEx
are api calls, which SwiftForth does not pre-define. It is simple to
define an api call:

Function: ScrollWindow ( hwnd dx dy 'scrollrect 'cliprect -- bool )
Function: ScrollWindowEx ( hwnd dy dy 'scrollrect 'cliprect hupd 'update flags -- n )

Note that in the use of Function: the number of blank delimited paramters on
each side of the -- is significant!

>Not all structures are defined in the kernel, and I'm kind-of new to SWOOP,
>but (according to section 10.1.4, "embedded objects") should the following
>class work properly?
>
> CLASS PAINTSTRUCT
> VARIABLE hdc
> VARIABLE fErase
> RECT BUILDS rcPaint \ ??? nested RECT Structure
> VARIABLE fRestore
> VARIABLE fIncUpdate
> 32 BUFFER: rgbReserved
> END-CLASS
>PAINTSTRUCT BUILDS ps.

This is perfectly valid.

>Furthermore, in the C code it was not obvious why I even need to declare
>a PAINTSTRUCT, as long as I use a buffer big enough to hold the device
>context -- is this just some common sense finally creeping up on me..?

This is also a valid conclusion. I very often use PAD or HERE as that
temporary buffer. In a callback, which is the only place one would need
to reference this structure, PAD and HERE are both valid and guaranteed
*not* to be unique and free for use.

Rick
Received on Mon Dec 11 2000 - 07:43:13 PST