After installation of Delphi 6 at new working station I issued problem with breakpoints. In debug mode environment doesn't trigger breakpoints like they are not placed at all...
Have you experienced similar situation? I suppose reason is some setting, but I cannot find which one...
TnX in advance!
Nemanja
Yes, this sometimes happens (not only in 6).
Enable all debug information except debug DCU's unless you want to debug the Borland code. (Don't forget to check for compiler switches in the code).
Disable code optimizer.
Rebuild all code.
If you are using DLL's be sure to enable debug code in all projects and set the host application to the right executable.
If that fails.
Be sure that there are blue dots at the code.
Be sure you have the right source file. You can check this by adding an error (for example dghasgsgd) and recompile, if the compiler accepts, this is not the right source file.
Be sure the code is reached (add a SendMessage statement or a message box so you can be sure the statement is reached.).
Restart the compiler. Or even restart the pc.
If that fails.
Take a break. Have a lunch or get something to drink.
Return and show the problem to a coworker. (preferably a programmer too).
I applied all settings that #Gamecat suggested, so you can look at this answer like short addition to previous answer.
I missed only one more to solve my problem. In Tools>Debugger Options I checked Integrated Debugging which alive my breakpoints. When breakpoints started to work, I got error message 'Project _.exe raised exception class EAccessViolation with message 'Access violation at address 4CDEB080 in module 'IDPDX32.DLL'. ' For solving this issue I just unchecked option 'Stop on Delphi Exceptions' in menu Tools>Debugger Options>Language Exceptions.
Now Delphi works fine and don't need to reinstall it.
Reason for loosing my previous configuration that worked fine might be in copying my files from one folder to another (as well as config and other temp files) when paths became wrong and after that I probably deleted old config files and started with settings from beginning...
+1 Tip: If you get this message: [Error] RLINK32: Unsupported 16bit resource in file ....\estands\estandar_StdFormMainFrm.DFM problem is in Text-DFM option. When you right-click on the form in the IDE, is the menu item "Text-DFM" (or maybe called "Text as DFM") checked? If not, do so, save and try to compile.
If somebody knows reason for this behaviour, detailed explanation would be useful. Until now I found this option is for backwards-compatibility to older Delphi-versions.
Related
I've been working on an MVC 5 code first project for a few months and (seemingly) out of nowhere, Visual Studio is refusing to debug and giving me some strange errors.
When I try to run the application Ctrl+F5 it builds ok but the browser never gets beyond the loading stage, I still have the pinwheel in the browser tab, but the app never loads.
When I try to debug the applicaiton F5 it builds ok, but then comes up with 2 errors, firstly Debugging information for iisexpress.exe cannot be found or does not match. Cannot find or open the PDB file. and then Process with an Id of xxxx is not running.
I've tried loading symbols from MS (https://stackoverflow.com/a/8138518/1778169), using a different database name, uninstalling VS extensions, performing all Windows Updates, repairing the VS installation and even reinstalling VS entirely. Nothing seems to help.
I'm not very familiar with PDB files, but I have done nothing knowingly to change this, and they seem to be in the right place:
I am running out of ideas, but really want to avoid a Windows reinstall if possible.
It's only happening in this one project, so the problem would seem to be with the project itself, not the installation. But I have no idea where to start debugging this problem, or looking for a solution.
Possibly Relevant
I tried running the app on a custom domain (set up in the hosts file and IIS Express's ApplicationHosts.config file). In an attempt to solve this problem I reverted these settings back to the default localhost:[port]. This doesn't seem to have made any difference, but thought I should mention it just in case.
My problem was that the Native Code box was ticked in the Debuggers section of the Web section in Project Properties.
I don't know how this came to be ticked, I certainly never ticked it.
Either way, unticking this box solved my problem.
I've got a group project built in Delphi XE2 that has 3 projects that always build to the wrong folder for one option set. (I've got 4 configurations under Release and Debug, one for our software configurations and one for FastMM and it's only the debug one that I want to use for debugging that always goes in to the wrong folder. Compiling the project even says it's building to the correct folder, but the DLL always winds up in a different one which I only used once when I was unit testing the code outside of the main project.
I've deleted every associated file, .identcache, .res, .tvsproj (whatever that was) and nothing changed. One very strange thing I noticed is that I copied one of the projects to configure the second one and mimics the behavior of the one it was copied from and I never even unit tested that one, so it never had that output path configured for it.
Obviously this makes it pretty annoying to debug, I have to copy files in to the correct folder just to do that (I was kind of astonished when it actually worked, because I thought Delphi might expect to find the files in it's output path, but oh well, those things are magic)
Let me know if I can post anything to help, I don't really know what's necessary, I checked the registry for the output path that it is getting built do and found nothing that I thought was of any consequence (nothing related to these projects).
One thing I did notice was, because I copied the original project into another project (they're plugins to the same part of the main program) it has the same and when I try using it in the "Build Group" it automatically selects both projects. That's one mystery solved, but is probably a red herring?
OK so as usually happens, after 3 years of suffering with this when I finally ask the questions I'm lead straight to the answer it appears as if RAD Studio is lying to us. The configuration shows this:
but the dproj had this:
in it.
there were two conditions for cfg_3 and only the last one showed up in RAD Studio, well for some odd reason the build path was taken from the first one (even though it's specified in both). So, removing the wrong one (the first one) fixed the problem and things are now building to the correct folder.
I had imported the Utils option set when I was testing the library, but when I incorporated the program in to the main program, I removed it. Somehow it didn't find it's way completely out of the dproj and I guess (not sure why) but it seems like the other library got messed up because it shared a GUID.
I build my project, and there are no errors:
That's because the build succeeded without any errors:
This is a good thing. The application runs and everything!
Except there are errors
What the compiler doesn't tell me is that there are errors:
I just happened to have this file open. And i just happened to have the Structure viewer open. And i just happened to see the errors.
Is there a way for Delphi to report all error it encounters during a build?
Is optimization on?
No
It's no big deal for a simple one-form test application, with one error. But when i have 200 forms, XE6 starts to look as bad a Visual Studio 2012. I then have to be sure to manually open every code file and check if there are any errors in it.
Is there a way to get XE6 to report all errors?
#xe6usability
The compiler is correct. Your code does not contain an error. You have two functions with the same name, but declared with the overload directive.
The IDE's Code Insight, or Error Insight, or whatever the feature is called, is mis-reporting this as an error. This is an age old phenomenon. The IDE uses a different code parser from the real compiler. Indeed, if I recall correctly, it uses multiple such fake parsers. They are not as good as the real one, and not infrequently get things like this wrong. It's considered to be a minor inconvenience and that's probably reasonable. I'd much rather the real compiler got it right than the other way around.
Short answer: Turn off ErrorInsight, it doesn't work.
Click Tools, Options, Find Editor Options item in the list, expand it, find Code Insight, click it. Then unclick Error insight.
I have done all the searching and can't find a solution to this weird problem that's been bugging me for about 5 hours. I started this app in Lazarus, but then took it across to D5pro to see if I could solve the problem. Thought it might have been a Lazarus "thing."
In D5, I have an app fully-working (so far so good) and I decided to try some different approaches to the look and feel so I "Save Project As" into a new folder. I then went through all of the included Units and saved them to the new Folder. I copied the two OpenSSL .DLL to the new folder. Did a compile and run and it all works fine. Well, almost.
When I tried the new app, the POP3 Unit crashes at "Login"
I have stepped through and all of the basic login stuff, Server, Name, SSL parameters etc is identical to the former version.
I went back to the original app and did a full Build and it still worked fine. I did a full Build on the new app and it still crashes at Login.
It gets through the pop3.Sock.SSLDoConnect() OK, but comes back from pop3.Login() with an error 10061 which according to the BlckSock Synapse-Unit, means "Connection refused."
When it returns from this call Result:=ssConnect(s, #name, SizeOfVarSin(name)); which I assume is in the .DLL it has a Result of -1 which then triggers the GetLastError and that is "10061 - Connection refused"
As far as I can find, everything is identical between the two projects. All Library Paths are in the Environment and not within the project.
Any thoughts and suggestions?
There is not much to work with. Can you see all parameters in the debugger on the various external call moments?
A change of compiler of course can make hidden bugs come to the surface, just like e.g. optimization. A well known difference is that the life time of temps might vary (see here).
Probably you need to nail the defining difference first. As with Delphi, the debugger is your friend here.
OK, problem solved.
Sir Rufo, it was a good idea but it did not help, but thanks for trying.
I had copied the ssleay32.dll into the new app folder BEFORE I started compiling. It did not work. I did a full Build and it still did not work.
I decided to delete the ssleay32.dll and libeay32.dll and do a full Build. I ran it and of course it crashed, but this time I expected that.
I then copied the two .ddl back into the new app folder and did another full Build.
Bingo problem solved. Seems weird but it is working with both Lazarus and D5. Something to do with the way the .dll gets linked into compiled .dcu.
Doing the Build with no .dll available cleared that. Dropping the .dll back into the Folder and another Build got the .dll linking correctly included into the .dcu.
Aaarrggghhhhh :)
I recently refactored some code, and a method the original Global.asax.cs file was depending on was no longer static. When I made changes to my Global.asax.cs code to fix the compilation problem, VisualStudio Development Server is still reporting the old problem. To make things more confusing, it's reporting the old problem with the new source code.
When I start up the development server I get the tell-tale error screen saying:
Method not found: 'System.Security.Principal.IPrincipal Example.Records.AuthenticationManager.GetPrincipleForUserName(System.String);
This original exception was located at line 54--which shouldn't matter to you, me or anyone else. However, it matters to Development Server. No matter what I change the code to, even completely commenting out the original code, I get the same error message. The only difference is the snippet of code it displays. It's currently pointing to a comment line.
So DevelopmentServer is seeing the old compiled code and VisualStudio is seeing the new code. I can't set the breakpoint because VisualStudio is telling me the source code is different from the original version.
How can I force DevelopmentServer to see the new code that works?
I have since found the real reason why this occurs, and it also affects the "Symbols not loaded for this class" problem when you try to debug your application. The problem has to do with the path to the DLLs. If your web application is part of a larger solution, and someone edits the solution configuration, Visual Studio will alter the build output path.
By default, the build output path for Debug is located in the ~\bin\ folder. This is so that Cassini can find the DLLs and the PDB files. When someone edits the master configuration and changes the architecture, VisualStudio will automatically update the target output directory to "~\bin{architecture}\Debug". You have to manually go into the properties for your project and set the output directory to "bin\" for debug again. Once you do that, it will work again.
--- Original Answer:
The only thing I could do to make it work was create a new project and copy all my code in. It's not a good answer, but its the best I could come up with. Same exact code ran like a champ. After going through the project file line by line, I could not find anything that would explain the behavior I was seeing.