Jump to content

Frame overhead


steved

Recommended Posts

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.)

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...