I have been developing a number of components using TFrames and ModelMaker -- I've found the combination of visual design/development + inheritance + ModelMaker to be very compelling. I then register these TFrame descendants w/a registration unit, and they become full-fledges palette-based components from there. I'm using Delphi 2007.
Early in my learning about the little "snags" of this process, I found that a number of the problems I would run into with TFrame descendants streaming incorrectly (often appearing as forms in the IDE, rather than frames) could be completely eliminated by introducing my own "TBaseFrame" class which inherits from TFrame with no chanegs, and then use THAT as the base class to develop components from (adding methods, properties, etc). If I added properties and methods, etc. to a class/frame inheriting directly from TFrame, the dfm file streaming would often get confused.
So, overall it's worked great, once I got the kinks worked out.
Yesterday, though, I ran into a new problem:
I install the resulting components in package sets, grouped in ways that make sense (i.e. all of the "panels" for App 1 are in one package, a number of "viewers" for App 2 are in another, etc).
If the TBaseFrame class is not included in the package, the inheriting TFrame-descendant component will not load in the IDE. BUT, if I add TBaseFrame to the package, I run into the conflict Delphi reports when it has the same source PAS file in more than one package.
I could put ALL of my frame=based components into one giant package, but I'd really, really prefer not to, as I can clearly see that will get too large / out of hand over time, given the nature of how many sets I plan on developing. Is there any other way to resolve this conflict?
Update -- there is a trick to getting this to work "properly" -- be sure to read the comments below.
Have you tried to put your TBaseFrame in one separate package that would be "required" by all other packages?
Related
We are using Delphi 10.4.2 Sydney. I would like to create a single unit (or possibly multiple units) that houses all the utility functions we use in our various software products. The idea is we would just include this unit in every project we start and then we can rely on it being there and use these functions freely in all our code. These would probably be mostly class routines and such.
I'm concerned though that some of our projects might only use a single routine in this large unit. The size of our apps is important and we want to keep that size to a minimum. I am not familiar with how Delphi's compiler works or how much space adding a superfluous unit might add or any other issues with this.
Is there perhaps a way to create a Unit where only the functions we actually use will contribute to the final build's size? Is this even something to worry about? How are common utilities library usually handled in Delphi?
The Delphi Linker is supposedly smart enough to detect unused functions and will not include the code for them in the executable it generates. This also applies to class methods. (*1)
So, go ahead and create these units.
You can easily check whether code was generated for a method by looking for the blue dots during debugging.
(*1: That feature can be a major pain in the lower back when you want to call such a function from the Evaluate/Modify dialog during debugging.)
Put the units into a separate package project. If you build your exe as a monolithic exe (so packages are linked in) then the compiler should only link in the units that are actually referenced, not the entire package.
So, I have a myself written run-time package. If a package is statically linked, the project that uses has full access to exported data because the compiler has full knowledge of what is imported from it, am I right? But it's also possible to load a package dynamically via LoadPackage(). But, how to work with imported complex data structures like classes then? I couldn't find a feasible way other than constructing complex expressions like using FindClass('TSomeClass') and invoking RTTI to operate on an instance of the imported class.
The compiler has full knowledge of what's in the package because the DCU and DCP files tell it what's there.
The IDE knows what's in the package because it knows how to find the Register procedure in all the units, and that procedure tells the IDE about the available classes.
In most cases, a program knows what's in a package because the program used units from that package, and the compiler assured that mentioning names of things in those units would resolve to corresponding things in the BPL file at run time. This includes mentioning the BPL file in the program's import table, so the OS loads the BPL automatically.
If the list of BPLs you wish to load can only be determined at run time, then you cannot use any units from those packages. You have to load the package dynamically.
There's still the matter of how to use what's in those packages. You could try to discover the entire contents with RTTI. That's no picnic, though. Instead, define an intermediary package that all involved modules will use.
Define an interface or a common base class for all your packages' classes to have. Put the definition of that class in a unit that's in its own package, which we'll call Shared.bpl. Include that package in the "requires" list of all your other packages and your EXE. Now, everything can refer to the shared unit and the common base class.
This is exactly what Delphi itself does. The shared packages are called RTL and VCL. There are several common base classes already defined there, including TComponent. In your case, it sounds like you need some common definitions beyond what TComponent has.
Short answer:
What you need is the compiler/linker to set you up and use DCPs to do all the linking to types and such.
Then loading of BPLs should be delayed/done by you in custom code.
Unfortunately Delphi won't allow this, probably because of political reasons, you could try and hack it though, see below for more thorough answer.
Long answer:
Apperently DCP describe to the compiler/linker/Delphi yadayadayada what's in those packages/DLLs/BPLs type-wise.
These DCPs can be considered the interface to these DLLs/BPLs, these DCPs are probably somehow compiled into the executable.
Then the BPL probably contains the "implementation".
Now here is where the problem begins. These BPLs are "auto-loaded" as somebody else already mentioned by mentioning "import table".
What you could try is "nuking" / altering the import table so that these BPLs are not loaded automatically anymore.
Then you could try loading these BPLs manually.
I am not sure if it's just as simple as doing a "load package" operation.
Perhaps the loading involves more like acquiring pointers to routines/methods/classes, not sure how that works.
However perhaps that code can be re-used, so all you need to do is "hack" into the import table and hack into the "load bpl" and disable it.
Then you should be able to replace that with your own custom loading code and perhaps finally "re-patch" into other importing routines... like routines calling getprocaddress and such if so required, not sure about this last part.
Anyway this is very sloppy from Delphi developers that there is no functionality to do this little "import table"/"load step" yourself.
This is politics at play though, there is no technical reason why this could not be delayed, done custom by you and then call the rest if necessary.
For some reason they do not want you loading these BPLs manually. They probably want you to keep using the IDE this way.
If you were able to load these things manually, maybe the IDE would then no longer be necessary.
Currently the IDE is necessary to specify where to load this stuff from, without the IDE it will get difficult. Though there are probably also some compiler options somewhere to specify the same, though few would use that.
So to me it seems some very weird "tie-in" into this product, which I honestly must admit is pretty fucking retarded.
They did the same with winsock for example which has two different versions, very easy to load this yourself manually so you can choose which version to use instead of always v1 or v2. For easy for them to delay these getprocs and such, yet they do not...
If they did, Delphi would be much more backwards compatible with windows 95/98, currently Delphi exes no longer works for those older operating systems, though there is no real technical reason why it could not work, it basically has to do with which DLLs are loaded, just a few lines of code could very easily make it work.
This is probably again politics as play to make Delphi only support the latest Windows versions a deal struck between Delphi creators and Microsoft.
Same thing with Windows 10, it apperently detects older processors and then refuses to run on them, removing/hacking these few lines of code/instructions will make Windows 10 work on older processors. Surprise ! =D
I have seen that most of the components (VCLs) in Delphi are split in two parts.
1) DesignTime Package
2) RunTime Package
Why all this fuss. What difference does it make if both RunTime and DesignTime packages are united into one single Package?
I have never really been able to understand this separation logic.
So what is the logic behind this?
Once I had head someone mention that this distinction was made just to avoid adopting and following Component standards as laid down by Microsoft. Really there is no logic behind this.
Is this true?
A. Some components have large and complex design-time features such as property editors, which you may not want to include in your run-time application.
B. Some component vendors do not want to licence their large and complex design-time features for royalty-free run-time use, but restrict them to use by developers only.
If you had done a little bit of research, you'd have found this SO question asked less than 2 days ago...
As already explained the main reason is that you cannot include any Delphi Design unit in a runtime package. And there is no reason to bloat your executable with code that can only run within the IDE anyway.
Designtime stuff may use Delphi's
internal units/packages to which you
neither have source code nor are
legally allowed to distribute in
binary form.
You probably don't
want to make your application require Delphi
to be installed on the user's
computer.
The logic is to keep your own code separate from the "glue" code which makes it nice & easy to work with in the IDE.
We have a Delphi 5 application, that is built without runtime packages, dlls or external resources (i.e. a single executable). when we install it on a clients PC we get the following error messages:
Class TListView not found
or
Class TImage not found
We have installed it on dozens of PCs before without incident, but this latest install is problematic.
The target PC is a fresh install of Windows XP (Service pack 3) with no other software installed.
It does not complain about all of the classes however just one or two. for example TPanel/ TForm/ TEdit are all OK.
Can anyone think what is causing this?
EDIT
The exe on the new PC is on 30 or so other PCs that I know of, ranging from windows XP Sp1,2,3, Windows Vista and Windows embedded. both old and new PCs were installed with an old version and then updated with the newest version. The only difference is that the version jump was higher for the latest install.
This is typically an error during the streaming of a .DFM. Usually this error occurs with TLabel components because many folks remove the TLabel fields from the form or frame in order to cut down on the clutter and reduce the instance size of the form. The common and confusing mistake they make, however, is that in their over-zealousness, they remove all TLabel references. That is when bad things start to happen. Let me run down how the streaming system locates a component's class.
Remember that the class reference in the .DFM is just a string. The streaming system has to convert this string into a class reference (TComponentClass). There are two mechanisms that the streaming system uses to do this. The first one is very simple and involves a global list of class references. You can call RegisterClass or RegisterClasses to explicitly make the streaming system aware of it. The second is much more subtle and not very well known; in fact it is all part of the "magic" of Delphi :-). When the compiler builds the form, all the fields that represent the components on the form are processed and an internal table is built as part of the RTTI or metadata for the form/frame/datamodule itself. This table contains a list of references to all the individual component types represented by the component fields. So even if a component is not in the global list, it can still be found by scanning through this compiler generated table. That is what the Classes.TReader.GetFieldClass() method does.
Back to my TLabel example, this problem is easily fixed by simply ensuring that at least one of a given component type has a field. So as long as there is at least field of type TLabel, all the other TLabels will load just fine. So in your case, make sure the TListView or TImage fields haven't been deleted.
Re0sless,
I suggest you open and close every form of your application and do a fresh build after that. If memory serves me well, that was the solution when we encountered similar problems.
You might also take a look at DFM Check to open and close all your dfm's automatically and at CnPack to help you clean your uses clause.
Regards,
Lieven
I think Lieven is definitely on the right track: simple base classes not being found during runtime are a Delphi (linker) problem. This exception is not caused by the Operating System.
My experience with similar problems: the linker generates a project with the units wrongly arranged.
Example: a form unit is linked in before the base units. Forcing the project to completely recompile/relink itself should make this exception go away.
A simple [Rebuild All] will probably not suffice. You might try to recompile without optimizations.
I have tried to reproduce this error but I have not been able to. The Delphi compiler/linker is one of the best - speed of compilation/speed of compiled exes - but this bug is definitely a show stopper.
Note: I have only experienced
this error in D5. Has anybody else
experienced this error with other
Delphi versions?
I had the same problem. Class TCheckBox not found. I usually edit large set of components through .DFM of form(for example renaming large amount of component). This error comes when I rename all CheckBox on my form through it .DFM.
I just cut all the checkbox and paste them again(So .DFM file is refreshed). The error disappeared.
I've seen a similar problem due to a file copy error. To make matters more confusing, the fault was on an intermediate media device. The issue was resolved by simply recopying the file from the existing release build.
It is probably impossible to confirm now, but it is quite possible that the problem was 'solved'; not because of the removal of an unnecessay uses clause item, but because it also involved a new copy of the executable.
The solution for all errors of this type "Class XXX not found" is simple. Open DFM file of a form in text editor and manualy remove the definition of the XXX object in it.
Change the name of the Form and save the .pas with other name. Change all references to create the new unit name if this is used in other units. Build All.
With this the error disappeared.
Remember the old class hierarchy posters that used to come w/Delphi?
I'm wanting a full class hierarchy browser for ALL my Delphi classes, including the custom ones I've built and installed on the palette, plus third-party components. Ideally easily searchable by class name (including "whole word only" searches, so partial matches don't count).
I've only seen two things that come close:
1) GExpets Class Browser - Works great, BUT doesn't automatically load ALL installed components / classes, which is what I want. You have to import all the source units manually, as far as I can tell.... which can be quite a hassle. It also doesn't allow "whole word only" searches, so sometimes searching for a class w/a common "sub name" takes forever.
2) Eagle / DevExpress CDK - It loads the full class list automatically, and seems to work brilliantly, but it's only usable in D7 and prior, and it's not really focused on being a class browser per se, so much as an "inherit from" chooser.
Is there anything out there which does this already? If not, how difficult would it be to write an app that, at bare minimum, builds a self-referencing class-name table, so I could at least throw it into a database / treeview component to easily view inheritance / ancestry, etc.?
I think ModelMaker Code Explorer has this feature, but I don't use it
ESSModel is another nice class browser tool, and it's open source. I don't know if there's any way to get it to load a list of units automatically. Not sure, but you may be able to manually import all the units you want and then save that as a base project that you start from with all your individual projects. Not sure how performance would be with that much loaded, or how easy it to view the part(s) you want.
http://essmodel.sourceforge.net/
Assuming you need a Delphi IDE Expert (you've mentioned somewhere in your post: "...installed on the palette, plus third-party components"), DelphiDiver is good for you (Source code available on the DelphiPraxis, registration needed).
Look and feel:
If you feel like delving into the IDE in order to get more indepth details, click Inspect the IDE hence the name of the Expert (DelphiDiver) ;-)
Click Inspect the Packages so as to browse any other third party component(s) or whatever package(s)/component(s) you've installed.
It makes use of the advanced RTTI and requires Delphi 2010 version onward.
I've personally installed it using Delphi XE on my box.
I hope it can serve as a base for the more focused Full VCL Class Browser you are looking for.