Leaderboard

In my opinion all is said. @PeterPanettone Just submit a feature request. It has nothing to do with "lacking abilities" of the developers but priorities for development

It seems beyond your ability to not be obnoxious. I don't see a point in continuing to converse who you.

Yes, I have divided my code in business objects, data objects, form and project directories. I've changed the "project directory" in DelphiLint to one of these directories and that worked fine ! I have to say that DelphiLint is one of the nicest Delphi tools I've seen for a long time. 👍

After reading some of the other posts here about Java 11, I breezed through the installation for both D11 and D12, opened a small project, made sure several units were open in the IDE, and selected Analyze All Open Files. I like how the suggestions are brightly highlighted right in the IDE--many good suggestions. This is pretty slick! I thought at first it only analyzed the current file but as soon as I switched to a different file in the IDE, the Delphi Lint window updated with the different list of suggestions for that file. Double slick!!

I find some of the EMBT marketing practices to be idiotic and unnecessary. They keep spamming me these offers for "upgrades" and "new licenses" with varying levels of price slashing, all year around. Don't they consider that I have been a subscriber for more than a decade, and that the offers only are valid for new licenses? The new releases and offers tend to bundle some third party tool or package that is underfunctional and overpriced, and where the license terms are a tad unclear after the year has passed. After being bought by Idera, it is often some other Idera purchased product that I have little interest in. I find the bundling practices to be inconsistant, to put it mildly. Not only do they do this directly, but the local representative also spam the same offers, over and over. According to the local representative - it is EMBT that do the spam on their behalf. Where is the reward for staying a long time paying customer? It is not like the maintenance is cheap, and it is not like I spam EMBT with support issues. As for support, I don't think I've every raised a support question apart from the annoying license counter bump requests. Ok, I am paying for new versions, updates, hotfixes, etc. - but to be honest, for many major versions now, the first xx.0 releases have of sub-par quality. We've had to wait at least for update 1, and a hotfix or two - before it was fit for use. About license management... Remember the Delphi .NET craze? It led us to purchase RAD Studio licenses to get a the new and shiny .NET stuff. That shit didn't last long, mostly due to MS not fully opening the door on third party .NET tools - but - when they were discontinued, we were still on RAD Studio Enterprise, when we really only need Delphi Enterprise. We have never used the C++ part of RAD Studio., but there is no way to downgrade a license, and it is still cheaper to keep the RAD Studio Enterprise maintenance, than to repurchase Delphi Enterprise licenses. So we stay on maintenance and keep hoping for Old problems to be fixed New platforms to be supported HighDPI to be done right Code performance to be improved RTL performance to be improved IDE to become stable and performant Debuggers that actually work in all scenarios Less immature and unfinished new libs and components Less pointless marketing offers because, warts and all, the tool is what we have become dependant on. Still hoping that it will change for the better... http://www.toodarkpark.org/computers/humor/shoot-self-in-foot.html

It's a privately held company; they don't have to answer to shareholders. By saying it didn't work out for them, that really means that most current users would be happy with having less features for a lower price, but this would not attract sufficient new users to make up the difference. So current users have to spend more than they want for things they don't use. There's a difference between a change and a bug fix. A bug means you paid for something that actually wasn't delivered as promised. In no circumstances should someone be able to deliver a product that doesn't work correctly and then offer to fix it for an additional fee.

It's a shame they didn't simply update the AbstractErrorProc to accept the ReturnAddress as a parameter so it could be passed to the raise statement, eg: procedure _AbstractError; begin if Assigned(AbstractErrorProc) then AbstractErrorProc(ReturnAddress); // <-- RunErrorAt(210, ReturnAddress); end; ... procedure AbstractErrorHandler(AExceptAddr: Pointer); begin raise EAbstractError.CreateRes(@SAbstractError) at AExceptAddr; //^^^^^^^^^^^^^^ end; Like they did with RunErrorAt() in XE2. And also, as can be seen in other areas of System.pas, like the various _UnhandledException() implementations.

XE2. Prior to that, _AbstractError() used hand-written assembly code that didn't use a stack frame. In Delphi 5 (and probably earlier, I can't check), it looked like this: procedure _AbstractError; asm CMP AbstractErrorProc, 0 JE @@NoAbstErrProc CALL AbstractErrorProc @@NoAbstErrProc: MOV EAX,210 JMP _RunError end; In Delphi 6, some extra platforms were added: procedure _AbstractError; {$IFDEF PC_MAPPED_EXCEPTIONS} asm MOV EAX,210 JMP _RunError end; {$ELSE} {$IFDEF PIC} begin if Assigned(AbstractErrorProc) then AbstractErrorProc; _RunError(210); // loses return address end; {$ELSE} asm CMP AbstractErrorProc, 0 JE @@NoAbstErrProc CALL AbstractErrorProc @@NoAbstErrProc: MOV EAX,210 JMP _RunError end; {$ENDIF} {$ENDIF} Then somewhere between D7-D2006, the PC_MAPPED_EXCEPTIONS branch was dropped: procedure _AbstractError; {$IFDEF PIC} begin if Assigned(AbstractErrorProc) then AbstractErrorProc; _RunError(210); // loses return address end; {$ELSE} asm CMP AbstractErrorProc, 0 JE @@NoAbstErrProc CALL AbstractErrorProc @@NoAbstErrProc: MOV EAX,210 JMP _RunError end; {$ENDIF} Then in XE, the assembly code was restricted to just 386 CPUs and tweaked to include stack alignment, but still no stack frame: procedure _AbstractError; {$IF (not defined(CPU386)) or defined(PIC)} begin if Assigned(AbstractErrorProc) then AbstractErrorProc; _RunError(210); // loses return address end; {$ELSE} asm CMP AbstractErrorProc, 0 JE @@NoAbstErrProc {$IFDEF ALIGN_STACK} SUB ESP, 12 {$ENDIF ALIGN_STACK} CALL AbstractErrorProc {$IFDEF ALIGN_STACK} ADD ESP, 12 {$ENDIF ALIGN_STACK} @@NoAbstErrProc: MOV EAX,210 JMP _RunError end; {$IFEND} And then finally in XE2, the assembly code was eliminated completely: procedure _AbstractError; begin if Assigned(AbstractErrorProc) then AbstractErrorProc; RunErrorAt(210, ReturnAddress); end; Which is why it is now subject to the compiler's setting for stack frames when compiling System.pas.

7, the most holy number!

Solved in build 26: Now you can setup the settings

You're not comparing like things. Microsoft's development tools support their platform services, which is where they are making money. Embarcadero cannot treat Delphi the way Microsoft treats VS, because Embarcadero needs to make a profit on the development system while Microsoft doesn't. I have a hard time taking rants about pricing seriously when they say "Embarcadero should do it like Microsoft." They just cannot, and that should be obvious. We all know that if we want bugfixes we have to pay for maintenance, and that they come mostly as new versions, not patches. It's part of the calculus of choosing Delphi. If you want it the way it's done with VS, best just move to VS. If you want to use Delphi, you have to put up with the extra overhead involved (in many aspects) of using what amounts to a niche product.

I know the reFind utility by Embarcadero has a narrower focus on just FireDAC migrations, but that is something else Delphi Parser does too. I'm curious if with a little work reFind could accomplish a lot of the other functionality as Delphi Parser.

Exceptions on shutdown are particularly difficult to track down because lots of code gets executed at that time and not necessarily in the expected order. IDE plugins use the Open Tools API which consists of a set of interfaces which all go out of scope on shutdown. On top of that some plugins hack into the inner workings of the IDE to fix bugs, add functionality or change the UI (GExperts and cnwizards both do that). If you have several plugins installed they might also interfere with each other. You can always run the IDE itself in the debugger and hope that in the case of an exception the call stack might give you some clues. But don't hold your breath, I have tried that for years and it rarely helped. Having said that: I know that using the GExperts code formatter can cause access violations later on in the code editor or when exiting the IDE. This did not start when the code formatter was added to GExperts but already happened with the original DelFor expert from Egbert van Nes. Unfortunately these exceptions do not happen in the GExperts source code but somewhere in the IDE, so even in the debugger I can only see the assembly code in the CPU window. I could also create them sometimes by simply copying and pasting large amounts of code, so I think it is not actually the code formatting that causes the problem but replacing the text of the whole editor file multiple times. There might be some background processing that gets confused by this operation. But I found no reliable way to reproduce them.

We're excited to release version 1.1.0 of DelphiLint, a free and open-source static analyzer and linter for the Delphi IDE! DelphiLint is powered by SonarDelphi, our Delphi analyzer for the SonarQube code quality platform, and can be run in two modes: Standalone - run analyses entirely locally, no server required Connected - connect to a SonarQube server, allowing for synchronization with the server's quality profiles and configuration Release: https://github.com/integrated-application-development/delphilint/releases/latest Blog Post: https://github.com/integrated-application-development/delphilint/discussions/43 New Features in 1.1.0 Quick fixes - fix issues using suggested automatic changes Standalone rule configuration - configure the analysis rules that are applied in Standalone Mode Declutter files by hiding issues Many performance improvements and bug fixes For more details, see the blog post for release 1.1.0 and the repository README.

Granted, but having used Delphi for probably over 20 years now, there is no 'upgrade' price that acknowledges the amount of money spent on versions over the years. It seems you are treated as a 'new' customer regardless of your 'loyalty' to the product. With other products, existing users normally get upgrade prices that are significantly better than a new customer would pay. Also, when I buy a product I would expect to get any bug fixes for that product free with an apology, rather than having to pay for it. Embarcadero seem to be like the Carpet shops, there's always a 'sale' on. I can't believe anyone, company or individual, ever pays the advertised price. Why don't they have some integrity and show a normal price! Whatever 'special deal' is running the actual amount they want is always around the same (which in my opinion is way too much).

Yes, I have used the UniGUI Migration tool on a fairly small (~40k lines) Delphi XE project. It's supposed to take a VCL program and replace all the components with their UniGUI equivalents so that you can turn your Windows-only program into one that runs through the web. As most typical applications, I use a few third-party components like DevExpress Quantumn Grid, Raize Controls, and some spell-check components. I figured I'd either lose functionality or have to find replacements for a few but was surprised that the migration tool does not support ANY third-party controls; in fact, it doesn't even support all the VCL ones. It doesn't know how to translate TLabeledEdit, TNotebook, TGridPanel, TBalloonHint, TBevel, TDBRichEdit, TDropDownButton, or (a big one for me in this particular project) TCategoryButtons. Many of these I could modify the script to add direct replacements but something like TLabeledEdit that needs both a TLabel and a TEdit, you have to do manually (separate into two VCL components in the original code before migrating). Things like TBalloonHint just get deleted as the functionality on a web app is different. Also, none of the dialog components (TOpenDialog, TSaveDialog, TTaskDialog, TPrinterSetupDialog) are supported. For most of the RaizeControls, I easily found the UniGUI replacements in the script for the VCL equivalents and added these to the list but I wish support for some of the more popular component sets could've been added to the standard script. If a control is not found, it's just skipped so it wouldn't hurt to have lots of third-party controls listed in there. The user interface is clunky--no settings are remembered between sessions, you have to hunt for the project file every time and once it's finished processing, the only option is to close the program. After running a migration and loading a converted project, I would make some changes to the script and have to restart the program, re-select the project file, and hit Next a few times in order to run the migration again; a minor irritation, I suppose, but for something that will be run multiple times until it looks right, having to restart and go through this whole series of steps instead of just clicking re-run or something was annoying. However, it does do a lot of the migration work for you, copying your project to a separate directory and making all the project and unit changes to produce a UniGUI project. I never did finish migrating my project to UniGUI because I was doing this on my own time and got busy with other stuff--but I still might come back to it some day and try to finish it.