Chilforms on an another form without tabview

[Petrus Vorster]

I want in FB to let childforms appear on the main form without the use of a tabcontrol.
We once did this in Powerbasic here on the Firefly forum.
I remember we had issues with scaling when the main form re-sizes.(And we used And Afxscale.....from Josè)
This form wont re-size.
I assume the coding will be somewhat different in Freebasic to make that happen?

[Paul Squires]

Not really. The coding concepts are the same. You just create a form with WS_CHILD set and display it as non-modal with the parent form set correctly. I use child forms all the time. You are correct that child forms do not respond to the auto sizing that other child controls do.

[Petrus Vorster]

Something very interesting....
If i call the form2 as a childform, it loads correctly, but the buttons on the parent form appears ABOVE the childform...

[Paul Squires]

Something very interesting....
If i call the form2 as a childform, it loads correctly, but the buttons on the parent form appears ABOVE the childform...

Yes, most likely because Windows is treating the child form just like any other child control. In Windows, there is not much distinction between "Forms" and "Controls", everything is just "windows" that happen to be WS_CHILD or top-level windows.

[Petrus Vorster]

Ok, then how would we fix this?
Perhaps a a simple hide_controls on the main form first, then load the child-Form, and
again turn them visible again when the childform unloads?

[Paul Squires]

I would create two child forms. Put the controls from the main form on one child form and whatever other controls you want on the second form. Uncheck the WS_VISIBLE style for both child forms. In the WM_CREATE for your main form, load both child forms. In the WM_SIZE handler for the main form resize and show whatever child form you want displayed.

[Petrus Vorster]

Ohhh. I see you use the Wm_size?
So its not a good idea to FF_closeform one, then load the other?
I was wondering why i was getting weird reactions sometimes.

[Petrus Vorster]

Cool, works like a charm....Thanks!

[Petrus Vorster]

I have recently revisited this post and is still intrigued by this function, but somewhere along the lines I got something wrong.
I love using the Tabview to enable multiple pages on one form since it doesn't require much to re size anything when the main form re-sizes.
Oh, but i HATE those tabs on top, and even making them so small that you can see only a thin little line, it still annoys me greatly.

I can easily place the chilforms and re size them to make it appear as one page, but i am finding it hard to let the childform autosize to the main one.

So basically, i need to mimic the exact functionality of a tabview, but without it.
Especially if i have listviews on those childfrms, so that the entire project can have a sleek, clean look and function.

If anyone is still in the mood to help me revisit what was probably explained numerous times before, i will be much obliged.

[David Kenny]

Peter,

The demo I am attaching does what I think you are asking for.  Let me know if I'm off base.
I am using FF for PowerBasic but it should work the same for FreeBasic.

The process:
Design the forms non-child controls first. (Only the two command buttons in my demo)
Add child form 1 controls next
   Place them where they will go.
   Manually edit the a Tag properties for each child control to something like "1,100,150" 
      1 = child form 1
      100 is copied from the 'Left' property
      150 is copied from the 'Top' Property
Now that you have the child form# and the x,y location of the control, you can drag the child controls to
   a single pile to make room for designing the next child form.         
Now, design the remaining child forms the same way.

In the Create function:
   Pass the handle of each child control to RegChildCtrl
   Call SetCFVisible to set the intial ChildForm

Call SetCFVisible as needed to change which ChildForm is visible

You will see the controls all follow their design-time resizing rules.

David

[Petrus Vorster]

Thanks David.

Once again you come to my rescue.
Nice little module you have there!
It gives great ease to the form handling and re-seizing.
I will most definitely give credit to you in the app.
This is for sure going into all future apps.

[Petrus Vorster]

David, so this just runs everything on one form, hides the controls you dont want and makes those others available you do?
To what size project have you used this? I have a project that uses about 7 Tab views and quite a number of controls.
How do you manage the layouts of such a number of controls?
It works pretty cool, but i am wondering how you keep everything together in a large project?

[David Kenny]

> so this just runs everything on one form, hides the controls you dont want and makes those others available you do?
Yes, all controls are always on the form.

> To what size project have you used this?
Small. Three to four child forms.

> I have a project that uses about 7 Tab views and quite a number of controls.
That won't be a problem if you don't change the design often.

> How do you manage the layouts of such a number of controls?
I design each child form one at a time of course. When one is complete, I type the Tag info (ChildFormNo, LeftPos, RightPos) into the Tag property and drag the control to a convenient location out of the way (for each child control). I will drag the parent form larger than normal and put each childform's controls into a pile that will be "off screen" when I put the the parent back to it's actual design size.

If you need to add a control and/or just move the controls around, click on them one at a time (in the pile) and type the Tag info back into the Left and Top properties.  The control will assume it's designed position on the parent.  Once you have done that, move them around, add some, whatever you need to change. When finished, you will need to modify the Tag property to reflect the new Left and Top values. When done modifying Tag properties on the childform, you can leave it there if you have no other childforms to redesign, or re-pile them off to the side so you can work on the next one.

> i am wondering how you keep everything together in a large project?
First, always give the control a name that indicates its Child group.  I failed to demonstrate this in my demo.  Lets use Label1 as an example.  Label1 could have been CF1_Lbl1 (use your normal naming convention), but add a prefix or suffix.  My prefix CF1_ is short for ChildForm1.  Using the FF Project Properties dialog as an example, the Project Name Textbox could be Gen_ProjNameTxtbx indicating that this control is part of the General childform.

I group the childform FF routines to together in the Parent form's .inc file.  For example, I double-click on CF2_Option1 and FF creates a function called FORM1_CF2_OPTION1_BN_CLICKED (if it didn't exist) and I move it to be with the other Form1_CF2_ routines.

****
FF could automate this process of course, but frankly I thought nobody else would find this useful and never asked for it on the wishlist.
You should be able to  move groups of source code out of the forms .inc, into a module named appropriately (Form1_ChildForm1.inc as a crude example), if your form.inc gets too big.  I haven't needed to do that yet.  You will loose the ability for FF to take you directly to the FORM1_CF2_OPTION1_BN_CLICKED routine when you click on the CF2_Option1 control in design view, however.

[Petrus Vorster]

Very interesting approach.
This does make sense now.
It would be nice if one could design a "container" for a group of controls and then just move the containers around or hide them, encapsulating the method you have demonstrated.
That would be useful indeed. Imagine  having a simple rectangle you place on your form with the normal size/re-size etc functions, but then allow it to contain other controls like on a form. disable group 1...etc, hide group 2, show group 3 and they all size and resize easily.

You are such a wizz with this, it wouldn't be a problem for you to throw this code together with a control like that... 

[David Kenny]

> You are such a wizz with this, it wouldn't be a problem for you to throw this code together with a control like that...
Describe something that happens at run-time and I will consider it.  Anything that happens at design time, has to be done in FF.

Since FF FB is still in development you can try asking Paul to add it in. 

I have quite a bit experience with various Hide/Show/Disable techniques and applications.  On fairly complex forms, I will employ a routine that gets called every time any control gets input and evaluates what other controls might be effected by the input.  It might then disable or hide a control because a condition was met that was mutually exclusive to the control.  Simple examples: Six controls must contain validated data, or be disabled, for the Save button to be active. If checkbox 2 is checked, then Option buttons 1,5, and 6 need to be disabled. The option buttons that were disabled in the last example could have been hidden, and the remaining controls moved to close the gaps.