@Aruna - You've slightly mis-understood which Panel I'm looking to move to a 'Form'. It is the MTF_Panel rather than the Output_Panel. This just meant that I had to assess what you were suggesting and modify the 'names' accordingly. No great shakes but better that you are fully informed. The 'Output_Panel' holds the buttons that affect how program output is dealt with (Data To Spread-Sheet or Printer; Image to Printer, along with which device is to be used) The MTF_Panel is the means by which the 'Device' is configured; This is the one that @WP suggested might be better as a 'Form'.
That was actually by design. I intentionally used the Output_Panel as the example because it let me demonstrate the overall logic and mechanics of moving a panel to its own form without getting tied to the specifics of any one panel. Once you understand that process, it's straightforward to transfer the same approach to the MTF_Panel, which is the one @WP was referring to. So the panel itself wasn't important, the technique was. Now you should be able to apply exactly the same logic with only minor changes to the component names and event handlers.
As yet, I cannot determine whether @Aruna's code snippet means that I don't need to have the MTF_Panel actually on Pr_Form or not and I have not yet been able to compile the project to find out.
Your current code base is over 7,000 lines long, so even small refactoring tasks can become tedious and time-consuming. While cut-and-paste makes it easy to duplicate a component, it doesn't preserve the associated event handlers. The quickest way to see this is to try it yourself, you'll find that the component is copied, but the events have to be recreated.
This is why I suggested using:
MTF_Panel.Parent := Pr_Form;
Instead of copying the panel, this simply re-parents the existing MTF_Panel to the new form. Because it's still the same component, all of its event handlers, properties, and state remain intact. There is no need to recreate the event declarations or copy the event code manually—everything is preserved automatically. It also saves a considerable amount of refactoring time and reduces the risk of introducing errors.
made the compiler complain that 'Pr_Form' could not be found. ( I was asked (and responded positively) to save the new Unit)
Adding Pr_Form to the Uses Clause of Tri (Interface section) had a slightly different error but still a 'not found'. Since there isn't a Uses section in the Implimentation Section, I created one and added the Pr_Form:
Again the compiler reported 'Cannot Find'.
I have checked and Print.pas & Print.lfm are both in the same folder as Tri.Pas.
So - for now, I'm stumped as to how I can get Pr_Form to be recognised as a valid Form :(
J-G, when you added the new form, did you rename it by editing the source code directly, or did you use the IDE?
If you renamed it by hand, remember that a form's name is referenced in several places (such as the .pas, .lfm, and project files). If you update only one of them, the IDE and compiler will still be looking for the old name, which usually results in errors such as "Cannot find..." or "Class not found."
When you use the IDE to rename a form, it updates all of the related references for you. If you do it manually, you need to make sure every reference is updated to keep everything in sync.
I've attached a ZIP file that demonstrates the approach. The code is fairly self-explanatory, so I hope it helps illustrate what I was trying to describe. Give it a try and see if it points you in the right direction.
To see how the demo works, follow these steps in order:
- Click Show Owner.
- Click the Close button on the MTF Panel.
- Click Change Parent.
- Click the Close button on the MTF Panel again.
- Click Show Owner.
- Click Reset to restore everything to its original state.
Recent
