Leaderboard

Version V15.0.37 of MMX Code Explorer introduces Structured Difference Viewer (former available as a separate product). It is registered as an External Difference Viewer in the IDE and can be used as an alternative way to compare source files.

I've never encountered anyone except Delphi users who develop inside VMs. Seriously, no one else. I'm not sure why you'd want to do it either. You're going to end up with less RAM, slower CPU, slower disk access, and the need to maintain two OSes now. I can understand testing in a VM where isolation and reproducibility are important, but I don't understand the advantages of using a VM for development. Honestly, it might have something to do with how hard it's been historically to get a Delphi development environment set up (or upgraded).

On Linux with KVM one can reserve hardware for the VM to have dedicated access to. On my home desktop I finally got this set up correctly so that a Windows VM has exclusive access to an old second video card I stuck in the machine. I was able to run some 3D games in the VM essentially as well as the old card could before under native Windows. I hooked the card's output to the second input on my monitor and can toggle back and forth between fullscreen Linux and fullscreen Windows with hardware GPU. 🙂 The keyboard and mouse can be toggled between systems and the sound is virtualized although one could also dedicate these to the VM too if they have the extra hardware. I *think* it's possible to configure things under some circumstances to automatically switch graphics cards such that, say, Linux boots with the newer graphic card but when the VM runs Linux gets the old card and the VM gets the better one, but I haven't tried this yet. If possible, it's not exactly easy.

This component was created for use in RJ TextEd to add language server support. It has been tested with several language servers https://www.rj-texted.se/Forum/viewforum.php?f=23. The client and code is available on GitHub https://github.com/rickard67/LSP-Pascal-Library The LSP client was written to make communication with language servers easier. You can use the client to read or send notifications and requests to and from the server. Handle notifications and request from the server using events. The client component support both stdio and tcp/ip socket communication. The client only works in Delphi. I haven't had time to make it compatible with Lazarus/Free pascal yet.

LSP simply does not work well yet in any sort of complex scenario. I wrote to EMB support about certain things not working with LSP mode and worked in Classic mode and they wrote: Although several issues related to the LSP server were included in the Sydney 10.4.2 update, several additional issues remain but are slated to be addressed in a future release or update. Examples of open defects affecting LSP: New LSP does not recognize newly build classes. https://quality.embarcadero.com/browse/RSP-31922 LSP not recognising subtype alias https://quality.embarcadero.com/browse/RSP-33546 LSP doesnt show errors https://quality.embarcadero.com/browse/RSP-33060 The Code Insight using LSP work only for small "hello world" applications. https://quality.embarcadero.com/browse/RSP-33403 Here are a few details which may affect Code Insight/Find Declaration: 1) It only works effectively on the first project in a project group, so if you have a project group with several projects, it is best to open just one project at a time. 2) When you see [Calculating...] it means that the LSP server is working and indexing, it's best to click elsewhere and then try again. 3) if you see an error 'cannot find file XXXXX' even though you are in the file in the IDE, it means the file cannot be found in the index database, so the LSP server still needs time to index it.

After several days of working with the 3 patches applied I have to say that things are going better but 10.4.2 is still far to be a stable environment to work (in my configuration). Even if with less frequency I continue to have scattered errors in the IDE: - access violations in dcc32270.dll (usually compiling a project not active and always need to close/kill ide when happen because of cascade of access violations) - access violations in rtl270.bpl (switching between projects / closing the ide) - "Error reading Image1.Picture.Data" doing text search in ide editor I think/hope that embd should/could invest some time to make things better for those who work with project groups and runtime packages.

I have seen this issue with my IDE plugin too... the problem is the IDE is not a normal VCL app when it comes to themes(it uses a custom version vcl themes).. and some controls just don't get told to repaint or that the theme has changed. I wasted a lot of time on this, but it's really an IDE problem. Delphi 10.4 is better with this than 10.3

Package binaries are specific to each compiler version. 10.3 can only use packages that have been compiled for 10.3, etc. If you have the source code for the 10.4 package, you will have to compile it using 10.3's compiler.

Thanks for the suggestions. I changed all the packages to Explicit ReBuild, not that it was the cause, but a good change anyway. Turns out I isolated the issue to the IDE injecting the FireDAC.FMXUI.Wait unit into the Interface section every time the unit was saved/compiled despite the fact it was already present, just wrapped in an IFDEF. Took me a while to find out why it was adding the unit. Turns out I had dropped a TFDGUIxWaitCursor component on the data module at some point. Creating that component in code with the Provider set appropriately fixed the issue. The dialog is obviously misleading as it has nothing to do with what packages are installed in the IDE.

If I understand correctly nobody likes to be forced to pay for bugfixes for stuff they already bought.

In that case, it is silly that the patches are not in order, and that two of them have the same date. IMO, the description should have contained the patch number.

I agree that it's not doable to be fully comprehensive, but there are some major issues people should be aware of for each version. What might be useful is a list of major function topics and warnings next to each. For example, inline variables were introduced in 10.3 but should still be avoided as their usage breaks tooling. (32507, 33176, 33365, 22089) Another issue for those that rely on IDE Fix Pack would be a warning that's its not available for 10.4 but by 10.4.2 many features have been implemented. I remember being stuck at XE2, but I no longer recall what was broken in XE3 which preventing me from upgrading. We are currently in the seemingly never-ending chase of requiring to use the latest version for bug fixes, but the latest version always adds new issues. We end up with developers 'stranded' at particular versions because of major issues that they are waiting to be resolved. Eventually the perceived pain of upgrading accumulates until such time as someone decides to 'abandon ship' and switch to a different solution. This thread is an example - 10.4.2 follows with even more bug fixes than the 'quality' focused release of 10.4.1 and yet, two months after release, some people cannot use the product due to internal errors. I wonder how many developers thought that their specific pain points were finally addressed and they would upgrade to 10.4.2 and then got smacked in the face with this particular issue and finally raised the white flag (especially after waiting for months now.) For me 10.4.2 is their best release in a long while. But I'm also no longer managing complex projects with many millions of lines of code so I'm not running into this particular showstopper. However, I would really like to use inline variables, but until they fix the issues surrounding them (including the code formatter) then I refuse to use them. I assume the code formatter might be upgraded in the 10.5 release cycle and it'll take until sometime into 10.6 before it's solid so I assume inline variables are dead to me until sometime in 2023, or later. That's not intended as a slam, it's simply a reasoned forecast. Therefore it comes down to a new language feature being introduced in 2018 and forecasted to be potentially usable in 2023. Saying that out loud makes me sad and question my life choices...

We know that a bug in the compiler has been detected that affects several reported QC issues and with a help of a couple of developer the hotfix was tested a month ago. Unfortunately it's a top secret information what delayed the hotfix.

I am afraid that list might be too long... and it would require input from large number of developers. It all depends on code you have and what kind of workflow you have at any given moment and for which platforms you develop. What is good version for some people, might be utmost nightmare for others. And besides stability, there might be other reasons and bugs in the core frameworks which makes some versions unsuitable for some developers. Workarounds were usually move to another version and hope for the best. Without actually trying on your own code and working with some version, one can never know. Since Embarcadero opened up beta testing for larger audience, it would be good that anyone who can participate. The more the merrier. It is also important to start testing early, because some bugs if found too late in the cycle may end up unfixed. Of course, all that also does not guarantee final quality and release success, but it can be significant factor. Literally one person can stumble upon critical bug that would end up in RTM, and all other testers might miss it for one reason or another. It is huge codebase, and we cannot test and use all features thoroughly.

That's exactly what I am doing, since the packages are plugins that the user can choose not to load. It's no where near as simple as you make out. And really, my code and application architecture is not the issue here.

They're not I posted a link to a webinar 3 weeks ago where @Marco Cantu admitted that he is in charge to resolve this problem and to release the hotfix. I guess the cold weather in Europe made slowed the release a bit down.

Are you volunteering to rework my application architecture if it's that easy - I have 100+ package projects in a project group, a few dll's and 4 exe's (around 4M lines of code) and I see these errors all the time. I cannot use LSP at all because of this, but even with it turned off the IDE and the compiler are unstable. I can't afford to spend months refactoring my code in the hope that the IDE or compiler might then just behave correctly 🙄

I've only projects that use packages... Top priority correction for me is an hot fix released in a couple of days not one released in more than a couple of months!

The fix is on the way at least for a month. It's really shame that Embarcadero is silent on this issue. It's not a minor bug, but a major showstopper!

Use it as you want if it works. I'd be happy if fixes/enhancements would come back to me! 😉 forsix.MapiMail.pas

So you should be able to make a reproducible test case - in case there is none already. I did report this with a reproducible test case, but they knew about it long before then. https://quality.embarcadero.com/browse/RSP-32666

Doesn't work well on this project - feel free to analyse my code and tell me what I did wrong 😉 https://github.com/DelphiPackageManager/DPM If the code is too complex for the tooling, then the tooling needs improving, valid compiling code should not be a problem.

I am baffled and pissed, here time flies and still no answer or solution from Embarcadero! I cannot understand why they are not giving top priority to correct these problems. It's unbelievable ... Daily work in these conditions is a nightmare! But is there anyone using 10.4.2 without problems? Has anyone switched to this shameful bug-ridden version to work seriously? Am I the only fool?

I have the same problem, finally I switched to "Delphi (Classic Code Insight)" and it works fine. But now it's a bit annoying that after doing a "Find Declaration" in the Code Editor, the cursor every two seconds shows the hourglass.

It doesn't work if your search path only has the dcu's or dcp's - which if you use runtime packages is quite likely. I have turned LSP off, but sadly 10.4 cripples the old code insight somewhat and navigating my code has become a real chore.