How can I remove the little sidebar to the left of the code in Visual Studio 2019? I mean the little minus signs that appear next to each function or code block header and, if clicked, minimize that function or code block.
Is there a way to disable these?
The feature is known as "outlining" and enabling/disabling it is language-specific. In all cases, use the "Options" command from the "Tools" menu and then, in the left-hand pane of the displayed pop-up box, open the "Text Editor" node.
For C/C++ files, the option is under the "View" sub-node:
For C# files (and also Basic, F# and Python), it's under "Advanced":
For other languages, it's likely to be in one or other of those places, but I can't guarantee that. In all cases, changes only come into effect on files that are opened after the option is changed.
If you have another specific language for which you can't find this option, just let me know and I'll try to help.
From time to time I lose breakpoint functionality in Delphi.
I thought this to be a Delphi 2009 issue but now I have also it in Delphi XE.
In Delphi 2009 by deleting .dproj file I made the breakpoints work again.
In Delphi XE I am not able to make breakopints appear. I have update 1 with all hotfixes applied.
Does anyone have a solution?
Debug info isn't present in the file.
Make sure that you're using the Debug configuration. (Project Manager tree, expand Build Configurations, make sure Debug is bold. If it's not, right click Debug and choose Activate from the context menu.) Make sure you then do a Build of your project, not just a Compile.
If that still doesn't work, go to Project->Options from the IDE's main menu, click on Compiling under Delphi Compiler, and check the Debugging section on the right half of the window. Make sure that Debug Information and Local Symbols are both checked. If you're trying to trace into the VCL's own source, also check Use debug .dcus (you'll want to turn this off and do a full build of your project as soon as you're done, as it gets annoying when you're debugging normally). Again, you'll want to build and not compile.
If all of the above fails, another possibility is that the code unit you have open in the Code Editor isn't the same one being seen by the compiler. Make sure you don't have multiple copies of the file on your computer in a location that the compiler might find first. If you're not sure, delete the .dcu files with that unit name and then do a build of your project, and see if the newly created .dcu is in the location you'd expect.
I found a better way.
From the Project Manager tree, right click on the project and choose "Clean" from the popupmenu.
The breakpoints reappear magically and it is a very fast method.
I suspect this happens when you have done a release build, with debug disabled. Then you switch back to debug configuration and do a compile rather than a build. The files where you can't set breakpoints correspond to those with DCUs produced by a compile with debug disabled.
Simply doing a build to re-generate all DCU files will make your breakpoints work again.
Here's one more reason to misaligned code vs breakpoint markers (blue/red "pill" in the gutter).
The editor recognices three different line endings,
CRLF (Carriage Return - Line Feed pair)
CR only
LF only
Of these, CRLF is the default in the editor.
The compiler however, doesn't seem to consider CR only as a line ending, only CRLF and LF only. Thus if your source file happens to have one or more CR only, the "blue pills" will be offset from the source.
You might have got source files with CR only EOL (end of line) character from e.g. the internet. I recall MAC OS used CR only as EOL.
To verify the EOL's in your file, you can turn on the displaying of EOL's in the editor
( Tools - Options - Editor options - Source options - Show line breaks).
The symbols look weird (see images below), but are just C on top of L for CRLF, C on top of R for CR and L on top of F for LF.
The following images show the normal EOL's (CRLF) and the EOLS's after I forced CR only for one line and LF only for another line in a hex editor. As said above, it is the CR only that offsets the break point markers from the source code.
Normal CRLF EOL's:
One line with CR only and one with LF only:
Fix
To reset all EOL's to CRLF, untick Preserve line ends in Editor Options
( Tools - Options - Editor options),
make a trivial change, so that the file is marked as modified, close the file, save changes to XYZ.pas? YES, and reopen.
Now all line endings are CRLF. Rebuilt the project and all the breakpoint balls will be in the correct locations.
Turning on remote debugging symbols did it for me (nothing else worked). Project > Options > Linking and check Include remote debug symbols.
I had the same problem with XE4. This is why I found this article a couple of hours ago. None of the above solutions worked for me. The correct solution for me - up to now - was to add "remote debug symbols" option. Strange because I don't use remote debugging. Anyway it looks OK now.
It is a bug, restarting Delphi will fix your problem.
Try remote debugging to your local PC.
Why it works: (source)
When you debug Delphi projects locally, RAD Studio does not use your RSM debug file because the compiler holds the symbol tables in memory. However, when you debug Delphi projects remotely, you must generate an RSM debug file that contains those symbol tables; otherwise, RAD Studio does not stop at your breakpoints.
Of course, you must first configure your project's "Linking" option "Map file" to "Detailed" to generate the *.rsm file. See Overview of Remote Debugging for how to get started.
I had a related problem: I lost the breakpoints in a particular file, but the other files were fine. What had happened was that I had renamed that file, but unknown to me the DCU for the old file was still being used because it was being referenced in a "uses" clause somewhere.
The solution is to manually delete all the DCUs (doing a "clean" is not enough because the old file represented by the DCU is no longer in the project) and rebuild. You will get a compile error showing the bad "uses" clauses.
Another reason for not working breakpoint could be (often tested with delphi5):
Too many procedures in a unit.
The solution is to move procedures to another unit
Although this is an old question I can confirm that this is still an issue in the current version of Delphi 10.3 Rio.
The answer above regarding line endings
https://stackoverflow.com/a/53360447/6445054
Solved the issue for me I had imported some very old Delphi code which had CR line endings
in a couple of places, as soon as I started moving code around the debugging broke completely.
The option to turn line endings on has moved slightly in Rio it's now
( Tools - Options - Editor - Source - Show line breaks).
In delphi 7 there seems to be a real bug on setting breakpoints.
I had a unit where many texts are definied in a
const constname : array[0..x] of record-type = (...);
in interface section, where record-type has some AnsiString items.
In the implementation section there are some procedures.
In some particular cases, when I set a breakpoint anywhere within a procedure, delphi does not stop at it!
Remarks: all options for debugging are set properly (as for F7 causes delphi stop at the "begin" of the program, blue dots are visible in the whole unit the line stays red while executing the app) and all DCUs that have according PAS files were deleted from all of my disks and within all folders, before I did a complete build on the whole project. So no wold files should hang around anywhere.
For testing, I renamed the PAS to another name, never ever used before, and surely nowhere else on any disk, then adapted all sources and recompiled, just to be sure that delphi and I are looking at the same PAS file - but the breakpoints did not work either.
But there another, very weird thing happened: the text consts (!) changed within my executable (not within exe file, but obviously within memory)! Those texts were checked for correctness during program start, and sometimes it complained about errors! Display of the texts in a messagebox showed, that there was changed a sinlge character within that texts, that are defined as const. For test, I tried to assign something to that consts within my code, but, as expected, compiler complained, so it cannot be an ordinary assignment that causes the change of the text. Must be a wrong pointer. Weird.
So, hours of testing followed, looking for any source code that might have set up a wrong pointer that later could cause that change in a text const. I placed the messagebox into the initialization section of the first unit within the chain of unit initialization I was able to edit, but the changed char was already there! Must be changed very early during startup of my application, then!
Finally I figured out, that the char that appeared in my texts always was an $CC - which exactly is the assembler code for INT 3, the code that delphi is using for setting a breakpoint. And when moving a breakpoint within that unit a line up or down, the position of the changed character also moves some chars left or right! And the number of characters the wrong one moved just correlated with the estimated amount of assembler coded bytes the concerned lines needed. Setting two breakpoint in lines near each other, suddenly two characters changed! When removing all breakpoints from that unit, the text remained unchanged!
So there's only one conclusion: delphi itself is changing that texts when trying to set a breakpoint and fails to do so. I was unable to get rid of this bug. None of the tips about re-synching delphi's internal bookkeeping of source and object code files did help me out!
As the concerned unit mainly consisted of {$I} lines between multiple {$IFDEF}s, for including some different, but long pascal texts, I considered delphi having problems on too long inclusions or on evaluation of conditional compiler directives. So I removed the includes and put the source text immediately into the unit, and removed the {$IFDEF}s - which compiled without errors, but setting breakpoints also changed my text constants, instead of stopping execution. All the same!
I solved this for now by splitting the unit into two units, one holding just the text consts in it's interface part, and a second one to hold the procedures. And now, without changing any compiler nor linker settings, all breakpoints do work like expected and not text is changed any more!
So, if breakpoints do not work for you, while you are sure they should, possibly delphi is the culprit and fails to set the breakpoints at the correct place. In case of it is changing just some texts, maybe that never gets to your attention. Splitting the unit helped me out, maybe that helps you, too.
If the file you're trying to set breakpoints in is part of a DLL, you need to make that DLL active by double-clicking on it in Project Manager so it turns bold, and then build it. Then the blue circles will show up next to lines where you're allowed to set breakpoints.
I solved my issue by making sure Debug was set to Local:
In my case, I was setting breakpoints in a unit that whilst open in the IDE was not part of the currently active project. Such breakpoints also show as green. IOW I was not on the right page at all.
(I discovered this after trying all of the above .)
If the project group uses packages (BPLs) ensure that none of them have any compiler warnings regarding implicitly imported units. If these exist you will only be able to step through the code via the CPU debug window.
Bit late answer but I stumbled on this problem too.
If I activated the MyPackage.bpl (bold) in the project manager with the debug configuration, then compiled it, I could see the IDE registered the debug information (blue dots on left of editor).
But when I activated my MainProject.exe (the one using MyPackage.bpl), those blue dots would disappear, indicating that the debug information is no longer present. After some head scratching, I realized that I did set up a dependency (right click on MainProject.exe -> Dependencies) on the Release configuration of MyPackage.bpl and not on the Debug configuration.
Each time I compiled MyProject.exe, it would link with the Release configuration, not the debug configuration!
So check your dependency configurations!
I had MSBuild checked under Delphi Compile (we do MS Builds). That was preventing breakpoints from working. Unchecked and it works.
By using F9 to run the app, breakpoints will work as expected. I am using XE4 and I do not know if this will "fix" prior versions of Delphi.
Since this is the best resource I found on this issue when encountering this problem with a new install of Delpi XE on a new laptop, I will just add in one more possible answer for Delphi XE.
If you are using a two monitor setup and the code editor window is on the 2nd monitor, the tooltips will not show. Works fine if the editor window is on the primary monitor. Very frustrating. May be a driver issue.
I followed the advice received in a previous discussion ( Should "Library path" point to the source files of packages? ) and now my Library Path points to folders containing the compiled code (DCU) and NOT to the source code of my controls.
The problem is that I have to duplicate the RES and DFM files and copy them from the 'source code' folder to the 'compiled' folder. It is not a elegant solution at all since, every time I change something (and I do often) to my controls I have to remember to copy the new resource files to the compiled folder.
There must be an elegant way to solve the mystery of the paths! All I want is to push the compile button and to have my program compiled. It doesn't seem so complicated. Right? Well, actually it work with my previous setup (point Delphi to source code of all controls). I just changed it to do it the way the 'good people' are doing it.
Addendum
I still think this is the wrong approach since Delphi's (scarce) documentation says that Library path should point to the "source files for the package".
Using:
Delphi 7, Win 7 (32), simple Delphi setup (single developer with no versioning system installed).
You have two solution:
Use a build tool to build and copy all files where they should be properly deployed (my preferred solution) after each build
Put the .pas/.dfm/.res directory after the .dcu ones. It will find the .dcu first and won't recompile unless you build, and it will keep on looking for .res/.dfm, etc.
If you look inside a D2007 project file (*.dproj) you'll see that the search path occurs multiple time for each configuration. There is
<DCC_UnitSearchPath>,
<DCC_ResourcePath>,
<DCC_ObjPath> and
<DCC_IncludePath>.
Maybe you can point <DCC_ResourcePath> to the source directory containing the resource files while you point the other variables to the DCU directory.
NB: I haven't tried this and can't check if the situation is different in other Delphi versions.
Though answers provided here by others are definitively good and correct (everybody receives a vote up), after experimenting a bit I decided to keep my previous (KISS) set up. It worked for years and it will work for many more. I know, it trades speed (recompiling the source code) for stability but it keeps the "paths, libraries, source, browsing and output folders" madness at bay. I just don't have to worry about settings paths anymore (except first time when I install Delphi but this can be automated) or to quit current DPR Delphi project and load a DPK library and compile it every time I add changes to it.
It's easy enough to find all your external dependencies. Just run the program and open up the Modules info window. But how can I find all my internal dependencies? I know the program keeps a list of all the units, because I've traced my way through the initialization code a time or two. But is there any easy way to access this list from the debugger?
The Delphi debugger can show you which units were compiled into a module (exe, dll or package). You can see this in the Modules view (View | Debug Windows | Modules). Click on a module in the upper left pane, and the lower left pane will show all the compilation units that were built into that module. If a particular compilation unit was made up of multiple source files (i.e a .pas and a .inc file), that will be shown too (when you expand the comp unit).
Alternatively, you can have the Delphi compiler show you a list of used .dcus by passing --depends when you compile a project. It will output a .d file with a list of the .dcus (and .dcps) that were required.
Another, but rather cumbersome way, is to generate a map file, it contains a list of all units used in a program.
see also this answer:
How can I find all the units in my Delphi app?
I use the GExperts Project Dependencies.
With the "Used By...", you can see units included but not used by anyone.
But you can't see unit included in uses clauses that could be removed when they don't have any code actually called.
Here's the help:
Project Dependencies
The project dependency expert enables you to see what units a particular unit uses, and in turn what units use a particular unit. When this expert is activated, it parses all of the current project's source code for uses clauses and builds up a list of dependencies. To view the dependency information for a particular unit, click on it in the left pane. The right pane will contain the dependency information. Indirect dependencies are units that are used by used units of a particular unit.
You can refresh the dependency information at any time by clicking the refresh button on the toolbar and you can sort the file listing by clicking on the column headers.
(source: gexperts.org)
OTOH, you can also use free Peganza's ICARUS as a more detailed reporting tool but less interactive...
Have you looked at Pascal Analyzer or the free limited version, Icarus, from Peganza Software? They will create "uses reports" telling you what module uses what others, so that should give you the info you're after.
Marc
GExperts has a Project Dependencies tool. I have used it before when trying to track down used units. You can't search in it but you can export the list to a CSV file and search there. This also only lists what is in the uses section. If you have a module included that is not being used it will still show up.
I know of at least two ways you could try to get a view of all the units used in your project
CTRL-SHIFT-B opens the object browser. If I'm not mistaken, here you can get a view of used units. I'm not entirely sure about this method and don't have Delphi available to verify it.
Use Modelmaker; Modelmaker can give you a tree like view of all your unit dependancies. Look at the Visualizing existing code section for more information.
The easiest way is to compile program and check which .dcu was created by compiler. Make sure to setup compiler to create .dcu in a separate directory, for example c:\dcu. I have created simple utility that searches .pas for every .dcu file in directories that are in a compiler search path (that can be read from .cfg, .dof or .bdsproject file).
You can use a MAP file in conjunction with MapFileStats, this will not just give you all your dependencies, but the amount of code (and resources) they contribute in the final executable.
Useful to spot units you have dependencies to, but use little of, as well as spotting "fat hog" units, which take everything plus the kitchen sink with them.
FWIW, reducing dependencies and eliminating hogs isn't just beneficial to executable size, it's also beneficial down the road when it'll be time to upgrade to a new version.
There is a (rather old) utility called UsgParse. It builds a treeview of all units referenced by a project.
I found a copy on the NexusDB site via
http://coding.derkeiler.com/Archive/Delphi/borland.public.delphi.thirdpartytools.general/2004-03/0231.html
source: http://www.nexusdb.com/downloads/USGParse/USGParse_src.zip
binary: http://www.nexusdb.com/downloads/USGParse/USGParse.zip
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.