nanogui: Thread: Length of Window extra bytes.

Hi,

I am writing a wrapper for C++ to ease the development of a C++ program.
I would like to place the object pointer for the object which owns the
hwnd handle into the window structure to allow a fast fetch of it given
a hwnd using GetWindowLong ().

I would like to use the extra data in the window structure and
specifically the end of the extra bytes. For this I need the length of
the extra bytes. Can I get it from a function or can I add a macro ?

eg:

#define GetExtraBytesLen(hwnd) ((int)(hwnd)->nextrabytes)

Regards

ps: I have implemented support for the OS's number of fd's. You can also
select on read, write and except.

-- 
 Chris Johns, ####@####.####

: I would like to use the extra data in the window structure and
: specifically the end of the extra bytes. For this I need the length of
: the extra bytes. Can I get it from a function or can I add a macro ?
: 
: eg:
: 
: #define GetExtraBytesLen(hwnd) ((int)(hwnd)->nextrabytes)

Chris - The doc'd API way to do this is thru GetClassInfo, but
that's not implemented yet.  You can use your macro, but,
remember that the extra bytes are always allocated at window
create time, so it doesn't really matter where in the extra bytes
you store your data, since it's a fixed size.




: 
: ps: I have implemented support for the OS's number of fd's. You can also
: select on read, write and except.

Send your changes if you want them integrated  ;-)

Regards,

Greg

Greg Haerr wrote:
> 
> : I would like to use the extra data in the window structure and
> : specifically the end of the extra bytes. For this I need the length of
> : the extra bytes. Can I get it from a function or can I add a macro ?
> :
> : eg:
> :
> : #define GetExtraBytesLen(hwnd) ((int)(hwnd)->nextrabytes)
> 
> Chris - The doc'd API way to do this is thru GetClassInfo, but
> that's not implemented yet.  

I see meantion of the API specification, how-ever I do not see where I
can download a copy. Is a copy online ?

> You can use your macro, but,
> remember that the extra bytes are always allocated at window
> create time, so it doesn't really matter where in the extra bytes
> you store your data, since it's a fixed size.
> 

I suspect I cannot use the extra bytes for storing the object pointer as
a SendMessage occurs and the object pointer is not loaded into the
window structure when this occurs.

I added the "LPVOID lpParam" to the `struct hwnd' and set it. I also
added a macro to access it.

> :
> : ps: I have implemented support for the OS's number of fd's. You can also
> : select on read, write and except.
> 
> Send your changes if you want them integrated  ;-)
> 

I intend to, how-ever I suspect you would like them tested :)

-- 
 Chris Johns, ####@####.####

: I suspect I cannot use the extra bytes for storing the object pointer as
: a SendMessage occurs and the object pointer is not loaded into the
: window structure when this occurs.
: 
: I added the "LPVOID lpParam" to the `struct hwnd' and set it. I also
: added a macro to access it.
: 

No, the extra bytes are just bytes adjacent to the struct hwnd.  You don't
want to add another element to struct hwnd, or every window takes
up extra space.  The proper way is to fill out the cbWndExtra field
with as follows:

	wc.cbWndExtra = sizeof(LPVOID);

before calling RegisterClass().  Then, in the window procedure
for that class, under WM_CREATE:
	
	SetWindowLong(hwnd, 0, your_lpvoid);

You can then always access this value with:
	
	pvoid = (LPVOID)GetWindowLong(hwnd, 0);

As I check the source, you'll need to write SetWindowLong
yourself, use microwin/src/mwin/winuser.c's SetWindowWord
as a base, and return a *(LONG *) rather than *(WORD *)...



Regards,

Greg

Greg Haerr wrote:
> 
> : I suspect I cannot use the extra bytes for storing the object pointer as
> : a SendMessage occurs and the object pointer is not loaded into the
> : window structure when this occurs.
> :
> : I added the "LPVOID lpParam" to the `struct hwnd' and set it. I also
> : added a macro to access it.
> :
> 
> No, the extra bytes are just bytes adjacent to the struct hwnd.  You don't
> want to add another element to struct hwnd, or every window takes
> up extra space.  The proper way is to fill out the cbWndExtra field
> with as follows:
> 
>         wc.cbWndExtra = sizeof(LPVOID);
> 
> before calling RegisterClass().  Then, in the window procedure
> for that class, under WM_CREATE:
> 
>         SetWindowLong(hwnd, 0, your_lpvoid);
> 
> You can then always access this value with:
> 
>         pvoid = (LPVOID)GetWindowLong(hwnd, 0);
> 
> As I check the source, you'll need to write SetWindowLong
> yourself, use microwin/src/mwin/winuser.c's SetWindowWord
> as a base, and return a *(LONG *) rather than *(WORD *)...
> 

Oh. I assumed that the `lpParam' was just not implemented and was to be
implemented. What is the purpose of the `lpParam' parameter when
creating a window ?

I cannot use the WM_CREATE message as I do not yet know the relationship
between the C++ object and hwnd when my WndProc function is called
(assuming synchronous message sends).

I have a single `WndProc' function for all windows created using a
window class created with the WindowClass class (blah, too many
classes). In my common WndProc function I need to obtain the object
pointer so I can call a virtual method `HandleMessage'. This is my per
window object WndProc function.

I see in the demo code the `HMENU' window create parameter is really an
`id' and it is used to handle different windows from within a common
WndProc function. I would use `id' how-ever is only an `int' and I
cannot assume the size of int is large enough for a pointer.

-- 
 Chris Johns, ####@####.####

: Oh. I assumed that the `lpParam' was just not implemented and was to be
: implemented. What is the purpose of the `lpParam' parameter when
: creating a window ?
: 

No, the lpParam parameter to CreateWindowEx is passed as a member
of the CREATESTRUCT structure to the WM_CREATE message, as
are all of parameters to CreateWindowEx.  It's only purpose is to provide
a user-defined parameter from CreateWindowEx to the WM_CREATE
handler.  It is not stored in the window structure.  The application must
save it in window or class extra bytes if required later.



: I cannot use the WM_CREATE message as I do not yet know the relationship
: between the C++ object and hwnd when my WndProc function is called
: (assuming synchronous message sends).

That's OK.  When you do know the relationship, call

	SetWindowLong(hwnd, 0, objectptr);

Then it will be stored with the hwnd.


: 
: I have a single `WndProc' function for all windows created using a
: window class created with the WindowClass class (blah, too many
: classes). In my common WndProc function I need to obtain the object
: pointer so I can call a virtual method `HandleMessage'. This is my per
: window object WndProc function.

Yep, get it with a call to:

	GetWindowLong(hwnd, 0);


: 
: I see in the demo code the `HMENU' window create parameter is really an
: `id' and it is used to handle different windows from within a common
: WndProc function. I would use `id' how-ever is only an `int' and I
: cannot assume the size of int is large enough for a pointer.

You're right.  The hMenu parm is used as an ID for child windows, and
as a menu handle for top level windows.  The correct answer is where
you started: use extra window bytes.  Remember, if the window class
sets the cbWndExtra value non-zero, that many bytes will be allocated
at CreateWindow time.  You can set/get the value anytime afterwards...

Greg

Greg Haerr wrote:
> 
> : Oh. I assumed that the `lpParam' was just not implemented and was to be
> : implemented. What is the purpose of the `lpParam' parameter when
> : creating a window ?
> :
> 
> No, the lpParam parameter to CreateWindowEx is passed as a member
> of the CREATESTRUCT structure to the WM_CREATE message, as
> are all of parameters to CreateWindowEx.  It's only purpose is to provide
> a user-defined parameter from CreateWindowEx to the WM_CREATE
> handler.  It is not stored in the window structure.  The application must
> save it in window or class extra bytes if required later.
> 

Sure. I have no problem with this model. I am now wondering why the
lpParam to CreateWindowEx exists ?

> : I cannot use the WM_CREATE message as I do not yet know the relationship
> : between the C++ object and hwnd when my WndProc function is called
> : (assuming synchronous message sends).
> 
> That's OK.  When you do know the relationship, call
> 
>         SetWindowLong(hwnd, 0, objectptr);
> 
> Then it will be stored with the hwnd.
> 

I will use the create structure to handle this now I know it exists and
understand it.

> :
> : I have a single `WndProc' function for all windows created using a
> : window class created with the WindowClass class (blah, too many
> : classes). In my common WndProc function I need to obtain the object
> : pointer so I can call a virtual method `HandleMessage'. This is my per
> : window object WndProc function.
> 
> Yep, get it with a call to:
> 
>         GetWindowLong(hwnd, 0);
> 

Agreed. I would like the pointer to be at the end hidden from the user
which might also allocate bytes. They would own 0 to the length they
set.

> :
> : I see in the demo code the `HMENU' window create parameter is really an
> : `id' and it is used to handle different windows from within a common
> : WndProc function. I would use `id' how-ever is only an `int' and I
> : cannot assume the size of int is large enough for a pointer.
> 
> You're right.  The hMenu parm is used as an ID for child windows, and
> as a menu handle for top level windows.  The correct answer is where
> you started: use extra window bytes.  Remember, if the window class
> sets the cbWndExtra value non-zero, that many bytes will be allocated
> at CreateWindow time.  You can set/get the value anytime afterwards...
> 

It is the best solution as the C interface is not altered. I do need to
be able to get the length of the extra bytes. This allows me to place
the object pointer at the end of the extra bytes allowing the user to
allocate extra bytes they might need.

To make sure I understand this I will outline what I will do :

 In `class WindowClass' I add sizeof (class Window*) to 
 the extra bytes supplied by the user. The user of 
 `class Window' must use a window class created by 
 the WindowClass class.

 When creating a window fill in a CREATESTRUCT and pass in 
 the first parameter of the CreateWindowEx function.

 Filter the WM_CREATE and take the object pointer from
 the CREATESTRUCT and set in the extra bytes.

 Use the extra bytes to get the object pointer.

This makes the only change I need the macro I posted earlier plus the
code to set a long word.


-- 
 Chris Johns, ####@####.####

: To make sure I understand this I will outline what I will do :
: 
:  In `class WindowClass' I add sizeof (class Window*) to 
:  the extra bytes supplied by the user. The user of 
:  `class Window' must use a window class created by 
:  the WindowClass class.
: 
:  When creating a window fill in a CREATESTRUCT and pass in 
:  the first parameter of the CreateWindowEx function.
: 
:  Filter the WM_CREATE and take the object pointer from
:  the CREATESTRUCT and set in the extra bytes.
: 
:  Use the extra bytes to get the object pointer.
: 
: This makes the only change I need the macro I posted earlier plus the
: code to set a long word.

You only need the code to set a long word.  Your
earlier macro gets the length of extra bytes, it's not needed.

Greg

Greg Haerr wrote:
> 
> : To make sure I understand this I will outline what I will do :
> :
> :  In `class WindowClass' I add sizeof (class Window*) to
> :  the extra bytes supplied by the user. The user of
> :  `class Window' must use a window class created by
> :  the WindowClass class.
> :
> :  When creating a window fill in a CREATESTRUCT and pass in
> :  the first parameter of the CreateWindowEx function.
> :
> :  Filter the WM_CREATE and take the object pointer from
> :  the CREATESTRUCT and set in the extra bytes.
> :
> :  Use the extra bytes to get the object pointer.
> :
> : This makes the only change I need the macro I posted earlier plus the
> : code to set a long word.
> 
> You only need the code to set a long word.  Your
> earlier macro gets the length of extra bytes, it's not needed.
> 

Yes you are correct. Sorry about that.

I have also noticed that the header files are not protected against C++.
Should I add the:

extern "C"
{

};

etc to the header files ?

-- 
 Chris Johns, ####@####.####

Greg Haerr wrote:
> 
> Chris - The doc'd API way to do this is thru GetClassInfo, but
> that's not implemented yet.  You can use your macro, but,
> remember that the extra bytes are always allocated at window
> create time, so it doesn't really matter where in the extra bytes
> you store your data, since it's a fixed size.
> 

Do you mean `GetClassLong' or a new function `GetClassInfo' ?

-- 
 Chris Johns, ####@####.####