Is there any way to solve the problem when you add a new unit to a project and LSP Code Completion doesn't recognize the new functions/procedures? Sometimes I have to close and reopen the IDE for it to recognize them.
I have a project with more than 300 units, and sometimes it doesn't recognize uses that I add, and I try to use functions or procedures. It only works if I close the IDE.
I don't have such problems in Delphi 10.3.
If you are referring to a brand new unit that does not yet exist on disk, then that is a known limitation of Code Completion. Once the unit has been saved to disk, then it should work as expected.
I believe this was stated in the launch webinar by David Millington and is referenced in the "Items to be aware of" section of a RAD Studio 11 wiki page.
https://github.com/ideasawakened/DelphiKB/wiki/D28.ALEXANDRIA.11.1.0.0
Related
I'm writing a Delphi package, which provides a new custom TGraphic object, allowing to read a new image format in VCL components like TImage.
I originally developed this package with RAD Studio XE7, and it worked well. However I migrated recently to a newer RAD Studio compiler version, and although my package continues to work properly on that new version, I noticed a strange bug that never appeared before.
I have a form with several components, some of them are TImage components. Immediately after opening the IDE, the first time I open my project in design time, all the TImage components containing my custom TGraphic component loose their content. If I close then reopen the project, the images reappear, and the bug no longer happen until I close and reopen my IDE.
I dug in my code to understand what may cause the issue. To register my custom TGraphic component, I use the class initialization section, in which I wrote the following code:
initialization
begin
Vcl.Graphics.TPicture.RegisterFileFormat('svg', 'Scalable Vector Graphics', TWSVGGraphic);
end;
However I found that, since the XE8 compiler version, the TImage constructor is called before my initialization section, causing thus apparently the above mentioned issue. All the compiler versions since XE8 are affected, but this bug never happened on XE7 or earlier. So something changed since XE8.
Here are my questions:
Is the way I use for register my custom graphic class correct?
If not, what is the correct way to do that?
As something seems different since XE8, what it the new correct manner to register my graphic component?
Did anyone else faced the same issue? How he resolved it?
Is this may be a new RAD Studio bug, or the issue is rather on my side?
This is most likely a side effect of the smart loading the IDE applies to design time packages. You can overwrite this behavior by calling ForceDemandLoadState(dlDisable) during the Register procedure of your package.
More about this can be found in the documentation of more recent versions of Delphi than XE8: Explicitly disabling smart loading of components in a design-time package
I want to import an unit to save ini files with this unit from Github, but, as soon as i import it, code insight stops working - instead of opening itself doesn't even open anymore. It isn't a change in the IDE options, as it works in every unit/project in which i don't use it. So, the line
Uses: [...], FMX.IniFile;
Seems to deactivate Code Insight. I use Rad Studio 10.3. Is this a known issue or does a solution already exists?
Thanks
Edit: In order to use the file correctly, i need to import the files for android and Apple as well, which are in the same directory as the main FMX.IniFile.Pas, these might cause the problem as well
Sorry, I just tried what you describe in your q and code completion continues to work fine.
Here's exactly what I did:
Created a new multi-platform application.
Saved the default new Form1 unit the IDE creates and the project.
Created a new unit and cut and pasted the source of FMX.IniFile into it.
Saved the new unit in the project's folder under the name FMX.IniFile.Pas
Added FMX.IniFile to Form1's unit's Uses clause.
Added a TButton to Form1 and did a Save All
Created a `Button1Click' event on Form1.
Switched from the form editor to the code editor and, in the Button1Click handler skeleton and started to type
Self.c
and the IDE immediately offered the various properties of Form1 beginning with c as code-completion possibilities.
I'm using Delphi 10.2.3 on Windows 10 Pro 64-bit.
When I add a file or form to a Delphi project, often I get an access violation. Then I have to restart Delphi, open the project and try it again. Then it sometimes workes, sometimes I get the same Access violation. I am having this issue in all Delphi versions since XE8.
Other Delphi programmers seems to have the same problems, as here on the Community of Embarcadero: https://community.embarcadero.com/forum/programming/9387-creating-a-new-unit-or-new-form-in-delphi-10-2-3-causes-access-violation
Some people say that it's caused by third part libraries. I doubt that. When you look at the stacktrace, there is no third party library.
To reproduce:
Work in a (somewhat) larger project and make some code changes before adding a unit.
Add a new unit/form: File>New>Unit - or add an existing file using drag and drop or 'Add file to project' - Or delete a file from a project.
I contacted Embarcadero about this. They know about this issue and they replied as following:
It's due to some Castalia code, that's merged in Delphi since XE8. It's only possible to reduce this issue, so it will happen less often. Use: Tools - Options - Editor Options - Color - Structural Highlighting and switch everything off.
Looking at how the code is integrated into the IDE, this results in less editor parsing and repainting. Irrespective of that, the handler that causes the Access violation is still attached to the editor.
So basically, we will have to wait for this to be fixed in 10.3.
But a while later, I discovered, that the Access violation only occurs if you have closed the project's 'dpr file'. So as a work-around:
Don't close the dpr-file and you won't get the Access violation.
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.
We recently converted our long-running Delphi project to Open Source. Multiple people have contributed patches already, which is great, but unfortunately forms and frames when saved with Delphi 2006 (and later) contain new properties in the .dfm that are not handled by older versions. Forms are handled quite gracefully by the IDE ("ignore propery?"), but frames are loaded at runtime and result in errors. Not an option, as far as I'm concerned.
I now removed those properties from the .dmf files by hand, but I am really wondering if there is a more elegant solution. There is no way to save in a backwards compatible format from the new IDE's, is there? Are there existing tools to strip the nonsupported properties from the .dfm's ? Any other elegant solution I am missing?
Normally, with a commercial project, I'd just upgrade the project to the most recent version applicable... but as this is open source I really don't want to loose out on those developers still working on Delphi 7. That includes myself, actually.
The JEDI JVCL project uses a little utility dc.exe (delphi cleaner) and a list of properties in DFMs that are not present in older versions of delphi, mine contains the following text:
*.PopupMode
*.PopupParent
*.ExplicitLeft
*.ExplicitTop
*.ExplicitWidth
*.ExplicitHeight
*.BevelKind
*.BufferDocument
*.DoubleBuffered
*.ParentDoubleBuffered
*.DisableHyperlinks
*.AlwaysEnquoteFloats
*.PixelsPerInch
I run this dc.exe utility from a batch file which cleans my dfms before I commit
changes to subversion. The syntax in my batch file for this is:
dc.exe -s -fd10.txt *.dfm -i
You can grab my stuff at:
http://sites.google.com/site/warrenpostma/files
You can try Andy's DFMCheck. It can automatically open and close all forms and frames in a project, which makes the IDE remove unknown properties (as Marco wrote).
Well, for sake of completeness:
Open the dfms in the oldest Delphi supported, let it remove all unknown properties, change a property and save.
For your purposes, Warren's solution is better, but it can be a workaround. I did it for a while when we were dual D7-D2006ing.