Delphi sets the name of components when you add them to a form. The first TButton will be named "Button1" the second "Button2" and so on.
A while ago I discovered by accident that you can change this "prefix". Staying with TButton I changed it to "btn" so TButtons will be named "btn1", "btn2" and so on.
Now I want to change some more component prefixes but unfortunately I forgot how to do this. It could be some functionality of GExperts. Anybody to the rescue?
Just if it is important: I'm using Delphi 10.2.
In GExperts it's called "Rename Components":
http://www.gexperts.org/tour/index.html?renamecomponents.html
To get there you have to open "GExperts Configurations" and click on "Configure" button at the right side of "Rename Components":
http://www.gexperts.org/tour/index.html?gexperts_configuration.html
There is the same functionality in CnPack in "Prefix-master"
I can be wrong a little, because I prefer CnPack, but they are similar enough, I think.
Related
I'm getting a weird error at compilation when I try to set the Parent property of a BitBtn that's been created at runtime. Using Delphi 7 on Win7 64bit.
[Error] unitMainForm.pas(70): Incompatible types: 'TWidgetControl' and
'TMainForm'
I'm creating the BitBtn at runtime like this:
newButton := TBitBtn.Create(Self);
newButton.Parent := Self;
"Self" here being the form, named "MainForm".
I'm getting this no matter what I put for a Parent. I've tried putting the current Form, ScrollBox, Panel. The same happens if I try to create a SpeedButton.
The thing is, my code works as expected when I use TButtons, and even TImages, but not with TBitBtns or TSpeedButtons. TButtons and TImages accept the Form as their parent, and show up as expected.
Any ideas?
If it helps, I could provide a sample of the whole code, upon request.
You are mixing CLX and VCL. Your button is the CLX TBitBtn, but your form is a VCL form.
I don't know whether you want your app to be a VCL app or a CLX app, but whichever it is, you need all the parts of your app to come from the same framework.
My guess is that you want a VCL app. And somehow you have used QButtons, the CLX unit, rather than Buttons, the VCL unit. And that's why you are getting the CLX version of TBitBtn.
So, assuming I'm guessing right, simply change QButtons to Buttons and your code will compile.
I'm trying to build a simple 2 columns grid "property editor" based on VirtualTreeView.
(I want to mimic look and user experience seen on Delphi's IDE object inspector)
The component is working almost and can handle multiple editors,
but I'm facing an annoying bug :
When I click on a new node (a new row), the node is selected and the editor appears, regardless of the column I've clicked on. It's expected and OK.
Then, when I click on the first column of the same row, I expect to see my editor content validated and the editor keeping focus (like in delphi's object inspector).
But the editor content is validated then it disappear and the entire node (row) is selected. The editor won't get back (even if I click on second column), until I select another node and click back on the previously selected node.
EDIT : added illustration and precision about my code.
about the code :
I do not have inserted code here because I used (as a starting point) the exact same code as the one found on Advanced Demo (properties page)
What I tried and found out :
the 2003's compiled Advanced demo (properties tree page) found here seems to works like what I expect from my component (and from virtual treeview).
But when I compile this same demo (I tried with versions 4.5.2, 4.8.7 and even 5.0.0 from current trunk on google code, on both delphi 2007 and 2009) the bug reappears !
I first think there was a documented breaking change between 2003 and more recent versions,
but I can't find anything.
I've also played with all available options trying to solve this, but without success.
I still don't know if this problem comes from new delphi RTL or a breaking change (bug?) in virtualtreeview.
so my questions :
do you have the same problem when compiling Advanced demo ?
any tip or workaround in code to solve my problem ?
As a side note, I nearly give up with virtualtreeview this afternoon and I wanted to try a solution with another component... I found this interesting question and decided to try berg's component, but was stopped in the buying process when reading an advice on their homepage (see my comment on the related question)
The VSTs onChange just gets called by changing the selection of nodes. The state will not change anymore, if the node is already selected. So, you have to implement a behaviour similar to Object Inspector on your own, e.g. by calling VSTs EditNode()-Method in the OnClick-Callback:
procedure TMainForm.VSTClick(Sender: TObject);
var node: PVirtualNode;
begin
node:= VST.GetFirstSelected();
if(node <> nil) then
VST.EditNode(node, EDITABLE_COLUMN_INDEX);
end;
I am using Delphi 2010 and GExperts stable release 1.35
I am testing the "Replace Components" expert.
I add a main form and a secondary form. Each has three TEdits on it.
I use the Replace Components Expert to replace all TEdits with TRzEdit. I Check the Replace all components on all forms of the project.
It works, it replaces them all. However, it doesn't do anything to the DFM file. How do i make it replace those instances.
If i save, compile, or rebuild, i get errors.
If i try to view the form as text after replacing, i get errors.
Can someone explain to me the steps to make this work?
Thanks
I just tried it with Delphi XE and GExperts 1.35 and it does indeed crash now even after a single "Replace Selected". (It used to work fine in the past).
It seems that using the hidden menu Project | Clear Unit Cache just after Replace Components then doing a full build before trying any Save/Compile/View As Text... fixes the problem.
I think this menu is surfaced with cnPack. I don't have it and cannot guarantee, but you can easily do it yourself by adding the following unit in one of your installed packages:
unit FGEnableHiddenMenus;
interface
procedure Register;
implementation
uses
Classes, Forms, Menus;
procedure Register;
var
Comp: TComponent;
begin
//Make a hidden menu item visible
Comp := Application.MainForm.FindComponent('ProjectClearUnitCacheItem');
if Comp is TMenuItem then
TMenuItem(Comp).Visible := True;
end;
end.
Source: Brian Long's old goodies
Update:
I had to replace a couple of TEdit by TDBEdit on our main project at work and this trick worked.
But on a new Project with 3 Forms, it failed consistently to write/commit/save the changes on the last Form (same environment).
FYI, I tried with and without DDevExtensions 2.5 and IDEFixPack 4.6.1
Update2:
Went digging in the GExperts forum as suggested by Ulrich and finally found a possible explanation. The new property Touch does not like being copied from one component to another when the source is destroyed (causing the AV).
The suggested workaround is to do a bidirectional mapping in the Expert Settings to disable the copy for this property:
You might be running into this bug while trying to copy the Touch property from the old to the new component, but it has a workaround you can fairly easily test:
http://tech.groups.yahoo.com/group/GExpertsDiscuss/message/3994
Details:
There is a limitation/bug in Delphi 2010 and XE where if you assign a
Component.Touch property from one component to another and destroy the
original component that the new component becomes corrupt (it isn't
like component/interface references, where they either auto-correct
themselves or are reference counted).
For the moment, you can assign a bi-directional replace component
property map from TPanel.Touch to TGroupBox.Touch (use the two components being replaced in your specific case) that is marked as
a disabled property map, and that will work around this problem. Our next release
will not try to assign that property any longer.
GExperts 1.36 is also now available and includes a workaround for this issue. The workaround has been in the GExperts version control system and in testing for several weeks already.
I have two forms(one main form,and one submain form).I'd like to do something like CodeGear's IDE panels on drag-and-drop.Meaning I could move them and they merge with other components.
However,I'm asking for something different:
I'd like to drag the submain form into the main form and to turn it into a something like TFrame or,in other words,something that doesn't move,but stay static.And reverse - I'd like to alo be able to get the form out of the TFrame by any chance.
Is my idea possible and if it is,could you explain how to accomplish it?
EDIT: An idea came to my head.Is it possible to create a TFrame that inherits all controls/components from a TForm so that components stay on the form,but when I attempt to turn it into Tframe,it just changes visibility to false and shows the TFrame contaning everything from the Form.Is that possible?
Set the main form's DockSite property to True, and then handle the OnDockOver and OnDockDrop events.
You can see an example of the VCL's drag and drop docking support in the Docking demo (installed for Delphi 2007 on WinXP in C:\Documents and Settings\All Users\Documents\RAD Studio\5.0\Demos\DelphiWin32\VCLWin32\Docking, for Delphi 7 in C:\Program Files\Borland\Delphi7\Demos\Docking.) Delphi 2009's will be in the same folder location as Delphi 2007's; just change the 5.0 to 6.0 in the path.
I am getting a cascading set of "EClassNotFound" errors in in my Delphi 2007 project. Doesn't seem to be caused by the missing Name property value as often is the case, and though adding RegisterClass(XXX) in the initialization section(s) fixes the EClassNotFound error at hand, another one follows it seemingly indefinitely.
I finally cracked open the DFM file in text editor, and it looks likely corrupted to me (lots of non-ASCII characters amidst form element names, and very "unstructured" looking when compared to what I'm used to seeing in a DFM file). (I'd post a same here but not sure that's OK, w/the non-aSCII, so will hold off).
The form loads fine, and seems to compile / syntax check OK too, but once I run it, trouble.
Going back to early versions of it in SVN, it looks like it's been in this state for some time, which makes me think that either A) the DFM file isn't my problem, or B) the Delphi form-streaming is quite fault-tolerant/robust (Bonus Question: Which is it?).
If the DFM file is the problem, and is corrupted, rolling back will have to be a roll-back WAY back, and that's gonna be expensive. Given that the IDE can still load it, is there any utility that can clean up the file?
Or, am I totally off base w/the DFM as primary suspect?
Thanks folks for the input. Forgot about the binary/text options w/DFM files, so that was helpful. It looks like the DFM itself is not corrupted.
Still having the EClassError issue though. re: It being missing property values, or referencing non-existing properties, etc., a further question: Is the class the error is given for (currently TnxSqlUpdateObject, but probably more waiting in the wings if experience thus far is consistent) usually/always the actual "culprit" class/object?
For instance, right now my main form has four references to TnxSqlUpdateObject, w/those actually dropped on the form. If I put RegisterClass(TnxSqlUpdateObject) in the initialization section, it runs fine for that EClassNotFound error but then goes on to the next one (in this case, TStringField).
I have reinstalled the NexusDB components in this case, and also built a new project using some of the components I thought might be the problem. It compiles and runs fine, UNTIL I add this other form from my real project (which, in turn, unfortunately references quite a few others).
SO, it sounds like my real issue is how to methodically diagnose and fix any and all EClassNotFound errors?
I get this error if a component is on the form, but doesn't have an entry in the form definition in the source file too. Most often when I've copied and pasted from another form. Simplest solution is to select the component, cut it, then paste it back. When you save, the component's unit will be added to the source, and when you run it again it will all be okay.
Well, a dfm file could be binary or tekst (as I'm correct from version 4.0).
You can check this by right click on the form and check the Text DFM flag.
If a dfm file is corrupt, tou can try to fix it by removing all suspicious lines.
Be sure to leave the object .. end sets intact and you probably only loose some property values.
By the way, the dfm file should look like this (to get an idea of the general structure):
object Form5: TForm5
Left = 0
DesignSize = (
426
652)
object Button1: TButton
Left = 343
end
object Memo2: TMemo
Anchors = [akLeft, akTop, akRight, akBottom]
end
end
If it does not look like that you are probably editing the binary file.
If you have a recent compiled exe that works, you can use a resource-editor, like PE Explorer, to get the dfm-definition. Then you can compare the one from the exe with the one that you now have.
I believe there is tools to convert binary dfm-files to text-files too. This will give you a better view on the file, and help you decide if it's really corrupted or not. I see Felix has something on the topic.
If the Delphi IDE shows the form ok without errors, I can't believe there is a corruption-error. Could there be a package problem? Do you use runtime-packages?
Update:
Hvae you tried Eurekalog or madExcept or something similar to get a more detailed error message with callstack and memorydumt? Maybe that will give you some clue about the problem.
But generally i think this error comes from missing runtime package, or a missing unit in the uses-clause. If you think you know witch component causes the error, search the source for the call to RegisterClass( ), and see if that unit somehow is included in the projcets uses-clause. If not, add it and try again.
If you can load the form in the Delphi IDE the DFM resource is not corrupted. Delphi uses the same code to load the DFM as the final executable will use, so I think that won't be the reason.
You can open the DFM in the Delphi IDE directly (if the corresponding pas file is not open), or you can use Alt+F12 to switch between form view and text view of the DFM. In this view the structure should be sane, with correct indentation and so on.
As Gamecat pointed out you can use the command in the form popup menu to toggle the DFM storage format. Leave it as text for Delphi 5+, it works better this way with SVN.
As for the cause of your runtime problem - I have no idea...
Edit: After your ruling out the DFM as the source of the problem I can only assume that an important unit in the uses list is missing, which can only happen if not all the components on your form have a corresponding member field. You should check that all the components referenced in the DFM are also in the form, even when you do not access them in your code. This will in turn cause Delphi to add any missing units to the uses clause when the file is saved. Manually registering components should not be necessary if the form class has references to all the components in the DFM.
For a quick check you could create a test form, drop all of the components that your "problem" form has onto it (one instance is enough), and check whether this works.
This can happen in case you have changed one of your custom components and removed a property from it. The property is stil in the DFM and Delphi tries to initialize it.
Try to remove manually parts from your DFM so you can pinpoint which component is causing the problem.
Try this:
Make backup first
Right click on form in designer; uncheck "Text DFM"
Save
Right click on form in designer; check "Text DFM"
Save