Frame overhead

[steved]

If creating a frame with a border and suchlike, the size of this 'overhead' reduces the available window area. It would be useful to know the size of this overhead in advance of creating the window, to facilitate the creation of a window with a client area of a given size. At present I've hardcoded the adjustments, but it would obviously be preferable to determine these adjustments programatically, in advance of creating the frame.

Number of ways of doing this; how about something like:

bool_t gwinFrameAdjust(GWidgetInit *pInit, uint32_t flags);

This could update the width and height values in the GWidgetInit structure to reflect the flags.

[inmarket]

Internally we do something like this already. It should be simple to export this in some form.

I think when you specify a size on creation of the frame you

are specifying the internal size. I will need to double check this.

[Joel Bodenmann]

I'm not sure if I understand you correctly here. Do you want to get the actual size of the "client window area" that is now left? In that case, the thing you want is already there: gwinGetInnerWidth() and gwinGetInnerHeight() which are available for containers (like the frame widget).

Or am I completely misunderstanding you here and you want to specify the width and height of the client window and extend the borders and stuff from the parent widget to the outside in order not to decrease the width and height of the client window area?

~ Tectu

[steved]

Or am I completely misunderstanding you here and you want to specify the width and height of the client window and extend the borders and stuff from the parent widget to the outside in order not to decrease the width and height of the client window area?

~ Tectu

Its that option - I know the required size of the client window, so need a generic method to set the correct overall window size (which obviously has to happen before the window is created).

[inmarket]

I thought creating the window you specify the internal size already but I might be wrong about that.

If not, in the interim you can create the window invisible, get its internal size and then resize the window (now supported but not well tested) before making it visible.

Later I will look at what is required to return border sizes etc.

Note the above method is the defined/preferred way of doing it under win32

[steved]

I thought creating the window you specify the internal size already but I might be wrong about that.

Unless its well buried, looks like the passed parameters determine the overall window size.

The 'raw' border information is already available through the VMT (type gcontainerVMT), which supports methods to return the width of each of the four borders. So its really a matter of how this information should be made accessible. (I imagine one could access the VMT routines directly, and do the relevant calculations, but I feel its a method that should be embedded in the container class to ensure the flags are handled correctly, and to allow for future possibilities.)

[inmarket]

Yes that is exactly what will happen when I get round to creating those functions. The vmt routines will be exported to proper api calls.

In the mean time the method described in the above post will always allow the border sizes to be determined.