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.
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 have deveoped a custom file type, together with a custom editor (basically a tree with several data pages attached and a few extra buttons). OK, I can run it stand alone and that is fine, and even add it to the tools menu, but I would like to integrate it into the Delphi IDE so that my custom editor (or a similar new version) appears in the IDE, rather like a DFM file has a custom editor. I can find references to most extensions in the Delphi IDE, but not this one. Any guiding hands? Note that this is not a property or component editor (the file type has nothing to do with either of these) nor is it simply syntax highlighting of a text file.
AFAIK it currently isn't possible to reliably integrate a custom editor into the Delphi IDE. The required API simply isn't there. See QC89028 Custom Module support.
During the Delphi 2010 and XE betas I spent most my spare time trying to get a resource editor integrated. Although the effort had the official blessing of Embarcadero and got some, half hearted, support from the IDE engineer, I was never able to get them to deliver on their promises and surface the module API. I eventually abandoned the project.
Update: I've now checked my old correspondence regarding this and it turns out part of the problem was that IOTAModuleCreator (used to implement File|New for custom file types) and IOTAEditorContent (used to transfer data to/from the custom module) only supports text data. Binary data gets mangled.
You can probably do this via an IDE plugin that uses the ToolsAPI (see ToolsAPI.pas in the IDE's source folder (e.g. Program Files (x86)\Embarcadero\Studio\source\ToolsAPI\ToolsAPI.pas.)
For information on writing a plugin in general, see David G Hoyle's excellent blog. Once you know the basics - i.e., write a 'wizard' and get it to do something - you will need to work on integrating your editor.
I have never done this, and so I can't guarantee it is possible. However, some interfaces that look worth investigating and implementing are INTACustomEditorView, which represents a 'view' (file tab when that file is open - think the code editor, Welcome view, type library editor, etc) and IOTAEditorViewServices, to register your custom view. I do not know how you associate a view type with a file type, sorry - possibly something to do with the personality interfaces. You might also be interested in INTACustomEditorSubView which is what creates a tab on the bottom of a file.
Good luck, and if you find a solution please write here so that other people can learn too!
Some people are saying that I must update the controls in Win3.1 palette (especially TFilterComboBox) with modern ones. But does Delphi provide such new controls?
I need to create a GUI (somehow similar to Windows Explorer, consisting in a DirectoryListBox, FileListBox and a FilterComboBox) where I allow the user to easily explore for files of a specific type. Since the interface is centered around this Explorer, a TOpenDialog will be like hitting the customer with a hammer in the middle of his head. I need an 'easy to use' solution.
Unfortunately Shell Controls are not stable enough to be used as replacement.
The Shell Controls that come as a demo with Delphi only have to be installed, and you'll have some nice shell controls. There is, IMO, no big need to get 3rd party components for that.
Look for ShellCtls (or similar, can't check right now) in your demos folder. That Demos folder can be accessed from the Windows Start menu for your version of Delphi.
Update
They are not in a Demos folder, it is called Samples now. They can be found in Samples\Delphi\VCL\ShellControls. Install vclshlctrls.dproj first and then dclshlctrls.dproj.
In our application we use tpShellShock which works rather well. You may need to tweak it a little for Unicode Delphi, but if I recall correctly that was pretty simple to do.
Here's what it looks like:
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?
Following up on this question, I'm working on a large Delphi 7 codebase which was not written very nicely.
I'm looking at code like this, as a small example:
if FMode=mdCredit then begin
Panel8.Caption:='Credit';
SpeedButton3.Enabled:=false;
SpeedButton4.Enabled:=false;
SpeedButton5.Enabled:=false;
SpeedButton5.Enabled:=false;
SpeedButton6.Visible:=False;
SpeedButton10.Visible:=False;
end;
Followed by another 6 very similar blocks. The whole thing is in this style.
So I'm thinking that this would be much easier to read if the controls were named sensibly.
I could just use a global search and replace, but I'll run into problems when multiple forms use the same names, and also I'd have to be careful to change (eg) SpeedButton10 before SpeedButton1.
Is there some plugin which has the ability to perform a "smart" rename for me?
Edit:
Sorry, I should have mentioned this before: I tried both GExperts and Castalia's "Rename Component" feature, but they both seem to be intended for use when adding the component to the form initially.
They don't do a search+replace in the code, or rename existing events (SpeedButtonXClick() -> cmdCreditClick()).
Have I missed something?
Not exactly a plug-in, but you can use one of the more recent versions of Delphi and the refactoring feature in there. Maybe you could use the free Turbo Edition . . .
You might try ModelMaker for Delphi 7. It has refactoring support that might work for you.
The Rename Symbol refactoring in recent Delphi versions will work across units in a project. Since you say Delphi 7 I guess that's not going to help you, and in the past I've just used TextPad, a great editor that (like many others) will do powerful search/replace across files (with or without confirmation).
HTH
Edit: Craig's right - GExperts will do this, as will Castalia.
I think GExperts has a search and replace like this.
Don't know if it can work in your case, but you could try to load your project in a later version of Delphi that has the refactoring capability and use it to change the components names while taking care of all the dependencies. Then you just have to do a diff and see what has been changed.
Why not use Sync Edit? Its part of the IDE (at least in 2006+):
The Sync Edit feature lets you simultaneously edit indentical identifiers in selected code. For example, in a procedure that contains three occurrences of label1, you can edit just the first occurrence and all the other occurrences will change automatically.
(copied from the BDS2006 Help)
You will have to rename your components first, but it takes the pain out of most of this. I prefer the GExperts wizard of renaming components as they are added to the form, but as you pointed out, it only works when the component is added to the form, and doesn't reach into the individual usages of the components in code. The reason for the renaming of the components first is that when you select the entire block of code to do the rename, it won't make the appropriate changes in the dfm file...just your locally selected code block.
To use the feature, select your entire implementation block, then press the button in the gutter that has two pencils "linked" by a line...then press tab until you get the first one you want to edit...when you change its name, it will change globally in the rest of your source file. Press ESC when your done.