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
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.
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
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.
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
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.
Yes !!!!!!!!!!! resize would be wonderful, very very wonderful
Doug
I think this must be the feature with the most votes at the moment. I would actually pay for this !!!
Marc
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.
Paul you've outdone your self, this will be a great addition THANK YOU
Doug
I second that!!!
Gary
Dear Paul,
This will really make my year. Thank you very much.
Very best regards,
Marc
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
Excellent, Paul.
Have you tested it with the FireSplitter Control, where three or more forms need to be dealt simultaneously?
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.
Yes, the new automatic resize code handles both the FireSplitter and the standard TabControl resizing of child pages.
I haven't checked that whole buddy control thing.
Amazing, Paul! This speaks volumes about the practicality of your FF3 design framework!
Thanks - I can't wait to try it out!
-John
Say, since new features seems to be easy to add in FF3, how about this: Generate_Winning_Lottery_Ticket? ;D
Wouldn't that be FF_Generate_Winning_Lottery_Ticket()? I imagine for every thing he adds and every issue he fixes FF gets exponentially better too since he creates it with itself.
Quote from: John Montenigro on January 26, 2010, 02:23:36 AM
This speaks volumes about the practicality of your FF3 design framework!
I have to agree with you there. Since finishing FF3, I am able to add, modify, delete items to and from FireFly so much easier than I could with the older FF2 (which was written using hand coded api).
My goal is to eventually move more into documentation and help file stuff. Once that end of the product develops more then FireFly will indeed be the product that I have always envisioned it could be.
Quote from: Jean-Pierre Leroy on January 25, 2010, 12:32:01 PM
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.
Sure. The pictures are attached. As you can see, you have the choice of horizontal and/or vertical move and/or sizing. The combination of both rules determines the action taken at runtime. The whole setup of this functionality was relatively simple - I am happy that it is finally done because it has been a new feature request since way back in the FireFly 2 days.
Paul,
This addition plus the addition of being able to edit properties for multiple controls.....wooo hooo!! Can't wait til the next release. I can't imagine what else you could add to FF to make it any better, but I am sure there will be something ;)
Thanks again for all of your effort!
Gary
Please, please, please, ... Can I open my present now. :) :) :)
If 3.07 has automatically resizing capability, I will be smiling for the rest of the year !!! And it's only January.
Robert
I have re-worked the auto resize code for the upcoming 3.08 update. I am using modified code that was sent to me by Eddy Van Esch (thanks Eddy!). The new code allows total control over resizing every side of a control in either fixed or proportional sizing.
The existing options still remain (the new code has been implemented for those) but I am now adding an "Advanced" sizing option to allow the programmer full control over the resizing of all sides of the control. I am working on that new option dialog now. Unfortunately, 3.08 won't be released until it is finished. I'll probably ask a few of you to test it for me prior to uploading the update.
So is there going to be two dialogs or are you going to map the old settings to apply the advanced. Having two dialogs will be confusing if not. Something like an expanding tree that shows more options for the old summary way would be ideal. Then it would look the same but allow applying more.
Quote from: Roger Garstang on April 29, 2010, 04:08:11 PM
So is there going to be two dialogs or are you going to map the old settings to apply the advanced. Having two dialogs will be confusing if not. Something like an expanding tree that shows more options for the old summary way would be ideal. Then it would look the same but allow applying more.
hmmm....that's a good point. Right now I have two dialogs. Maybe mapping the old settings to a single dialog would be better. I'll see what i can muster up today.
I just finished moving everything to the new dialog. The existing resize settings dialog will no longer be a part of FF3. The new approach is less confusing with only one dialog rather than a "Basic" and "Advanced" dialog.
Hi Paul,
will there be any compatibility issues with projects that use the "old" resize dialog?
Quote from: Rolf Brandt on April 30, 2010, 01:17:00 PM
will there be any compatibility issues with projects that use the "old" resize dialog?
There should not be. When a form is loaded all controls are checked for the older method and they are converted automatically to the new method. It should be pretty seamless to the user. Of course, I need to test this to ensure that the conversion works as intended.
I have attached a screenshot of the new dialog. It is now fully functional and so far I am very happy with the resulting generated code.
That looks very cool Paul, I'm looking forward to tinkering with it.
Cheers,
David
Paul,
I have a question: why do you re-designed the "Resize rules" again; what were the limitations (if any) in the current implementation?
Jean-Pierre
Looks very good like the anchoring model VS.
I like the Visual Studio look. Didn't we talk about it looking that way early on?
What are the list of options that the combos have? Without seeing the choices available I couldn't tell if fixed meant in place or fixed to edge. And, do all the custom options popup a box for percent? Not sure I understand how the percent will work or be accurate with only 0-100, but we'll see when it comes out I guess...unless you let us put it through its paces before then.
Quote from: TechSupport on April 30, 2010, 04:04:20 PM
Quote from: Rolf Brandt on April 30, 2010, 01:17:00 PM
will there be any compatibility issues with projects that use the "old" resize dialog?
There should not be. When a form is loaded all controls are checked for the older method and they are converted automatically to the new method. It should be pretty seamless to the user. Of course, I need to test this to ensure that the conversion works as intended.
I have attached a screenshot of the new dialog. It is now fully functional and so far I am very happy with the resulting generated code.
Hi Paul,
I had a Egrid32, I think MLG could have been used as well on the left side that I wanted proportional sizing. With a grid which has internal columns I wanted to auto size proportionally as well. It would be great if it were possible to augment the control resizing with custom code for controls that have internal layout.
I've done a test and a WM_Size on the control is sent after the resize is complete, so the only thing required is getting the original size. It would be great if two functions were added. I assume you are storing this information to do the proportional sizing.
FF_CONTROL_GETORIGLOC
FF_CONTROL_GETORIGSIZE
The work like FF_CONTROL_GETLOC and FF_CONTROLGETSIZE accept return the original sizes at startup.
Thanks,
Brian
Hi Brian,
Couldn't you achieve the same effect by saving the control's size in a global rect during WM_CREATE for the Form?
Global gGridRect As Rect
'--------------------------------------------------------------------------------
Function FORM1_WM_CREATE ( _
hWndForm As Dword, _ ' handle of Form
ByVal UserData As Long _ ' optional user defined Long value
) As Long
' Get the control's size and position based on screen positioning
GetWindowRect HWND_FORM1_GRID1, gGridRect
' Convert from screen positioning to relative to the control's parent form
MapWindowPoints %HWND_DESKTOP, HWND_FORM1, gGridRect, 2
? Str$(gGridRect.nLeft) & _
Str$(gGridRect.nTop) & _
Str$(gGridRect.nRight) & _
Str$(gGridRect.nBottom)
End Function