I'm running Delphi Tokyo 10.2. My Tooltip Symbol Insight (when debugging) has suddenly stopped working. The Code Insight that shows tool-tip information in the editor on mouse hover has also stopped working. All other Code Insight features appear to be working.
I attempted a Windows Update (Windows 11) which failed and rolled back. (I don't know if it's related to that or not. Code Insight worked before the update attempt and now doesn't.)
I have unchecked and rechecked all the Code Insight check-boxes in the Options window. In my frustration I have even uninstalled and reinstalled Delphi 10.2. Still no Tooltip Code Insight.
I'm guessing that it may be an invalid or missing registry entry but really have no idea.
Does anyone have the experience or knowledge to get my tool tip code insight back?
Thanks.
For those Delphi developers that may experience this in the future, I have found the answer.
My setup is on a laptop that usually has multiple monitors. I removed the additional monitors and was able to successfully install the Windows 11 update. The issue then resolved to the following:
Run the laptop with no extra monitors and Delphi tooltips worked
Add a monitor and Delphi tooltips stopped working
The same was true of the applications I built in Delphi. If I ran them on the laptop with no extra monitors I got tooltips. If I added a monitor the tooltips disappeared.
It turns out that I installed ElevenClock (a Windows app that adds seconds to the clock in the system tray - an extremely valuable feature for me) at around the same time that I attempted the Windows 11 update.
I removed ElevenClock and, presto, my tooltips now work flawlessly. Those with more knowledge of Windows messaging are free to add comments but it would appear that ElevenClock was intercepting the message that ultimately generated the Delphi Application.OnShowHint event.
Related
I have just installed Community Edition of Embarcadero C++Builder 10.3, as downloaded from the manufacturer's website. When I run it, the Welcome screen looks OK. Then I press on "Create a new Windows VCL application - C++" link to create a simple "Hello World" GUI project targeted at Windows. After that things fall apart - the windows in the RAD Studio do not update, and the only way to get at least some information out of them is to click on them (see screenshot below). And even then their headers never show up. Main toolbar is entirely lost. Main menu is only visible when you click on it. And then the main menu becomes frozen for several minutes. I can't even get to just placing a simple button on the form, let alone writing some code.
I used to be a huge fan of Delphi 20 years ago, did a lot of software development in it, then migrated to MSVC. Now I am trying to migrate back to Delphi/C++Builder tools, so I gave it it a try. But come on, it can't fall apart right after the installation while attempting "Hello World" project! Not a development tool that has decades of history! Am I doing something completely wrong? I really want this tool to work out for me, I have lots of respect for it from 20 years ago.
I installed C++ Builder 10.3.3 community and opened an example VCL project "Searchbox".
It compiled and ran the program, but I am not able to navigate in the sourcecode.
If I hover the mouse over a datatype or variable, a tooltip appears "cannot find C:/Users/Public/Documents/Embarcadero/Studio/20.0/Samples/CPP/VCL/SearchBox/usearchbox.cpp" This is the file in the editor and it definitely exists, however note the path is written with forward slashes, this might be the reason of failure.
If I search for declarations via menu, nothing happens, no result, no error.
To me, this seems to be (partially) broken out of the box.
My OS is Win10Pro 64 Bit.
Edit:
This apparently only happens when the classic Borland compiler is deselected which means CLang is used.
Because I am only interested in the CLang compiler, the product is -unfortunately- unusable for me.
With XE8 update 1, Win 7 64 bit and a single component added to an otherwise empty folder I get:
error: [dcc32 Fatal Error] F2039 could not create output file .\Win32\Debug\MountTest.
The test will compile and run fine the first time but XE8 has to be shut down and restarted to compile again. The component is a gauge from Mitov Software.
The component vendor say's that this is a known bug with no fix. If so its a showstopper and project end'r for me. Is it really the end of the line for Delphi?
I hope some one can pull this rabbit out of a hat somehow.
This is what I have done to isolate the problem.
Started with a failing application (will not compile a 2ed time)
Remove all external units used
Remove al references to those units
Remove all references in the 'Uses' clause
Comment code until it compiles
It should compile every time you hit run (no problem).Now add a blank form to the project. Don't do anything to the form just add it. Add it to your uses clause.
Its should compile every time you hit Run.
Now open the blank form and simply touch it so that it needs to be recompiled.
When you run the application its back to failing when you run it a second time.
Notice that happens when you simply add a form and 'touch' it. No code needed.
This problem is not something wrong with my code - it can't be. Its a bug in the UI - must be.
Coincidentally, I just fought with this issue yesterday testing some components I ported to XE8. The output file in my case is the project executable.
After spending several hours trying to figure out what was going on (including efforts to reconfigure my AV software, disabling it entirely, moving the project to a different location, etc.), I was able to solve the problem by disabling Castalia. If I run the IDE without Castalia, the problem does not occur. If I enable Castalia again, it starts happening again.
You can find instructions for disabling/enabling Castalia in How can I disable Castalia in XE8?
I'm removing the above content because the issue has reappeared (with Castalia disabled). Further investigation shows a couple of things:
The problem seems to be related to any sort of exception being raised in the debugger (even those that are handled in the code). Clicking either Break or Continue in the debugger exception dialog works as always. However, the next attempt to compile or build the application fails with the F2039 error. Deleting the executable in Windows Explorer allows compilation and running once, and then the error recurs.
Restarting the IDE fixes the issue, until the next debugger exception occurs.
Neither taskkill or a batch file with del worked in either a pre- or post-build event.
There is an open QC entry for it at Embarcadero which indicates that it was reported in XE7, XE7.1, and XE8, and is currently an open internal ticket. I can't find a way to add the information in the two points above to that open ticket in the new JIRA-based Quality Portal. Perhaps someone who has access and can do so will on my behalf (or at least add a link to this post).
It's not linked to a specific project. The original answer (as mentioned above) was related to a test app while porting some components to XE8 from an earlier version. When the problem reappeared for me, it was in a brand new project, totally unrelated, that does not use any non-standard components.
(I previously had access to EMBT QC, and had a few open tickets. The accounts appear to have not migrated to the new QP, and I can't locate any tickets there under my account.)
Found It.
I decided to start from scratch on my development system and uncovered the problem.
I installed Windows 10 on a virgin disk
Installed XE8 update 1
Installed MITIOV Instruments for XE 8 and tested them. All working find
Installed AsyncPro - Still working
Installed the JEDI Jcl - Fails
Remove JEDI Jcl - now works
Trash JEDI completly - Everything works fine
Something in the JEDI Jcl version 3.48 is causing the problem. I can code around the JEDI components I was using without to much trouble but its a shame.
How about automatically kill your "hang-up" application before build?
I also had this problem on Win 7 Pro 64 bit with XE8.
Removing JCL fixed the problem. If I was a betting man, I would look closer at the JCL Debug IDE extension.
Guy's..
There is no reason to upgrade to Delphi 10.1, because all previous versions are equipped with an older version of the Android SDK.
Now, how to solve this annoying issue:
Just find the map where the Android SDK is located.
See: Tools/Options/Delphi Options/SDK Manager/Android Location
Now run the ..\sdk\tools\android.bat as Admin
This will show the Andoid SDK Manager.
Next is to update to the newest Android SDK and SDK Tools.
If all completed, you don't have to upgrade to Delphi 10.1 or whatever "advised".
Restart Delphi and problem:= solved!
btw:
It took some effort to find out what's happening here, because the Eclipse compiler suffered the same issue as Delphi. Finally all was related to bugs in earlier versions of the Android SDK causing adb.exe to keep a filehandle held hostage.
I've been widely making use of the Complete Class at Cursor function in Delphi, in 2010 and in XE2. Recently, after installing Update 4 for XE2, the Complete Class at Cursor stopped working. After doing some research, I found that uninstalling "AQTime" would fix the issue. So I did that (had to re-install Delphi just to remove it) and sure enough it started working again.
Except, today, it suddenly stopped again. AQTime is not installed, and I haven't done anything in the IDE at all which (as far as I know) could possibly cause this. I haven't installed/uninstalled any packages, changed any library paths, not even changing any settings. It just suddenly stopped working in the middle of my development. Was working one minute, and not the next. I've restarted Delphi, restarted my PC, and even tried in a brand new project. It just will not work anymore.
Anyone know why this stopped working? How can I make it work again? It's an extremely helpful tool which I use all the time.
I had the same problem, but it was solved after uninstalling Smartbear AQTime from the windows uninstaller. (close Delphi first)
No need to reinstall Delphi.
Had the exact same issue in XE2/Update 4. Did the following (without uninstalling AQTime) and it came back.
Tools > Options >Editor Options > Code Insight
Verified the Code Completion was checked (it was), then changed the Delay to Low (was set to None) > OK
Code Completion in my IDE started working again.
I was having the same problem in Delphi Berlin. None of the above worked for me. I also tried regenerating the .dproj file but that also did not help.
The one thing that has worked (so far) is installing the excellent IDEFixPack for Delphi Berlin. Delphi IDE Fix Pack
Please let me take this opportunity also for a quick moan. Code completion is an absolutely essential feature of Delphi and it is very slow and flaky at best. Embarcadero (if you are listening) - please focus on making these core features much more robust.
Unstalling the AQTime8.20 integration in the IDE solve the problem for me too - used AQtime outside the IDE anyway.
I'm writing a FireMonkey HD application on my Windows 32 bits machine, and deploying (remote debugging) it on my MacBook running Snow Leopard. I'm running the Delphi XE2 Trial.
Everything is working fine, except for one thing: every other run I hit the following error when I press F9:
Fatal error starting debugging kernel: "Invalid debugger request".
Please save your work and restart Delphi XE2.
Restarting XE2 and running again cures this problem... for exactly one run, then I hit the same error again. Whether I stop the debugging run through CTRL-F2, or gracefully close the application on the Mac, makes no difference. It happens on every project (including new, empty ones with only a single FireMonkey form).The PAServer terminal has no information, it's still on "listen".
Anyone has any tips on how to avoid this issue?
Installing the full version of Delphi XE2 (including update 1) seems to have fully solved my problem.
I've checked the Bug Fix list for any references, but no such luck. Oh well, problem is gone anyway.
[EDIT] And now, the very next day, the problem re-appears.
Delphi 10 gives a similar adventure (Win32 --> Win32 target). It's "business as usual" for the remote debugger.
We have a few different programs all compiled together in the same suite, recently we had a bug reported that "The Right Click Shortcut Menu was missing."
So as with any bug I tried to reproduce it and couldn't. No matter what I did the right click menu appeared on my system.
My first guess was that this was an OS issue. We know it works on Vista and XP, but on Windows 7 it doesn't. Unfortunately this issue only affects one of the programs in the suite and seemingly only on this one machine. AFAIK there isn't any code we've written to allow or prevent the default menu appearing so I'm not sure why it only affects one program.
The machine with the issue is a 32-bit machine running Windows 7. There was another issue to do with the regional settings (we have noticed backwards date formats even though the OS thinks it's UK it had been displaying MM/DD/YYYY format, but this was fixed when changing the regional settings to something else and back again). This did not resolve the issue.
Besides writing a new context pop-up, does anyone have any idea how I would even start to diagnose this issue? Is there an API I can call to pop-up the default menu so I can monitor its behaviour? some windows message I can intercept the check its all running as it should be?
Download Delphi 2007 December updates to fix this problem
or andy Context menu popup delay bug fix unit