I'm pretty much at my wits end at the moment.
I am using Delphi 2009 (Update 3) on Vista (service pack 2) and without fail, if integrated debugging is enabled and I try to run a project, it will give an access violation and the project will crash out.
This happens even if I haven't even added any code to the default project template.
The only way I get around this is by disabling the integrated debugger, (then I may as well just be using a text editor and a command line compiler...)
Does anyone have any advice for this? I've been googling without much success.
Thanks in advance.
I have used this combination without any problem.
Have you tried at at a clean machine (just installing delphi and try a "hello world" application?
Go to Project > Options, Compiler tab. Uncheck Optimization, check stack frames. This seems to be the usual advice in the faqs on Delphi debugging. It may only apply to the earlier versions of Delphi but is worth trying.
Related
We use Embarcadero Delphi 2010 and recently a change was made to one of the units of a medium-sized project, causing code completion to stop working completely -- but only inside this project, it still works fine in other projects. Puzzled, I searched the interwebs for clues on what exactly could make this happen, but my search wasn't too successful.
From what I gathered, it looks like IDE has a few parsers/compilers that work completely separated from one another, which makes it entirely possible that the faster code-completion compiler could fail where the main compiler would not. Which is exactly what's happening to my project.
My question: Is there a way to find out WHERE exactly the Code Insight/Code Completion compiler is failing? Does the IDE keep a log of on-the-fly parsing/compilations anywhere?
Is there a way to find out WHERE exactly the Code Insight/Code Completion compiler is failing?
Not readily, not without debugging the IDE.
Does the IDE keep a log of on-the-fly parsing/compilations anywhere?
No.
I suggest that you install Andy Hausladen's IDEFixPack. If that does not help then use your revision control to isolate the code change that causes the problem. And find a different way to write that code that happens not to bork code completion. Trial and error is likely to be the most productive method here, much as I hate to say that.
I recently had the same problem using Delphi 10.2. After a lot of research I found that I had inadvertently declared a variable in a type section with an end; following on the next line. Removing the errors restored the code completion function. So I would recommend combing the interface for an error or restoring a backup from the directory history.
I found interesting problem with Win7/X64 machine.
For this time I haven't got problem with Delphi 6 and UAC.
The exes are working in their's place, so I can use Delphi debugger with them.
But today I got error on run the project: "Unable to create process. For this operation you need higher user level".
How can I prevent this side-effect?
What causes this?
I don't understand why the older projects are running fine, but this new isn't...
Thanks for every idea, link, information!
Additional info:
Normally I using the Delphi 6 IDE with normal starting (without SysAdmin rigths).
So it is never asking me with "really?" kind UAC questions.
And every of the older projects are usable with Delphi 6 - I can build, run, debug everything.
This problem happened with only this project, so I try to find the differences if possible to solve the problem.
I using normal directory ("c:\dev\anyproject"), others are using "c:\dev\otherproject1..2..n").
Does your application request elevation when started from Windows Explorer?
Does it have a manifest?
The name of the exe, like setup.exe, could also trigger elevation. See an outline of the Installer detection technology.
Non-elevated process can't debug elevated process.
If your application requires elevation at the start, then you would need to run the IDE elevated to be able to debug it.
Starting your IDE as an administrator should solve the problem (option in the context menu).
If not, you could always disable UAC while developing.
There is a number of limitations that needs administrator's rights.
For example: you cannot write data directly into program files directory.
I'm using TJvPluginManager in the JVCL to create and load BPL-based plugins for my program. Problem is, one of the plugins isn't loading properly, and I can't debug it. Every time I try to trace into the loading sequence, it gets as far as the LoadLibrary API call, and then the debugger seems to forget what it's there for. It completely loses the ability to associate program code with source lines, give meaningful data in a call stack, or display local variables. It will still stop at breakpoints, but it breaks to the CPU window, with all the inline source code stripped out.
This happens on Delphi 2007 and 2009, and it's driving me nuts. Does anyone know how to load a plugin without it breaking the debugger? Does anyone even know why it's breaking it in the first place?
NOTE: I'm not looking for alternative methods of debugging. I know all about tracing and logging and all the rest. What I want is to understand what's going wrong and how to fix it. Surely I'm not the only person who's ever used TJvPluginManager?
Not quite the answer to your question: Have you tried to debug the package project, by setting the host application and putting a breakpoint into the package's startup code?
I've found Ray Kanopka's (Raize) CodeSite to be invaluable for debugging in situations where the integrated debugger is acting up. Thinking about the things I want to monitor using CodeSite actually helps me focus on what's important - it enforces good habits.
Another alternative to Codesite is Overseer which is part of the nexus project, but stands alone so does not require you to use their framework. Codesite is by far the better option, but in a pinch Overseer would work just as well.
I found that using packages for plugins can be problematic and many years ago switched to a completely COM based implementation for plugins and never had any problems. The other advantage to COM based plugins, they don't require Delphi to write, do not need to be recompiled when the main app switches to a new version of the compiler (my plugins compiled with Delphi 5 still run fine against the main application compiled in Delphi 2009!) and they are easier to write test applications to assist in debugging.
The only side effect I notice, is that shared code ends up in both executables and the plugins require registration into the registry.
Hmmmm... This is a stupid question, but I have to ask: the initialization function have the EXACT declaration syntax like the other plugins that work ?(from your question, I deducted you made some others that work)
Check your dependencies. Make sure each unit is compiled into one package only. Whenever a package needs to reference a unit from another package, use the requires clause to do so. Watch for compiler warnings about implicitly linked units.
Here's the situation:
A user of our program suddenly started receiving an error from the Borland Database Engine (BDE) when attempting to start the application. The error message says that it was unable to initialize the BDE and gives error code $251e. User is on BDE 5.2.0.2.
I cannot find any official documentation on the error $251e. The only somewhat useful hit I can get on Google is not very instructive and the suggestion there does no good.
Here are some things that we have tried / discovered:
Other applications that access the BDE the exact same way have no complaints.
The error occurs on a line where we set Connected := True on the TDatabase component.
Reinstalling the BDE makes no difference.
Closing all BDE apps except the one in question makes no difference.
Changing from using an MSSQL database to a Paradox database makes no difference.
Making the logged in user a member of the Administrators group on the workstation makes no difference.
The typically logged in user is a domain user.
Logging in as a workstation administrator (non-domain) account that was originally setup on the machine as a last resort administration account, all works fine.
Creating a new workstation user with local admin rights, the problem returns.
The user has been temporarily allowed to use the one workstation admin account that actually works, but this is not an acceptable long-term solution. Any idea where we might go from here? Any clue as to what $251e really means?
I know that the BDE is way out of date and no longer supported, but changing the use of the BDE is not an option right now.
You might have better luck searching for the error here..
http://www.fulltextsearch.com/
A common culprit seems to be a conflicting device driver.
Good luck
I am not sure, because I don't use BDE for lot's of years, but here are some hints and links:
Error is probably related to BDE parameters (as article you linked claims)
Here are some sites that have some suggestions for optimal BDE configuration
http://www.kennedysoftware.ie/oldapps.htm - check BDE section, have information about BDE configuration and some advices about using BDE with Vista
http://www.thedbcommunity.com/index.php - community site about Paradox and BDE
BDE issues from Codegear quality central
search newsgroup borland.public.bde - there is lots of questions about #251E
Error $251E means "Insufficient shared memory available"
Proposed solutions:
Increase SharedMemSize to 4096 or 8192
Change SharedMemLocation to 0x5BDE.
After using www.fulltextsearch.com to read through hundreds of messages regarding 251e (thanks for the pointer KevinRF), we came up with a list of about a half-dozen new things to try.
Turns out the user had turned on compatibility mode (right-click exe file, choose Properties, Compatibility tab) for the program in question. Turning compatibility mode off for the application resolved the error.
Thanks to all for the suggestions!
Turn off uac and add the setup.exe and regsvr32.exe to DEP.
look on codegear's web site. some time ago i saw an article about the memory layout for this shared memory and ways to resolve a problem like this. it's an ugly business but there was a good article on this. sorry, i can't find it offhand.
Wow, I tried a lot of tactics to try and solve this problem, and it was the same. Compatibility mode. Disabled the compatibility mode and the problem is gone for good.
If your executable is with the tables (same directory), try putting it in another location.
You can also Try to rename the Executable file name, had the same problem, I know it sounds strange but it worked for me.
Looks like the path somehow caused the problem.
I solved it by renaming the folder containing project files.
I'm having an interesting problem implementing a global keyboard hook.
I wrote a dll which is used to set the hook and then an application (Delphi) which loads the dll and processes the results of the hook. This was done this afternoon on my PC at work and after some testing I figured it was working 100%.
I've just tested the same app and dll here at home and I'm not getting any errors, but the application does not appear to be getting any data either.
Both machines are WinXP, although my work machine is SP2 and this one is SP3.
Has there been some change in the Win32 API which would cause this to malfunction, or could the problem be related to some A/V / Spyware / MS Update that has been released recently?
I'm hoping somebody here will know of an obvious reason that this may happen before I spend hours debugging.
Thanks!
Actually some A/Vs don't like homemade hooks. I've got the same problem with my mouse hooker on some machines, and it doesn't depend on service pack version.
Yeah, I could. I haven't installed Delphi on this machine, but I think I might have to. I'm going for the low hanging fruit here. If there's an obvious answer, there's no need to go through all the trouble of debugging and hoping to find what might be the problem.
My first suspicion is that there's been a change in the API somewhere.
As I mentioned, this app works absolutely perfectly on my work machine.
Do you have a debugger on your home computer? Do you receive any messages via the hook at all?
Can it be that some other application is hooking, and don't pass the message on down the hook-chain?
BTW: I love virtual machines for this kind of testing. Keep a clean XP install. Install SP2, and test your application. Roll back to clean install again, and install SP3. Try your application again. This way you will know if its SP3, since there is nothing else to mess things up. I like to keep a set of snapshots around with different configurations.
Which kind of hook are you using? I once used the WH_CBT-type and encountered problems when certain other applications where running. One case I could trace back to Trillian, which seems to do also some kind of hooking (and maybe screws up).
Apart from that I am currently working on an application that uses the WH_KEYBOARD-hook and this works on SP2 and SP3 equally well. The MSDN also doesn't mention any service-pack related changes.
What you can do to trace the bug on your home machine:
make sure to check all result values of all system api calls (and use GetLastError in case of error)
provide some kind of debug output in case of error (e.g. as message box or to a text file)
optional: log some status messages so you know whats going on internally
One alternative is to use a low level keyboardhook. (Just a different param to SetWindowsHookEx). The hook is processed in the message loop of the registering thread, and thus does not need to inject a dll everywhere. And for some odd reason VirusScanners/Firewalls interfere much less with it. They often silently block dllinjection or normal keyboardhooks. Also removes the need to share the hHook across processes if you want it to work in older windows versions.
And if you abuse a keyboardhook to implement global hotkeys(Have seen that a lot) use RegisterHotkey/http://msdn.microsoft.com/en-us/library/ms646309.aspx) instead.