Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Position form in another form when radio clicked

TheLazyPig

Programmer
Sep 26, 2019
96
PH
Hi!

Can I position my form (frmchecks.scx) to appear inside another form (branch.scx) when the radio button is clicked? It works when I change the Top and Left but if I do this will it stay in the position even if the device changes?

branch_fp9.png checks_fp9.png<-- changes depend on the radio button

frmchecks.scx should be in the yellow square below.

branch2_fp9.png

Thanks for the replies. :)
 
Hello,

why not put the content of form frmchecks inside a container and put in mainform and make it visible .t. / .f. depending on radio buttons ?
If it has own buttons, disbale maiform buttons/controls if container is visible

What do you mean with "device changes" ? Moving mainform to other screen with different resolution ?
 
Hi!
Can I position my form (frmchecks.scx) to appear inside another form (branch.scx) when the radio button is clicked? It works when I change the Top and Left but if I do this will it stay in the position even if the device changes?
View attachment 1523 View attachment 1524<-- changes depend on the radio button
frmchecks.scx should be in the yellow square below.
View attachment 1525
Thanks for the replies. :)
Yes, it's possibly, but how as Tom... Why?!?

PUBLIC m.poFormMain, m.poFormChild


m.poFormMain=CREATEOBJECT("_formMain")
m.poFormMain.Name="MAINFORM"
m.poFormChild=CREATEOBJECT("_formChild")
m.poFormChild.Name="CHILDFORM"

SHOW WINDOW ("CHILDFORM") IN WINDOW ("MAINFORM")

m.poFormChild.ChangePosByParent(m.poFormMain)


m.poFormMain.Visible=.T.
susp

DEFINE CLASS _formMain AS FORM
Name="_formMain"
Height=500
Width=500

PROCEDURE Resize
m.poFormChild.ChangePosByParent(m.poFormMain)
ENDPROC

ENDDEFINE


DEFINE CLASS _formChild AS FORM
Name="_formChild"
Height=250
Width=500

PROCEDURE Init
This.AddObject("Label1","Label")
This.Label1.Caption="Child form"
This.Label1.Visible=.T.
ENDPROC

PROCEDURE ChangePosByParent
LPARAMETERS m.loForm
This.Move(0, m.loForm.Height/2, m.loForm.Width-SYSMETRIC(3)*2, m.loForm.Height/2-SYSMETRIC(4)*2-SYSMETRIC(9))
ENDPROC
ENDDEF
 
For me Ideal solution will be to put Page Frame control and convert all your radio buttons to Pages. This will be more clear, easy and simpler solution to implement.

Please explore Page Frame control and that should solve your issue. Your page frame could look like below with individual page having required fields:

1737109573194.png
 
Last edited:
I second Premal Vala. But is there any reason you have all separate forms? If there is any reason, like all of them having a private datasession and separation of data from the main form, then the normal way to use them is as a satellite/popup form.

You may have the idea popup forms are bad, as they are suppresed by Browsers, for example, but that has it's own reasons. Spare the free area of your main form, put buttons or a commanfbutton group on it to start the different child forms and let the user decide here they want to move it, display it nonoverlapping, for example, and the user may even steart two or three of the smaller satellite forms, it could even be useful to have multiple of them side by side. That way you also have the least need for changes.

On top of that you could offer dockable forms. That won't allow a head area that stays visible, but adds a pageframe interface without needing to rearrange anything. Maybe only allow the popup forms to dock into each other and keep the main form undockable and not allowing docking, then you have the always present main form as header to all the other forms.
 
Last edited:
Yes, my first thought was a pageframe. And if you don't want to use the tabs, you can turn them off and have the radio buttons activate the appropriate one.
 
I already gave my advice and don't see any benefits of having an empty area in a form just to be able to position a form there. The sstraight forward way to have child forms (forms within forms) is creating a parent form that's capable to have child forms in it. In VFP that kind of parent form is a top level form. The property to set is ShowWindow. Setting a form "As Top Level Form" (2) it should become clear what "In Top Level Form" (1) means. Starting a form (DO FORM or CREATEOBJECT("formclass") - the way doesn't matter) from code of a top level form, an "In Top Level Form" then will become a child form that will be movable within the top level form only and that will move along with the top level form.

The use case that is what you use by default: Forms that all show in the VFP Screen (aka _SCREEN) form where the screen is usually empty (perhaps a background and acts as a desktop for all the application forms. Or instead of desktop (that should be reserved for the Windows Desktop, of course) it's just a parent form for all forms of the applicaiton, which keeps all the windows of one application together. I'd not consider it a good design to reserve a space for child forms, though. They still have a titlebar and are movable. And that's actually the major design of Windows itself. That's giving it the name. You have Windows and you're usually (within some rules about child windows containied within parents) free to move and arrange them as you like. That's what users expect of Windows applications. So a straight forward comple Winddows application design is to offer all forms to be movable anywhere on the Windows desktop, not confined to anything and not fixed into some predefined space, only. What you want is either a pageframe or container, not a form in a form.
 

Part and Inventory Search

Sponsor

Back
Top