Is interposer class really best to customize TPanel.Paint?

[Anders Melander 1783]

9 hours ago, Remy Lebeau said:

Quote

Packages compiled with the {$DESIGNONLY ON} directive should not ordinarily be used in applications, since they contain extra code required by the IDE.

Quote

Use the $DesignOnly directive in a package’s .dpk file to mark the package as being a design-time package. You cannot link the package with an application or library. You can only install the package in the IDE of Delphi or C++ Builder.

 

You can't use the rules for what a design-time packages cannot do as an argument for why a design-time package must also have a run-time package. Nowhere in what you quoted, or elsewhere, does it say that; It's a straw man argument.

 

Say I have this custom component:

unit MyComponent;

uses
  Classes;

type
  TMyComponent = class(TComponent)
  end;

procedure Register;

implementation

procedure Register;
begin
  RegisterComponents('My stuff', [TMyComponent]);
end;

end.

Apart from the fact that I should split this into two units, are you saying that if I place this into one package then I must mark it as both design- and run-time and if I place it into a design-time only package then I must split the unit into two and also create a run-time package? If so, that is simply not true. Going back, all the way to Delphi 1 (yes, I've just checked), there has never been a documented requirement for that.

[Uwe Raabe 2057]

48 minutes ago, Anders Melander said:

A package management system that allowed us the define per project design-time packages.

How would this be supposed to work when you have two forms open each belonging to another project having conflicting design-time packages? We should also not forget that form, frame or datamodule instances are sometimes opened implicitly inside the IDE.

 

I tried to get this straight with my Package Magician, but that still can handle simple cases only. A big blocker are package developers not caring about their packages being loaded and unloaded dynamically.

[Anders Melander 1783]

10 minutes ago, Uwe Raabe said:

How would this be supposed to work when you have two forms open each belonging to another project having conflicting design-time packages?

It wouldn't - but since that's no worse than the existing system I'd say it's acceptable.

 

11 minutes ago, Uwe Raabe said:

We should also not forget that form, frame or datamodule instances are sometimes opened implicitly inside the IDE. 

Linked modules, base forms etc. would need to follow the same rules as the rest of the project. I don't see the problem.

 

14 minutes ago, Uwe Raabe said:

A big blocker are package developers not caring about their packages being loaded and unloaded dynamically.

Then those packages would not be supporting per project configurations.

You need to establish a set of rules and exclude those that doesn't follow them. Not supporting dynamic unload is already a bug with the existing system.

[Fr0sT.Brutal 900]

On 8/15/2020 at 8:08 AM, FPiette said:

There is no bundling with app required. Simply don't add that package in the run time package list. The component code will automatically bundled in the application. Nothing to deploy.

I meant source code, of course. Reinstalling all the custom components for a fresh IDE is still a pain.

It's a matter of taste; I, for example, dislike excess components on a form so I create and use them in run-time where possible.

On 8/15/2020 at 8:08 AM, FPiette said:

Creating a separate package helps having clean code which is reused easily.

With interposer you have separate single unit with clean code which is reused easier than easily 😉

[FPiette 383]

12 minutes ago, Fr0sT.Brutal said:

Reinstalling all the custom components for a fresh IDE is still a pain.

I don't think so. I made a lot of components, split into a number of packages. I have a project group with all packages. I do a "right click" / "From here" / "build all" in the project manager and then select all design time packages in project manager and right click and select "install". It takes at most 2 minutes for everything. I don't call that a pain. And you only do it once when a new IDE is here.

 

I also use 3rd party components and I add their packages in the same project group as my own components for easy installation in any new IDE. This is quick and easy.

 

With a component installed in the IDE, you don't even have a single unit to include. The IDE do it for you when you drop the component on the form. Much easier and cleaner than an interposer class IMO. No code to add manually to any of your application.

 

[Fr0sT.Brutal 900]

5 minutes ago, FPiette said:

I don't think so. I made a lot of components, split into a number of packages. I have a project group with all packages. I do a "right click" / "From here" / "build all" in the project manager and then select all design time packages in project manager and right click and select "install". It takes at most 2 minutes for everything. I don't call that a pain. And you only do it once when a new IDE is here.

Right but you forget source paths.

 

7 minutes ago, FPiette said:

I have a project group with all packages

I guess you generate it again every time a new IDE version is out with corresponding packages? Still some piece of work.

 

Anyway project groups are nice and helpful.

[FPiette 383]

19 minutes ago, Fr0sT.Brutal said:

Right but you forget source paths.

What do you mean?

 

Quote

I guess you generate it again every time a new IDE version is out with corresponding packages? Still some piece of work.

No, the same .groupproj file is usable with any IDE. And the dpk file are compatible between IDE version as well. I works really nicely and easily. You should try...

 

Quote

Anyway project groups are nice and helpful.

Yes, indeed. I frequently use a project group with more than 100 projects.

[Anders Melander 1783]

44 minutes ago, FPiette said:

I don't think so. I made a lot of components, split into a number of packages. I have a project group with all packages. I do a "right click" / "From here" / "build all" in the project manager and then select all design time packages in project manager and right click and select "install". It takes at most 2 minutes for everything. I don't call that a pain. And you only do it once when a new IDE is here.

That's fine if you only work with projects where only one version of the components are ever used at the same time across projects or branches.

If you have to maintain multiple versions or branches of a project then you will potentially have to recompile the packages every time you change the branch you work on.

It's a significant effort to have to babysit every commit made by unaware developers because they save forms with component properties that doesn't exist in the version of the components the application will be built with. Compiles and runs fine on their system but breaks at run time when built on the build server.

 

If Embarcadero dog-fooded Delphi on something other that Delphi itself then I'm pretty sure they would have solved this problem a long time ago.

[Guest]

Like @Anders Melander said!

[Fr0sT.Brutal 900]

2 hours ago, FPiette said:

What do you mean?

You need to add paths to sources for all installed packages, otherwise many useful things won't work.

[Anders Melander 1783]

19 minutes ago, Fr0sT.Brutal said:

You need to add paths to sources for all installed packages, otherwise many useful things won't work.

That depends on how you setup your projects.

For example I never use the global library search path for anything other than the standard VCL/RTL. All project specific libraries goes into the project search path.

Since I also place these libraries in sub folders under the project root all the search path entries can be made relative to the root. This has the benefit that the projects can built anywhere by just pulling the source. All projects are self contained.

[Remy Lebeau 1396]

On 8/15/2020 at 3:41 AM, Anders Melander said:

Apart from the fact that I should split this into two units

In this example, no, since the only design-time functionality being used is RegisterComponents() which is implemented in the RTL in a runtime package, not a design-time package.  So this example can exist in a single runtime+designtime package.

On 8/15/2020 at 3:41 AM, Anders Melander said:

are you saying that if I place this into one package then I must mark it as both design- and run-time

Yes, so that the IDE knows that it is allowed to use this package for both installation into the IDE and compiling into executables.

On 8/15/2020 at 3:41 AM, Anders Melander said:

and if I place it into a design-time only package then I must split the unit into two and also create a run-time package?

Yes, because designtime-only packages are not allowed to be compiled into executables, only runtime-only and runtime+designtime packages.  Marking the package for runtime usage is important.

On 8/15/2020 at 3:41 AM, Anders Melander said:

If so, that is simply not true. Going back, all the way to Delphi 1 (yes, I've just checked), there has never been a documented requirement for that.

Maybe not a hard requirement, especially in the early days, but around D6 or so this actually did start getting enforced.  And besides, it is how the system has always been intended to be used, and how it gets documented by 3rd party books and such.  And frankly, it just makes sense to do it this way.  Component logic goes in a runtime package, design-time editors go in a design-time package.  If there are no editors, the two packages can be merged into one.  Simple and straight forward.  Whether or not it works to compile a designtime-only package into a runtime executable is another matter.  It is not supposed to work.

[Anders Melander 1783]

1 hour ago, Remy Lebeau said:

On 8/15/2020 at 12:41 PM, Anders Melander said:

Apart from the fact that I should split this into two units

In this example, no, since the only design-time functionality being used is RegisterComponents() which is implemented in the RTL in a runtime package, not a design-time package.  So this example can exist in a single runtime+designtime package.

What I meant was that it's good practice to separate all run- and design-time code regardless of the fact that I didn't need to in this case. Thus my use of should instead of must.

 

36 minutes ago, Remy Lebeau said:

It is not supposed to work.

So far we have just your word for that and I contest it.

 

The Delphi Developer's Guide has 14 pages on the topic of creating run- and design-time packages yet nothing that supports your claim. However it does mention one little detail that I had completely forgotten about: The DCLUSR default package. Guess what; It's a design-time only package. Do I need to elaborate on what that implies?

 

[Guest]

@Remy Lebeau's explanation above is mint! Thanks.

[FPiette 383]

On 8/17/2020 at 1:09 PM, Fr0sT.Brutal said:

You need to add paths to sources for all installed packages, otherwise many useful things won't work.

I never use IDE global path, nor library folder. All my project have explicit paths (always relative) to everything, except components delivered with Delphi. All my components and all 3rd party components I use are all explicitly added to all projects they are used in. And I always recompile everything, never use a prebuilt dcu, obj or package. This way I'm always sure to have everything required to build an application. On the computer I use, it takes only a few seconds to compile hundreds of thousands code line.

 

I use Delphi since version 1 (25 years ago) for almost full time.  I wrote hundreds of applications, some of which are very large. I have always had great success. I will not change the way I work.

Edited August 18, 2020 by FPiette
Typos

[Fr0sT.Brutal 900]

12 hours ago, FPiette said:

I use Delphi since version 1 (25 years ago) for almost full time.  I wrote hundreds of applications, some of which are very large. I have always had great success. I will not change the way I work.

Ow. Sir, with all the respect, that was too pathetic. I wasn't trying to convince you to change your workflow. There's a conversation on the thread's subject, right? So, just like you, I was just telling my experience.

[Lars Fosdal 1792]

I use the same approach as @FPiette