Maybe this question is very specific for me, but I'll give it a try. Here's the scenario:
In Delphi XE2 the shortcut "Ctrl+Shift+7" toggles bookmark (likewise Ctrl+Shift+[1..9] for the other bookmarks)
I have installed ModelMaker Tools (v. 9.1.0, but I believe I had this error earlier also), where I have assigned the shortcut "Shift+Ctrl+Alt+Y" to "Sync Declaration/Implementation".
Whenever I use the ModelMaker shortcut I also set the bookmark (7). Why is this? Note that contrary to the "real" shortcut (Ctrl+Shift+7) the bookmark isn't toggled, only set.
This behaviour puzzles me. Does anyone have an explanation? It's not a big problem, since I rarely use that many bookmarks, but it got me curious.
For a couple of refactorings, ModelMaker Code Explorer sets some bookmarks for your convenience.
It is documented somewhere, but I forgot where (:
Edit: it is documented here.
All refactoring operations that modify the IDE edit buffers
(optionally) drop bookmark #7 at the current cursor position. Similar
to how Extract Method drops bookmarks #8 at the original code and #9
at the extracted method. The bookmark numbers can be customized on the
History Tab which also allows disabling dropping specific bookmarks.
Related
After years of Delphi development I now have hundreds of forms shared throughout our Applications. Compilation ranges from Delphi 7 through to XE, thus one form might be opened in any IDE. The well-known Explicitxxx property addition after Delphi 7 has solutions to avoid a form accidentally acquiring properties that earlier compilers can't process (e.g Andreas's DDevExtensions) but I'd like a more positive 'switch' that prevented Delphi from making or saving any form modifications at all. Period.
Of course you could use the read-only flag, and a version control system provides additional means particulay of seeing that such a modification has occured. What I'd really like though is a {$LockDFM} switch that I could put in the form's unit, or a context menu option when viewing the form layout.
Can anyone think of a neat way of achieving this?
Thanks
The only thing I can think of (other than the read-only/VCS options you mentioned) is the Edit menu's Lock Controls option. This sets a flag that prevents controls from being moved around. I'm not sure how much good it would actually do, as I've never tried it; I just know it's there.
Helo
I am pretty sure that Delphi has no such a thing. I have been searching for a solution to this problem as well.
But, theres one thing you can do: You can write your own Delphi addon using OTA (Open Tools API). I know that there are a few classes which are able to notify you when something are about to be saved. You can intercept this event and decide if you wanna save it (in your case, if it is a DFM).
BTW, if you have plans to do such component, tell me. :)
EDIT:
I have found a piece of code that may help you. Extracted from http://www.gexperts.org/otafaq.html
TMyFormNotifier = class(TNotifierObject, IOTANotifier, IOTAFormNotifier)
protected
procedure FormActivated;
procedure FormSaving;
procedure ComponentRenamed(ComponentHandle: TOTAHandle; const OldName, NewName: string);
end;
In design time there is Edit->Lock Control.
LE: this is only for resizing/repositioning the controls on the forms. Concerning the ObjectInspector I don't know if there is anything that can 'lock' the values set there(so the developer can not change them).
Basically, no. Aside from the f'ing (pardon my french) explicit size and position properties which IMO never should have been in the .dfm, there are some third party components will change stuff just by you viewing the form. F.x. TMS components will update a version number even if you didn't change a thing since the previous version of their components.
We used Delphi 6 long times ago. Our problem, that Delphi have two problems with DFMs:
1.)
When some linked resource (like DataSet) will removed, Delphi many times forget to ask you that "some of the resources are linked, you need to redirect...". This happens, when the actual form is not added to the project, or it is not opened.
2.)
When we only open the DFM, and only see some thing, may we change it (active TabSheet, form position).
Then Delphi auto save the form - and sometimes it drops the links.
Another problem with this that we used SVN, and SVN detect these changes...
We thought that we change DFM files to read only, but this can prevent the usage of SVN too...
So somebody please help us: have the Delphi some extension (like gexpert) that can lock the DFMs to avoid changes, and some other tool to see that dataset is used in other forms or not?
You're kinda cheating on Delphi. It is built to manage the duality *.pas and *.dfm altogether, knowing how to maintain the links (and with form inheritance, it's better to have all the stack open).
If you want to manually interfere, you have to know what you are doing and do it very carefully. You're not supposed to fiddle with the dfm insides more than to edit the form code portion before the private section.
What I do when I have to edit the dfm manually is to make sure it's not open in any way in delphi (beware form inheritance) and then edit it in another editor.
Also when I check the pas/dfm back in, I do a diff on the dfm to make sure nothing bad happened to it.
In Delphi 2010 a new Find bar has been added beneath the source editor.
Though I sounds like a good idea I find it prettry anoying when F3 should be pressed multiple times for finding next matches. It works from time to time for me.
How I can switch it off and use the old search fnctionality?
It is not possible to switch back to the old modal behavior. That code is gone. If you’d like to see all the results in a list, you can use “Find in Files” and choose either “open files” or “files in project” to keep the number of files being searched to a minimum
Depending on how reliant you are on the latest versions of the VCL components, you may be able to run a slightly older version of the IDE as your editor, and use command-line compilation to compile your code using Delphi 2010. I have in the past mixed and matched IDEs in this way, but admittedly this is more difficult if your software is component-heavy, so to speak.
Edit: Moved my comment.
In a Delphi 2007 program I am using a TMainMenu referencing actions in a TAction list. I have prefixed the hotkeys of all main captions with an ampersand:
&File | &Edit | Ev&aluate | ...
In design view these hotkeys are underlined as I would expect, but when I start the program they no longer are underlined but they work nonetheless. In contrast to this, for all the submenu icons
&File
&New ...
&Open ...
the underline is shown as expected.
I am aware of the Windows pisplay properties option "Hide underlined letters or keyboard navigation until I press the Alt key." and have disabled it. In all other programs this works fine, including the Delphi IDE.
If I create a new VCL appliation and just add a TMainMenu and a few menu items, it works as expected.
This has me baffled, really.
Is there any property of the TMainMenu component or maybe an application option that I must change? The "Enable runtime themes" project option is grayed out for some reason, might that be the problem? If yes, what causes this?
This may not be a Delphi issue. I have just tried this with IE8 on WinXP. On my machine, with the display properties set to require the Alt key, the underlining works as expected. However, with the checkbox unchecked, the underlining never appears on the main menu items (even when using the Alt key), but always appears on the File,Edit,View etc submenus (as you describe) ........ unless Microsoft wrote IE8 in Delphi :-)
I asked the same question last year and there were some excellent answers:
Menu Accelerator Keys Not Showing Up Delphi 2009
In conclusion, it appears to be a Delphi bug, and I reported it to Embarcadero at:
http://qc.embarcadero.com/wc/qcmain.aspx?d=68816
However, they have no resolution to it, so unless others (maybe you) also complain, I don't expect it will get addressed.
Step's answer to my question refers to a possibly related bug reported on the Delphi forums:
ALT Key press causes controls to disappear under Themes in Vista and XP. This one is marked as "resolved" with several possible fixes listed in the comments. I have not had the opportunity to go through these.
By the way, since I asked that question last year, I got a new computer with Vista. The same problem still happens, even when the Vista Ease of Access Centre setting: "Underline keyboard shortcuts and access keys" is set. So the Delphi bug still exists.
I was very surprised to find the default was that this was unchecked. I guess in Vista, they want a cleaner looking menu with the assumption that not many people ever used the accelerator keys.
The easiest way to fix this problem seems to use TJvMainMenu from the jvcl instead of TMainMenu. I tried the current version 3.38, but it is possible that the problem was fixed already in earlier versions. Since I was using the jvcl anyway it does not add much to my program's size. Your mileage may vary though, the jvcl is a huge library.
Uses an empty image list for main menu, if it is possible. In this way you can force delphi to paint menu correctly. (But looks ugly in vista and w7)
Are you sure you don't have OwnerDraw set to true in the MainMenu?
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.