Here is a quick comparison of Delphi components and frames and at the end is my question.
Advantages of Delphi components:
They are encapsulated well. A software that uses components can access only public and published properties of components.
All their inner event handlers are available at parent form's design time.
Disadvantages of Delphi components:
They need to be installed with some package
The package is shared between multiple applications even if the components inside are application-specific
Advantages of Delphi frames:
They could be placed on a form just like components
Their published properties also can be adjusted in a form
They are in-app only and aren't available for the rest of apps which they don't belong to
They are quickly available. No need to install.
Disadvantages of Delphi frames:
All of their inner components are directly available in a parent form. If I move the components from published section, design-time customizations are broken in the frame designer too.
If I override the Resize method in a frame all the arrangements are available at run-time only. No arrangements at design-time are made.
If I introduce a new published property, it is not available in object inspector.
What I would like to have is a symbiotic thing:
Good encapsulation. None of the inner components is available from the parent form, but all their inner components are fully functional either at run-time or at their design-time.
Quick availability. No need to install.
In-app only. No sharing with other apps.
Their published properties can be adjusted in a form
All the method overrides (especially Resize method) are available at design-time.
Could you suggest a thing that fulfills these requirements? Or may be some surprising method to work with frames I didn't know about?
It shouldn't be necessarily a frame or a component. If some of other VCL classes fulfills these requirements, I would gratefully accept it.
If its properties have to be editable in the designer the object has to be a descendant of TComponent. TFrame actually is a descendant of TComponent.
Unfortunately, object inspector seems to use structure information from design-time packages only. Thus, you have to compile a design-time package for your custom published properties to show in object inspector.
But that strikes your requirement of Quick availability.
Related
I'm trying to figure out how to access a list of objects available in the Delphi IDE (ie., from different namespaces) from within a component editor. (Also from the same editor form running independently.) LiveBindings do it, and there's a video where they say you have to have a unit listed in a uses clause in order for the LiveBinding editor to see the classes defined inside that unit. But it does not have to be a form.
I can access forms through the Application.components array, but that only gives me access to the TForm objects. Any classes defined in the same units with the form aren't visible, nor are classes defined in any units that are not forms.
Someone suggested the answer lies buried somewhere in the Open Tools API.
I thought there might be someone here who could shed a bit more light on the subject.
BTW, I'm using DXE5, but anything from version XE and up is probably the same.
NOTE: I did find a property somewhere that lists every single class and record defined in the entire freaking ecosystem. There are hundreds of them! That's not much help. Still looking.
In Delphi 2010...
I am building a reasonably complex application. There are all kinds of non-visual VCL based components, such as TTable, TQuery, etc. I know I can put Data oriented components into a datamodule, so in design time, they don't show up on my main form. I am looking for a way to "hide" the other non-visual components. I know that I can hide them with GExperts, but as soon as you click on the form, they show up again. I seem to recall that there was a 'Component repository' type of component. You dropped it on your form, and then dropped all you other components into it... Can't find it though.
Is anyone aware of a way to accomplish this?
Thanks
Just put your other non-visual components on the DataModule as well. All non-visual controls can be placed there; it's only the visual (TControl/TWinControl) components that can't be (for obvious reasons - the data module has no visual aspect at runtime).
Note that this is useful even in applications that don't access databases of any sort. You can still create a TDataModule to hold all of your non-visual components like image lists, file open/save dialogs, and so forth.
What is the purpose of having a DataModule in your project? Does it have any special properties compared to a normal class or module? What are the conventions of what it's usually used for?
A datamodule is a non-visual "form" (container) that can contain non-visual components (usually database components, though any component can be added, such as dialogs and Indy components) that can then be shared by many forms.
This wiki explains further: Delphi Wikki.
It is normally used for Dataset and DataSource objects to keep them in a central location. A DataModule can only contain nonvisual components on it but are not just limited to Data Access components. You could put a TTimer on it and SaveDialog etc...
It can be useful when you have multiple forms, needing to change the code only in one place, instead of every form.
A datamodule differs from a simple class that it can be designed within the form designer and its components can be edited with the object inspector. The datamodule has also a resource that is streamed in a DFM file.
Furthermore a datamodule can be used by other datamodules, forms and frames and then its components are available for selection in the object inspector, too.
In my desktop applications, I usually have one data module containing a bunch of TImageLists. If my applications uses TCP/IP, the components are on a separate data module. Of course almost all of my application's logic goes in different data modules. And, if I need to create a service application, I put my logic in a data module so that I can easily create a desktop application around it for debugging. And, last, but least, I put my data access components on data modules most of the time.
In a moderately complex database application in Delphi it's easy to have dozens of datasets (tables and queries) and associated datasources on a form.
All these clutter up the screen.
It gets worse when your form has a pagecontrol where every page has its own set of datasources et al.
If the Tables and Datasources were visual controls, at least they would only be visible on the Tabsheet where they're applicable.
I've thought about creating some container object that could hold many datasets and datasources, but never got round to it.
I also have cnPack which adds to option to hide non-visual components from view in the designer.
However this is not helpful because it makes it hard to select them.
What's the solution to unclutter the form designer whilst still having the option to select the data access components?
(For what it's worth I'm working in Delphi 2007 and XE2)
You could create a data module for each logical group of non-visual components. Then name the data module accordingly so you can relate it quickly to the page the components belong to.
www.gexperts.org has a IDE plugin for delphi, which contains an option to hide/show all non-visual controls.
It is perfect for hiding all of the datasets etc so you can manipulate your components. You can then show them again when you need to access them.
To make life even easier you can customize the toolbar so you can hide/show them in a single click.
You can write your own small expert or component (like this one) to hide nonvisual components you need and store them in groups.
I'd like to create a custom "datamodule" in Delphi, a TDataModule like (maybe inherited) class which would have a custom grid based design interface (one component per line, some properties as columns). Is this possible? Where should I start?
I'm currently using Delphi 2007.
Maybe it is possible. An example of a XML Frame Designer can be found on the page New IDE Building Blocks. Well this example is for Delphi 5, but it might be a good starting point.
As Nick Hodges pointer out here:
Drawing on a DataModule in Delphi
it would be difficult to paint on the TDataModule descendant. Not impossible probably, but not worth the trouble for sure.
I would consider designing a completely new TDataModule from scratch, so you would have complete control over it. Sure a lot of work probably, but in the end it would pay off.
You can find TDataModule class in the Classes.pas unit. But this is just the runtime part of the code. Other parts are IDE related. You can find units related to ToolsAPI in "c:\Program Files\Borland\BDS\4.0\source\ToolsAPI\" for BDS 2006 for instance. You can also derive you own data module from TDataModule and register it with RegisterCustomModule (DesignIntf.pas). I don't know much more on this subject, maybe others do. As I said it would not be easy to do something like that. But maybe with this initial information you can find what you want.
It's not possible exactly as you describe it. You can't place visual components like a grid on a data module. You need a form or frame for that.
If I were to do try to something like you're describing, I'd use a list box to hold a list of individual components, a couple buttons and a selection dialog box for adding and deleting components from the list, and the TJvInspector component from the JVCL for modifying properties. That would be a lot easier than trying to make a one-size-fits-all grid to handle the situation.