I have inherited an application that was started as an MDI program, but the necessary background work was never put in place to fully support MDI. I'm trying to build in just enough MDI support to make the application look good and work properly as an SDI application.
Here's what I am observing, and I don't know how this is happening or how to fix it.
The MDIchild form's border is shown above the MDIparent form's menu strip.
The MDIchild form has two icons in the upper left.
The MDIchild form has two ControlBoxes in the upper right.
Any ideas why this would be?
I'd be really happy if the MDIChild window border (including the icons and control boxes) was removed entirely.
Thanks,
SH
I created the child form but showed it in normal state instead of maximized. It's as if showing the parent form in the same process as the maximized child form caused the form to be constructed out of order. My code looked something like this...
frmChild.WindowState = FormWindowState.Normal
frmParent.Show() 'frmChild.Show called within form_load of parent
frmChild.WindowState = FormWindowState.Maximized
And yes, I set the Child window's FormBorderStyle to None, but like I said, I didn't want an MDI application.
I think this must be a bug in Visual Studio. For so many people to have difficulty with it, it can't be right.
I found:
Call Show() on your MDI form before setting the WindowState property on your child form to get rid of the multiple control boxes.
Do not set the WindowState to Maximized in the designer -- do it in code after you've shown the parent.
Related
I have a delphi application with multiple forms. Initially I had tried a setup where each newly opened form was a frame and the "parent" of this form (whichever called to open the form) was hidden as the child was shown with the child being resized and relocated to give a seamless effect of having one window, when the child is closed the parent is relocated and again made visible. All forms have a bsSingle border style for the Windows title block.
This approach worked well for positioning however the issue I have is a noticeable flicker as the parent form is closed and the child opened, and as there is a small time period where no form is opened the icon/tray on the start bar would shift around and itself become hidden and visible.
Does anybody have any advice on solving this problem? I thought perhaps if I only had one form with the border within the application and opened each new form within this border it would work better - though I am unsure how exactly to do this.
Any help is much appreciated.
It is easy to make one form appear as a child inside another. Create a new form which will contain and create your other forms:
procedure TMainForm.FormCreate(Sender: TObject);
var
F : TForm;
begin
F := TOneOfYourChildForms.Create(Self);
F.Parent := Self;
F.Show();
end;
Create both your child forms similar to this, then just do Show on the one you want to display and Hide on the other. Set BorderStyle to bsNone on the child forms to remove the caption. Turn off Auto-Create on your forms in project settings if you create them yourself like this instead.
I've had success with this design, and I think it helped to have the contents of the "main form" within a TFrame as well. When you want to show the main form, you would just perform a frame swap.
Is it possible to create an MDI application using FireMonkey in a traditional sense of many documents forms/frames and one master form?
I'm specifically interested since there are no MDI controls on forms anymore.. Has it been replaced with something different?
EDIT: Adding to the question, when I create child forms they all showed separately in taskbar, even the OpenDialogs..
Here's one approach you can use:
1) Create your individual forms as normal, except use a TLayout, call it "LayoutMain", (aligned alClient) as the parent of all controls on that form.
2) On your "master form", when you want to bring a form instance in to behave as it would as an MDI interface, create a TLayout (call it "FormContainer" or something), place as a child of that (aligned to top) another TLayout (call it "FormHeader"), containing the individual controls for the Form Caption, the Minimize/Maximize/Close buttons and anything else you'd like on the "frame" heading. This is called a Composite.
3) Create an instance of your child form (but don't show it), then parent that instance's primary TLayout "LayoutMain" to your main form's TLayout "FormContainer".
4) On the TLayout previously mentioned (with the name "FormHeader"), give it OnMouseDown and OnMouseMove events to provide the ability to drag it around the Master Form.
When you want to maximize the child form inside the master form, you'd just set the outer TLayout "FormContainer" align property to alClient, remembering to store its original Top, Left, Width and Height values within the the form's instance so you can recall them when pressing the Restore button.
True, this is a fairly involved solution, but to the very best of my knowledge this is the only way you're going to achieve what you're trying to do with FireMonkey as it exists today (circa Update 2).
I wouldn't expect Embarcadero to provide any form of MDI emulation as part of FireMonkey "out of the box", as MDI is considered an old-fashioned approach.
The more modern solution would be to use Docking, as the RAD Studio IDE itself does. This provides the very best of both worlds, giving the user the freedom to choose what child forms they want to link into the master form, or display outside of that on their own (or any combination of docked arrangements).
I have a number of forms that 'host' other forms using ChildForm.Parent := HostForm and ChildForm.Align = alClient etc. Some child forms are host themselves for another child form. Under Windows 7, the alignment is fine but Windows XP sometimes leaves the child form visible but not client aligned. Touch the outer window frame to resize it by one pixel and it all springs aligned correctly. Is there a command I can send to the host form to ensure that the alignment has taken place properly?
You might want to take look at Realign method. Look also at AlignControls and ArrangeControl to manually align the child control. Consider also using Frames instead of Forms if it is possible - they are designed for the job you described (but on the other hand have a number of inconveniences - for example lack of OnCreate event).
Best regards -- Spook.
I also had this problem a few times and it seems it is often caused by faulty controls on the child form.
How to avoid issues when embedding a TForm in another TForm?
Is it possible to edit a DFM (Delphi's form script format) in such a way that a form closes itself when shown?
I don't code in Delphi, so I'm not familiar with how these forms work, but it seems I could put code (but not standard Delphi code as it seems) in the OnShow or OnCreate events of the form. However, after trying several statements like Close, Exit, FormNameExit, Destroy, etc. won't work (a log will be created, stating the error that the value of the OnShow property was invalid, etc.)
The normal way of closing the form is through a button, but the button doesn't have a OnClick event, just a property, "ModalResult = 1".
Is there a way to make the window close upon opening, some standard function I could put on the OnCreate or OnShow events of the form? Or maybe, creating a checkbox on the form itself, that gives ModalResult = 1? (don't know if this works)
Thanks for any suggestion!
=)
(Note: maybe it's obvious, but I don't have the source.)
Not in DFM. You would have to modify the source.
The OnShow and OnCreate lines you're seeing are only used to give the name of a method that's already defined in the source code. You can't add much functionality at all by modifying the DFM file.
Perhaps the form already has a matching event handler that closes it: the OnClick handler for a close button or menu item, maybe? If so, you could try setting it as the OnShow or OnCreate handler.
You might be able to add a TButton to the form and set its ModalResult -- I don't recall whether you actually need a field in the form class for each control in the DFM -- but that would only work if the form is shown modally, and you'd still have to click it to make the form close.
EDIT: Seeing some of your comments added while I typed my text-wall clarifies things a bit.
I'm guessing that you you're using a resource editor to edit the DFM and modify the behaviour of the app without actually touching the source code?
In this case, the best you could try is to set the Visible property to False. However, this will have no benefit if the developer 'actively displays the form in code'. (He could have done this by calling Show, ShowModal or even by explicitly setting the Visible property.)
Unfortunately, if this is the case, then there's nothing you can do without modifying the actual source code. This is because the DFM is processed when the form is loaded; i.e. before the developer's code that shows the form. Even looking for a place to set ModalResult is useless, because the current ModalResult is cleared when ShowModal is called.
I don't think I understand exactly what you're trying to do, because it doesn't make sense.
It seems to me that you want the form to be automatically closed as soon as it is shown; and that doesn't make sense. :S
So, if I have understood you correctly, please explain why you would want to do this; there may be a better solution for your actual problem.
However, some general concepts...
If you want a form to close, you should link it to some action that closes the form. Either put a button on the form, or a menu item.
Standard forms have a standard Windows mechanism to close them by default. (I.e. the X on the top-right.)
There are two ways of showing forms, and the way in which it is shown does have an effect on how it will be closed. It can be shown modally (which means it is the only form of the application which will interact with the user), or it can be shown normally (which allows the user to switch between other forms of the application).
The point of showing a form modally is that it blocks the flow of your code until the user has finished doing something that was required; it often involves the user providing some form of answer or confirmation.
When shown modally, the form should rather be closed with a ModalResult.
When shown normally, the ModalResult has no effect.
Whenever a form is 'closed', there are a few ways in which this can be done.
The form can simply be hidden; it's still there, but invisible. Next time you want to show the form, you just make it visible again.
The form can be destroyed; meaning that it no longer exists in memory. If this is done, then next time you want to use the form, you have to recreate it.
The attempt to close the form can be actively prevented (Not usually advisable; but may be necessary in specific cases - if for example some information on the form is incorrect).
The form may be simply minimised (this is often done with MDI child forms).
NOTE: There are also a number of attributes on forms (FormStyle being the most important) that have an effect on how it behaves, displays, and can be closed. (E.g. MDI Child forms will by default either minimise, or do nothing when closed.)
NB:If the main form of an application is properly closed, then the application will shut down.
Now, some of the technicalities...
As mentioned earlier a form can be displayed either modally, or normally; using either MyForm.Show; or ModalResult := MyForm.ShowModal;
NOTE: If the form was shown modally, you then need to check the ModalResult to find out the user's answer and act accordingly.
If you displayed the form modally, you should set the ModalResult and the form will close itself. An easy way to do this is to assign a ModalResult to the buttons on the form; then the button will automatically set the form's ModalResult when clicked.
If you displayed the form normally, then all you need to do is call MyForm.Close at the appropriate point in time. NB: Note their are other ways to 'close' a form, but it is better to use this method because it allows you to handle the OnCloseQuery event which is a mechanism to confirm whether the form is allowed to close.
NOTE: While closing the form, there are two events that Delphi can call which you can handle in order to modify how the closing of the form behaves:
OnCloseQuery is called to confirm whether the form is allowed to close.
OnClose is called to find out how the form should close (as explained previously).
Coming back to your question (which sounds like you want the form closed automatically). Rather than closing the form automatically; just don't bother showing it. This is very easy to do. All forms have a Visible property; if set to True, Delphi will automatically show the form normally when it is created. So all you need to do is ensure the property is False.
You really can't do much without the source but move files around or change existing properties. If you have a MAP file for the program and there are existing events in place (onCreate/OnShow) you could patch the executable to invoke different code for those events, but it won't be easy and you have to insure that you don't inject more code than was there previously or make any external calls to routines which don't exist.
I'm looking after a way to AlphaBlend a child form, if possible using layered windows as there will be interactive controls behind it.
The problem is I have a component in a regular TForm that paints multiple visual layers (drawings, pictures...). At some point I need to instantiate an editor control on this form (in-place), this control will involve a variety of standard input controls outside of my control (edit box, check box, etc.), however I would like to overlay the layers in front of the layer being edited using alpha blending (and WS_EX_TRANSPARENT to make it click-through).
I first thought of using child forms for that (borderless TForms parented to the component), and that works alright, up to the point where the AlphaBlended TForm isn't alphablended at all, but turns opaque as soon as parented...
I then tried to unparent the alphablended form, set it to fsStayOnTop, and by reacting to the relevant events, keep it in front of the component on screen, that works, but that isn't a truly satisfying solution: the alphablended StayOnTop form is also in front of other modal and modeless forms of the application, should the user decide to move them in front of the component...
So, any other ideas on a way to have a child form be alphablended? (or behave like it is)
According to MSDN you are out of luck, as WS_EX_LAYERED cannot be used for child windows.
Maybe you could hide all editor forms when your form / application loses focus, that would at least keep them from being on top of other windows. Still, it's unsatisfactory...