I am working on a multiple-device application in Embarcadero Delphi XE7.
Being new to delphi I would like to know how (if possible) can I rename a Form's Name.
e.g. TForm3 to something like frmCustomer.
You can change it from the Delphi Object Inspector - official documentation on how to customize the main form of an application.
You got me a bit confused. You want to rename a class name (TForm3) to frmCustomer. A defacto standard is to prefix all classes with a "T", like TfrmCustomer. Never have a class named frmCustomer, use that for the instance instead (here form3 -> frmCustomer). Generally it's a very good idea to be strict about renaming all controls. Makes things a whole lot easier to maintain.
I prefer to use the built in refactoring (shift-ctrl-e) while having the cursor stand in the """thing" you want renamed, e.g. TForm3. That way the name, that be a class, method or attribute, is changed throughout the project.
I can furthermore recommend you install GExperts which, among many good features, have one to name the components while you place them.
Related
Just upgraded from Delphi XE to Tokyo, and was hoping for some updated IDE features.
One nice to have feature would be automatically providing options to add a unit to the uses clause. For example, if you reference something in code that isn't in a uses, it would be nice if the IDE prompted you to add the related unit(s).
For example, keeping it simple, in IntelliJ, you might declare a Button, but not yet have added the associated Library to the Import clause.
When this happens, the offending line is highlighted (just like in Delphi), but the IDE will let you add the necessary library with an Alt-Enter. If there are multiple libraries (it knows about it) it will prompt you for the one you want.
Anything like this for Delphi?
Delphi 2007 and later versions support this for most types that it knows about (in the search or library path). (It may have been available in D2005/2006; I don't have them installed anywhere now to check. I know it was not in Delphi 7.)
Put in the type, and use the Refactor menu (Refactor->Find Unit) or press Ctrl+Shift+A.
Here's an example:
It's not 100% effective, but it's a vast improvement over the old way.
(And yes, I know about TArray<string>, before someone chimes in. I just grabbed a quick type that I knew wouldn't be in the default VCL form uses clause for an example.)
I need to change the functionality in a component. What do you do when you get a "you can't override this" message, or you need to change the code in a private method ("method does not exist in base class" message), rendering it impossible to descend the component?
If I face that problem,
I first try to inherit from the component, or its CustomXXX ancestor and see if that fixes the problem. If that doesn't,
I go deeper, i.e. try to intercept the messages that come in. That can be done dynamically. If that turns out to be too deep, because the code that has to be built on that is too extensive, or if I still have to access items I can't access,
I try hacks. One hack is to copy the component and the dependent code to a new unit with a different name, rename the component and modify what needs to be modified.
Sometimes I only need to redo one or two methods to make my new behaviour possible.
Never forget to give the unit a different name and the component a different name too (possibly inheriting from the original component or one of its ancestors, so they remain in the same hierarchy). Do never modify the original sources and then recompile the VCL. That is a maintenance nightmare.
I am no fan of interposer classes, i.e. classes that get the same name but different behaviour than the original classes, inheriting from the original. Their functionality depends on the order of inclusion in the uses clause, and that seems rahter flaky to me. I can't recommend that.
But what I do greatly depends on the problem. I don't think one can (or should) give a blanket advice that covers all situations.
But my main advice: do not modify the original units, always put the new code in a new unit and use a new class name. That way the original and the modified versions can peacefully co-exist, also in the IDE.
There are some (mainly hacky) options when it comes to modifying private methods or behavior therein:
modify the original source, recompile the unit and use the changed dcu as suggested here; never did this but I think this can cause you a good headache when your code uses the new dcu but other VCL code don't
often component behavior is controlled by numerous window messages - look if you can achieve your change by modifying the reaction on some of these messages; you can override the message handling methods (the ones with the message keyword) even if they are declared private and you can also replace the WndProc
you can use hacks like this one which is tinkering with casting
you could use some detour mechanism as described in the answers here
Or you can get another component.
I have a base form with descendents. The base form has a TElRelDataSource on it (from ElPack v4.00). When I open the descendent form I get an error "cannot inherit from (parent form). Contains a component that does not support inheritance". This is with the ancestor forms open (there are two), to avoid the "ancestor for (parent form) not found" error.
Delphi 7 doesn't (AFAIK) support finalising classes, but this seems to be a standard error message. It's in the index for "Tomes of Delphi: Troubleshooting" but I don't have a copy of that and I'm reluctant to spend $US60 to read an entry like "this is why you should avoid VFI" (being pessimistic about the contents of the book). Other than that, no references in Google or Bing.
This is in code that I've recently inherited from someone who left a while ago and I'm the first person to change it since they left. Which means I can't ask how he created the offending form.
So, how do I get around this error message?
You got yourself into an interesting problem. First of all, you say the parent form already includes the offending DataSource, so you've got to ask yourself a question: How did the original developer manage to put the dataset on the parent form and then create child forms, if creating child forms is rejected by the datasource?
The original code didn't have the TElRelDataSource
This implies you're trying to add it your self. Don't add it, find an other solution that doesn't rely on the TElRelDataSource.
The original code did have it!
The original was probably compiled against a different version of TElRelDataSource, one that did allow inheritance. "Inherability" is controlled by the "csInheritable" component style. That is, if the component doesn't include "csInheritable" in ComponentStyle, the Delphi IDE will not allow visual inheritance. You have a number of options:
Use a different version of TElRelDataSource, maybe the original was compiled against a NEWER version of TElRelDataSource. If you are using the latest TElRelDataSource, the author probably decided it's code can't handle visual inheritance so he/she removed the csInheritable flag from ComponentStyle!
Try making your own derived component and set that style yourself. This is easily done, but if TElRelDataSource's author removed the csInheritable flag for a reason, you'll probably get into trouble.
Normally HeartWare's idea would work just fine; Unfortunately it's not that easy with a DATA SOURCE component: I assume you have DB-Aware controls linked to that data source. If you create the DataSource from code, you'll need to re-create the connections to data-aware controls as well, and that's going to take a lot of "if-s" (or clever use of RTTI).
You may try moving the DataSource to a TDataModule. This is probably more trouble then it's worth it.
One option would be to remove the offending component from the form and allocate it dynamically in the FormCreate event. Depending on how many properties the (presumed) non-visual Data Source component has, this could be fairly simple.
I need to switch every control of a particular type on a form to a different type while maintaining the name and the code associated with each control.
For example, let's say I need to switch a dozen or more TEdit fields to TSpinEdits. How can I do that in Delphi 2007 with minimal effort?
Use the GExperts Replace Components expert. It's free, and is the only tool I've seen that does what you're asking, including mapping properties from the old component to the new one.
If you don't feel like using any external tools, you could always try switching to view the form as text, then search and replace TEdit to TSpinEdit. When you switch back and save the form, the IDE should tell you that the declarations in the .pas file are incorrect and offer to correct them automatically. Property mappings shouldn't be a problem unless there are properties that are named differently that you want to map from one class to the other. Properties that don't exist on the new class will be deleted. This is how it works in Delphi 7 anyway...
If you're not happy with the results, you might try GExperts as recommended by Craig, which are a great addition to the IDE for many reasons.
I use the CNTools component replacer (couldn't find the one in GExperts), it's got a good Component Selector feature too so you can select multiple controls based one some simple queries.
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.