Master RESIZE setting on Form; ancillary settings on controls?

[John Montenigro]

I've been trying to wrap my head around what it's going to take for me to make my new project fully resizeable...

From what I've been able find so far, it would appear that I have to specify in some detail which controls can be resized and which cannot.

This seems complicated, so naturally my mind tries to simplify and I find myself asking "What would be the easiest way to allow a programmer to create a project that would be fully resizeable?"

And I start to daydream: First, I envsion my Main Form having a checkbox that says: Resizeable Y/n, so I enable it.

Then as I place each control on the form, I set its "Vertical Anchor" and "Horizontal Anchor" properties to LeftEdge and TopEdge respectively. I know that if the user resizes the form, all the controls will resize automatically, except those individual controls on which I have enabled their "Restrict Resize" property. For those, the app will not allow a resize operation to shrink below values specifed in properties such as MinHt, and MinWdth...

Assuming that the Form is an object and its controls are "inherited"... does this kind of scenario seem reasonable? Would it be difficult to implement?

How far from reality have I strayed?   

-JohnM

[Roger Garstang]

Pretty much how I did it in another application although manual.  Either with a future FF implementation or on your own it wouldn't be too hard to setup an array of types holding hWnd and the values you mentioned (Although I'd have Top/Bottom/Left/Right) then parsing the array in WM_SIZE and adjusting the positions depending on the values stored. Visual Studio has all the settings you mentioned and stretching and docking, etc.  It would be much easier for FF to do it of course, but anything is possible.  Those using PBForms and DDT have to do it all the time.  It is one of the biggest drawbacks compared to other languages/IDEs, but not too hard to overcome.  Another thing to also think about are Min/Max window sizes too that you have to process in WM_GETMINMAXINFO so things don't get too out of hand.  Controls would also need some type of margin around them and min/max sizes too.  To not get too complicated FF would calculate the min form size from all the controls min sizes, margins, and spacing and set it for WM_GETMINMAXINFO so controls don't overlap...that way there is no need for dynamic positioning and adjusting for other controls overlapping or bumping during the WM_SIZE since it will be restricted.

[Jean-pierre Leroy]

John, Roger,

I don't know if you have already seen this post from Carlo Pagani in the PB Forum.

http://www.powerbasic.com/support/pbforums/showthread.php?t=23434

His demo program is very informative.

But a function (or attributes in FF3) to reproduce exactly what he has done could be a good addition to FF3 !

Jean-Pierre

[Roger Garstang]

Yeah, I've seen a couple of those.  In FF I'd picture properties containing 4 check boxes for Top/Bottom/Left/Right, Margin and Min/Max X and Y for each control.  I think that would get all that is needed and what's in that example...although what is meant by Float is confusing.  In this method, Top/Left alone really would mean nothing (Same as none being checked).  Right/Bottom would move the control with those edges.  Top+Bottom anchors both and stretches vertical. Left+Right anchors both and stretches horizontal.  Min/Max will determine how far.  To Center- Position control centered, set Min/Max to be the same and anchor both/all sides...although this may be something to set max size of window at too, but then you have to worry about people having Maximize style set and you get a maximized window that doesn't go full screen, so usually I only set min window size.

Probably still some tweaking, and with just about all examples I've seen you can mess them up if setting things wrong like left anchor two controls by each other and set one on left to grow and it will expand into the right control, min/max values set wrong, etc.

You could also use new Tag values to make a string of your binary representation of your structure and store it in the control, or put your own comma delimited values that you can parse.  Gets a little complex though.  The FF internal Pointer could be used if it stored the positions and size of the controls...which is probably what would be needed once implemented.

[Gary Stout]

I am not a user of RealBasic, but I have downloaded and tested the trial version, but it makes resizing very simple by allowing the user (programmer) to set 4 checkboxes in the properties box which will bind a control to each side of a form (top,left,right,bottom) or any combination of those. If something similar to that could be implemented, it would be....sweeeet! I have already mentioned this to Paul back near the beginning of FF 3.0 release, so it may already be on the wishlist.

Gary

[Paul Squires]

Yes, the automatic resizing stuff is on the wishlist.... I was sent resizing code by a few people. I just need time to digest it all and see how to best implement it into the program.

[Douglas McDonald]

Yes !!!!!!!!!!! resize would be wonderful, very very wonderful

Doug

[Marc van Cauwenberghe]

I think this must be the feature with the most votes at the moment. I would actually pay for this !!!

Marc

[Paul Squires]

Automatic control resizing has now been implemented.

Controls now have a "ResizeRules" property. When clicked, that property will display a dialog box where the user simply needs to check a few checkboxes to indicate how they want the control to resize during runtime.

The whole process is extremely easy and it is amazing how simple it is to now write automatic resizing forms without any code whatsoever. Combine this with the previous implemented new feature of MinWidth/MinHeight/MaxWidth/MaxHeight properties for Forms and you now have a very powerful and easy to use resizing system.

The new features will be in v3.07.

[Douglas McDonald]

Paul you've outdone your self, this will be a great addition THANK YOU

Doug

[Gary Stout]

I second that!!!

Gary

[Marc van Cauwenberghe]

Dear Paul,

This will really make my year. Thank you very much.

Very best regards,
Marc

[Jean-pierre Leroy]

Paul,

It is a very good news ... can you post a screen shot of the "ResizeRules" property?

So we can think about these resizing functionality before you release 1.07.

Thank you so much.
Jean-Pierre

[Martin Francom]

Excellent, Paul.     
   Have you tested it with the FireSplitter Control,  where three or more forms need to be dealt simultaneously?

[Roger Garstang]

Cool addition! I would hope since the splitter(or even a Tab Control) has each section as a form it would all be somewhat dynamic like in VS when you have a Tab Control set to resize it automatically positions its internal controls too.  First thing that came to my mind was Up/Down controls.  There is already the issue where an extra call to Set Window POS at the end of each control creation in CodeGen causes problems with them buddying with controls.  May need to test what happens to them when their buddy control moves too and if they need to move in sync, if they move automatically when buddy moves since they somewhat subclass, or if a SetBuddy call would reposition them...whichever works best.