Packages and Package structure

[UCT_24 0]

Hello,
i have a question on the general structure of RAD Studio Builder projects and packages.

1. I can define controls as child-classes of TCustomControl for usage in Forms I create later on.
   The .bpl holding the Components can and has to be installed via the IDE. Thus, the Components are installed within the package.

 

2. Those Components can be used in dialogs belonging to the same package the components are installed with and/or in dialogs belonging to other packages or applications.

 

My question is, if it is somehow discouraged to use the components on forms within the same package they are installed with.

 

I hope it got clear what i intend to ask.
Thanks for reading this and kind regards,

 

 

[Remy Lebeau 1385]

3 hours ago, UCT_24 said:

My question is, if it is somehow discouraged to use the components on forms within the same package they are installed with.

If you can use the components on external Forms, why would you think you can't use them on internal Forms, too? 

3 hours ago, UCT_24 said:

I hope it got clear what i intend to ask.

Not really. Can you clarify the issue you are worried about with more detail? 

[UCT_24 0]

Hello, thanks for your answer.
 

I will try to clarify my question.
Say, i have created a Custom Control, a kind of Grid or such. It is part of a package i have created. Within the same package i have several Dialogs that use this control.
Can this lead to problems in any way, or would it be better to have the package defining the custom control "installed" (to use in the designer as the built in controls) and make a seperate package for the dialogs?

I mean that "compiling the forms" and "installing the package" might interfere somehow, or can this not happen?
Though this technically works, i have quite frequently troubles compiling ( internal compiler errors ) and installing (runtime errors of various kinds, mostly by "rtl280.bpl/dll (or simillar)" which are not really reproducible.

Thanks a lot and kind regards,

[Anders Melander 1773]

20 hours ago, UCT_24 said:

it is somehow discouraged to use the components on forms within the same package they are installed with.

There's no problem with just using the components as long as you don't use them at design-time (i.e. place them on forms) as that could create a chicken/egg situation when the forms are opened on a system where the components hasn't yet been installed.

 

If you need to use your components in the package, just create them dynamically in code.

[UCT_24 0]

Hi Anders,

thanks for your answer.
I guess that is the cause of the issue, as to "use them in the designer" is the difference from any other "usual" class to a "Custom Component" as i have to deal with.

However this answer gives me hint at least.
Thanks a lot,
Ulrich
 

[Lajos Juhász 292]

There is no problem while the source can be compiled. I have such a package. If there is a problem and you can not compile it those files that contains components from the package can be edited only using extarnal editor (notped is my choice).

[Remy Lebeau 1385]

7 hours ago, UCT_24 said:

Say, i have created a Custom Control, a kind of Grid or such. It is part of a package i have created. Within the same package i have several Dialogs that use this control.

Can this lead to problems in any way

Yes, if you try to open those dialogs at design-time and the control has not been registered with the IDE yet. But if the dialogs create the control dynamically in code, then there is no problem.

7 hours ago, UCT_24 said:

or would it be better to have the package defining the custom control "installed" (to use in the designer as the built in controls) and make a seperate package for the dialogs?

Probably, yes. It depends on your use case. Are you expecting other projects to use those dialogs?

7 hours ago, UCT_24 said:

Though this technically works, i have quite frequently troubles compiling ( internal compiler errors ) and installing (runtime errors of various kinds, mostly by "rtl280.bpl/dll (or simillar)" which are not really reproducible.

ICEs are compiler bugs, only Embarcadero can address those. You have to change your code to avoid them.

 

Can't help you with runtime errors without more detail. 

[Lajos Juhász 292]

9 hours ago, UCT_24 said:

Though this technically works, i have quite frequently troubles compiling ( internal compiler errors ) and installing (runtime errors of various kinds, mostly by "rtl280.bpl/dll (or simillar)" which are not really reproducible.

 

I have had a problem with Delphi 12.2 when I have edited my package. After that I was unable to compile it due to access violation during compilation. The only solution was to delete all the dcu, bpl and dcp files. After that I was able to compile the project group. Of course, I cannot reproduce it and did not took any screenshots. 

[UCT_24 0]

Hello and thanks for the input on the matter.
It really helps. I was wondering if the structure is making trouble with compiling/IDE more likely at least.

2 hours ago, Remy Lebeau said:

Probably, yes. It depends on your use case. Are you expecting other projects to use those dialogs?

Yes, the dialogs are used from other packages once more.

[Anders Melander 1773]

16 hours ago, UCT_24 said:

It really helps. I was wondering if the structure is making trouble with compiling/IDE more likely at least.

When you recompile a design-time package that is currently installed then the IDE must unload that package before it can be linked.

Now, if you at the same time have forms open that uses one of the components in that package, then the IDE must also close those forms and this is where it typically goes wrong (AVs, internal errors on compile, etc.). Why I don't know. It's probably a bug in the IDE:

 

[Pat Foley 51]

I had had some luck following these rules. 

• Place only mature controls in the palette. 
• If a control coding is changed just select Install that seems to tell the IDE to do the right thing.  Needs to be 32 bit to see install.
• Any existing control needs removed from the designer view with ctrl X and the control gets the update as it pasted back in. This saves restarting the IDE.
• Check the path of control ensure that it's codebase made the trip to 290  and not using a control that using a 11 or 280 codebase.  
• Have a  sub project that allows the custom controls and forms to be compiled as standalone allowing modular construction getting custom controls working. then the main project uses the forms that have the controls placed on them.    

Edited October 10 by Pat Foley
added "have" note mature means working and in final trim

[UCT_24 0]

Hello, thanks for your answers, it really helped me understanding the issues. Thanks and have a good day!