Recent

Author Topic: [ANSWERED] Frames - why the difference  (Read 1179 times)

Badger

  • Full Member
  • ***
  • Posts: 144
[ANSWERED] Frames - why the difference
« on: March 21, 2023, 01:10:56 pm »
I've been playing around with frames recently - wish I'd done this a long time ago!!

I have one question.  My first attempt was to add a frame to my Form via the Standard toolbar which worked fine.  I read about the advantages of creating the frame at run time and gave it a try and again it worked but not until I had expended a lot of energy and pulled out a lot of hair.

The problem I had was that in the first instance I did things like changing the shape and position of the frame and its components from within the program.  When I tried to create the form at run time, these actions wouldn't even compile.  I finally worked out that just about the only thing I could do to the frame was align.  Is there a reason for this difference?
« Last Edit: March 22, 2023, 12:53:29 am by Badger »
Badger
(A bad tempered, grumpy animal that sleeps most of the winter!)

If at first you don't succeed - you're running about average!

I'm using Windows 10 Lazarus v2.4.4  FPC 3.2.2   Win 32/64

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Frames - why the difference
« Reply #1 on: March 21, 2023, 01:23:00 pm »
The golden rule for frames- IME at least- is that you edit a frame's properties in the form editor window dedicated to it.

Any attempt to edit a frame after it's been placed on another form will, at best, not work as expected.

Frames instantiated at runtime onto e.g. dynamically-created pages of a tabbed notebook generally work well.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Thaddy

  • Hero Member
  • *****
  • Posts: 14205
  • Probably until I exterminate Putin.
Re: Frames - why the difference
« Reply #2 on: March 21, 2023, 02:15:54 pm »
There is a design reason behind it, although nowadays it got lost in translation:
Frames were meant to be just design-time containers which contents were made part of a run-time container control, like a form or panel, at compile-time. (This was so designed at the Borland campus.)

But as I wrote: frames can nowadays - and even then - actually be manipulated to some extend at run-time and against the intentions: well, a form created at run-time can hold frames, or better its contained controls.
Along the same lines, form inheritance was introduced, but that is even more strict, also by design.

In a professional setting, though, I always preferred form inheritance over frames, because it easier to maintain team discipline regarding general lay-out of an application.

So the design premise of "Frames" was basically that in the run-time code you could no longer refer to a "frame" because it should not be there anymore...
« Last Edit: March 21, 2023, 02:23:06 pm by Thaddy »
Specialize a type, not a var.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Frames - why the difference
« Reply #3 on: March 21, 2023, 02:21:42 pm »
But the consensus appears to be that having properties of TFrame (descendant) instances editable at design time is undesirable.

The only properties which can be safely changed relate directly to the position of the instance.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Thaddy

  • Hero Member
  • *****
  • Posts: 14205
  • Probably until I exterminate Putin.
Re: Frames - why the difference
« Reply #4 on: March 21, 2023, 02:24:25 pm »
Correct. and in line what I just added (posts crossed). I was at Borland at the time, for a short period, but not involved  with frames.
OTOH Form inheritance is often a better option, but takes more effort.
« Last Edit: March 21, 2023, 02:28:19 pm by Thaddy »
Specialize a type, not a var.

korba812

  • Sr. Member
  • ****
  • Posts: 392
Re: Frames - why the difference
« Reply #5 on: March 21, 2023, 02:42:01 pm »
But the consensus appears to be that having properties of TFrame (descendant) instances editable at design time is undesirable.

The only properties which can be safely changed relate directly to the position of the instance.
Why? After all, this is the basis of a visual designer. You just have to remember that if you change the properties of a frame directly in the form, these changes only apply to the frame in that form. Exactly the same as with forms inheritance. Very useful for me.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Frames - why the difference
« Reply #6 on: March 21, 2023, 08:22:14 pm »
Why? After all, this is the basis of a visual designer. You just have to remember that if you change the properties of a frame directly in the form, these changes only apply to the frame in that form. Exactly the same as with forms inheritance. Very useful for me.

If you edit instantiated frames you're likely to end up having to fix your .lfm files by hand. I neither know nor care whether that's Lazarus-specific or will ever be considered to be something worth fixing.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

af0815

  • Hero Member
  • *****
  • Posts: 1289
Re: Frames - why the difference
« Reply #7 on: March 21, 2023, 08:45:46 pm »
The handling of frames was in Delphi the same. You must know, what you are doing (sometime the IDE was better)
regards
Andreas

Warfley

  • Hero Member
  • *****
  • Posts: 1499
Re: Frames - why the difference
« Reply #8 on: March 21, 2023, 09:55:12 pm »
The thing about Frames is, they are very useful to split up large Forms into smaller subforms, and this is good. The first lesson of software engineering is to split up tasks, instead of writing one giant block of code, split it up into function. Instead of having one giant file, split it up into units. So why not doing the same for the Form? If I write an e-mail client, I have a section with my folders, a section with all the mails within that folder, a section where te email is previewed, which is subdivided into a header and a body. Why should anyone want to put that all in one giant form instead of having small files for each section individually?

But the issue is, that frames, while being very good for doing that, when non dynamically created, are very bad at doing that. You want to put then together in your main form at design time, so you can see how it looks. But if you do that you run in all kinds of problems. E.g. you want to change something but forget that you need to go into the frames LFM for that, so you change it in the main form, and as a result you now have a disconnect with some changes in the frame and some within the main form, which is terrible for consistency and mainatainability.

On the other hand, if you change things within the frame, after the frame has been applied, anything can happen. Just create a project, add a frame with a button, add that frame to the main form, then delete the button from the frame. Now hell breaks loose, first if you want to run it you get a runtime exception because it can't find class TButton, then when you fix that, and you run again the button you deleted is still there. So changes aren't kept? No if you add another button to the frame, it is added to the main form at runtime. So additions are made to the main form, but deletions not?  The worst thing that can happen to you when writing a program is inconsistencies in behavior. You can deal with bad behavior a lot of the times, but inconsistent behavior can not be handled predictably.
Also even though some changes are taken over, the WYSIWYG editor does not update, making it less WYSIWYG and more a torture chamber for anyone trying to understand what is happening.

So once you put a frame on a form, you shouldn't touch it anymore, but taking the comparison to units, this seems ridiculus, imagine you couldn't change a unit after adding it to another units uses clause. This would make units useless.
With frames it's not that bad because you can dynamically create them, but then you loose the ability to look at your form in whole at design time, without having to compile and run the application.

So while they are still incredibly useful, they are not nearly as useful as they could be. The only real alternative I've found so far is to create a package where you create custom controls, which you can then design and use like frames, but thats so much more cumbersome than it would be if frames would be just a bit less bad
« Last Edit: March 21, 2023, 10:00:40 pm by Warfley »

Thaddy

  • Hero Member
  • *****
  • Posts: 14205
  • Probably until I exterminate Putin.
Re: Frames - why the difference
« Reply #9 on: March 21, 2023, 10:06:28 pm »
it would be if frames would be just a bit less bad
Long story put short:
- frames are design time only. They are a collection of controls thrown at another form with the hand that throws staying at home, no owner.
GOOD idea.
- Form inheritance is more flexible and cumbersome but has a firm rooted owner. Owners can be accessed at run-time...
Better idea.
Specialize a type, not a var.

Warfley

  • Hero Member
  • *****
  • Posts: 1499
Re: Frames - why the difference
« Reply #10 on: March 21, 2023, 10:19:06 pm »
The question is can you use form inheritance consistently as sub elements of forms, like if I just want to have a menu as a seperate entity (like if I create a component for this). I know this is possible with MDI capable widgetsets like Win32 Forms, but is it possible with all the major widgetsets (GTK2, QT5 and Cocoa)?

Because up until now for this I either used frames, or if it was a big project sometimes even create a custom package with new controls specifically for that project
« Last Edit: March 21, 2023, 10:23:07 pm by Warfley »

Badger

  • Full Member
  • ***
  • Posts: 144
Re: Frames - why the difference
« Reply #11 on: March 22, 2023, 12:52:52 am »
Thanks folks
More than answered the question.
Badger
(A bad tempered, grumpy animal that sleeps most of the winter!)

If at first you don't succeed - you're running about average!

I'm using Windows 10 Lazarus v2.4.4  FPC 3.2.2   Win 32/64

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Frames - why the difference
« Reply #12 on: March 22, 2023, 08:26:25 am »
Thanks for that, well thought out.

So once you put a frame on a form, you shouldn't touch it anymore, but taking the comparison to units, this seems ridiculus, imagine you couldn't change a unit after adding it to another units uses clause. This would make units useless.

I'll bite: if you change the interface part of a unit it has the potential to screw up anything that imports it.

The issue here is hiding the implementation. You wouldn't expect to be able to change the published parts of a unit from anything other than a text editor dedicated to that unit, hence it would be reasonable to expect that you couldn't change the published parts of a frame from anything other than a layout editor dedicated to that frame.

The implementation (i.e. content) of both a unit and a frame should be hidden at the point at which they are used.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

 

TinyPortal © 2005-2018