Leaderboard

We have released new updates of all products: Pascal Analyzer 9.14 Pascal Expert 9.14 Pascal Browser 3.5.35 It is possible to download evaluation versions, and also to view the entire documentation online. Go to Peganza for more information. If you are new to the products, we recommend our Youtube video (18 minutes) that describes Pascal Analyzer, with examples and a short demo. Here are the changelogs for these updates: Pascal Analyzer 9.14.0 February 20, 2025 fixed a problem with inline variables fixed an issue with WARN46-"Local variables that are set but not later used" fixed an issue with WARN19-"Recursive subprograms" fixed issue with unit in "contains" having same name as package itself fixed issue resolving overload calls fixed issue with WARN46-"Local variables that are set but not later used" unnecessarily also listed variables that were not used fixed issue with REDU1-"Identifier not used", reported parameters to procedural types improved code that recognizes event handlers fixed error with variable not property initialized removed minor memory leak for editor tabsheet fixed issue with WARN11-"Value paramaters that are set" Clone Report now marks code blocks that are *exactly* same (non-case-sensitive) with the string "*SAME*" instead of "0.0%", makes it easier to find those clones that are result of copy-paste fixed issues with the Clone Report improved display of code lines in the Clone Report, now also shows indentation added option to select font for read-only editor files. New item in View menu. EPreviously font was same both for read-only and writeable editor files. now font effects and font color not possible to select for editor, because always uses a default color scheme for Object Pascal fixed an issue with calculation of decision points for abstract methods new section in Strong Warnings Report: STWA11-"Duplicated GUID". Please note that you may hav to update the template,if you want to include new sections Status Report now marks search folders that do not exist with "(invalid)" suffix. You should remove these folders from Delphi library path to improve compiler performance Status Report now shows comment if not all files are selected for parsing fixed error in XML format for Warnings Report new setting for the Clone Report: "Min DP", or minimum decision points. This specifies the minimum DP a subprogram must have in order to be examinated by this report. Default is 1 added divider lines between subprograms in Clone Report to make the display easier to view and interpret new section in Strong Warnings Report: STWA12-"Equal if-then and if-else statements" clicking in the report tree on a section now scrolls to the section in XML file if changed "main file" and selecting "Save Project As" now suggests the new main file name as file name (previously suggested old main file name) fixed an issue with display of Complexity Report for HTML in the Status Report, now displays a note if the corresponding Delphi version of the compiler target is not installed. If the relevant Delphi version is not installed it will affect the results in a negative way, because RTL/VCL source code is not available new report section in Memory Report: MEMO8-"Created and freed objects", use this as a reference of all create-free in code improved display and sorting in the Subprogram Index Report in "Object-oriented Metrics Report", now sorts classes alphabetically simplified options dialog for multiprojects fixed an error in Missing Property Value Report, for buttons with ModalResult<>mrNone fixed issues with COWA1-"Controls that overlap visually" Pascal Expert 9.14.0 February 20, 2025 fixed a problem with inline variables fixed an issue with WARN46-"Local variables that are set but not later used" fixed an issue with WARN19-"Recursive subprograms" fixed issue with unit in "contains" having same name as package itself fixed issue resolving overload calls fixed issue with WARN46-"Local variables that are set but not later used" unnecessarily also listed variables that were not used fixed issue with REDU1-"Identifier not used", reported parameters to procedural types improved code that recognizes event handlers fixed error with variable not property initialized fixed issue with WARN11-"Value paramaters that are set" new section in Strong Warnings Report: STWA11-"Duplicated GUID". Please note that you may hav to update the template,if you want to include new sections new section in Strong Warnings Report: STWA12-"Equal if-then and if-else statements" Pascal Browser 3.5.35 February 20, 2025 fixed a problem with inline variables fixed issue with unit in "contains" having same name as package itself fixed issue resolving overload calls improved code that recognizes event handlers fixed error with variable not property initialized

FreeAndNil is something that you will need to use rarely (it might depend on the kind of code you are writing). In places where your code needs it logically it will be obvious that you need it and everywhere else you can use Free. The point that FreeAndNil can help you avoid errors and mistakes is full of holes. First, simple access after Free is usually easy to catch either by looking at the code (local variables) or by using memory manager in debug mode or other specialized tools. Next, FreeAndNil nils only single reference to the object instance. If you have multiple ones you will still have to deal with dangling pointers and you will need to learn how to use previously mentioned tools. Most of the problems with memory management in Delphi are caused by having multiple references to single manually managed object instance as such code is more complex. This is exactly the place where FreeAndNil cannot help you, but where using it will give you false sense of security. Another reason against using it everywhere, is that it obscures the code intent. Logically, FreeAndNil means that variable will be reused and this is important information. If you use it everywhere, you will have mush harder time reading the code and understanding its intent. And code which is harder to understand is also harder to maintain in the long run. Of course, that can be solved with comments, but then you will have to use them everywhere or you will never know whether some comment is missing somewhere. Manual memory management requires some discipline. thinking about the code you are writing enforces the discipline and makes you a better programmer. Taking the "easy" path where you will slap FreeAndNill everywhere just so you can avoid accidental mistakes and thinking is going to cost you at some point. Many existing codebases where it is used everywhere cannot be easily migrated to not using it as it can be hard to determine where it is needed and where it is not (except for local variables) and they need to continue using it indefinitely in all places, as the only thing worse than using FreeAndNil everywhere is using it randomly. Consistence in code is the king. In my codebase I have less than 50 places where I am using FreeAndNil (I cannot tell the exact amount as I have many smaller projects and it is not easy searching through them as some contain fixed VCL code which uses FreeAndAil a lot, so I cannot easily count usage in my files only) One of the advantages of being a new Delphi developer is that you don't have a lot of existing code where FreeAndNil was used in places where it is not needed and now is the right time for you to decide whether you want to pollute your code with FreeAndNil and stick with it forever or not.

Yes. We now know Marco can read the help. Beyond that I don't know what we learned. Maybe that they don't have any compiler engineers at hand since the product manager had to do first level support and guess about the work required. The issue was filed as a New Feature but treated as a Bug report. Not impressed.

Bug now fixed, it was a late change in V9.,4 flushing the log file to disk in case the request failed, but not actually checking the log was opened. You can fix it by removing the lines marked with V9.4. Angus

Instead of FreeAndNil implying a certain pattern I think it would be better to explicitly state, in a comment, when and why a certain behavior is expected. The projects I'm working on right now has something in the neighborhood of 200 calls to FreeAndNil in it. All except two are there to catch stale pointers; FreeAndNil gives us a nice AV that we can easily debug. Free would most likely give us a sporadic random error somewhere else. The two remaining cases are in a framework where we need a container var to be nilled before the object is destroyed. I won't go into why it's necessary; I'm sure you know the pattern. Anyway, for these two cases, the comments in the code clearly document why the FreeAndNil pattern is necessary. This is an old project and the introduction of FreeAndNil, where it makes sense of course, has helped us catch and eliminate countless bugs. Before I took over as the lead the code was littered with hundreds of empty try..except blocks simply because they had given up on trying to find the cause of the exceptions.

For me it is about code intent. FreeAndNil implies reusable variables and more complex instance lifetime. Free implies the opposite.

Strangely, that function was on my screen, I've just added some more parameter encoding and decoding functions to that unit. I've removed the / after text, it's a pretty basic function to avoid trying to convert images and files into unicode. Not sure why V9.3 changed anything, that text/ check was previously in the TriggerRequestDone2 function. Angus

Treat API keys and tokens as if they are passwords, and encrypt them, as we have forever, at least in properly written applications. The type of encryption and how you protect the key really depends on your security threat level. Angus

pasfmt is now available as a GitHub action. This enables easy integration into GitHub CI workflows. View it on the GitHub Marketplace: https://github.com/marketplace/actions/pasfmt

procedure TMyClass.StartAsyncTask; var LCancellationToken: ... begin // capture this local variable instead of field in anoanymous methods LCancellationToken := FCancelaltionToken; ... TThread.Synchronize(nil, procedure begin if LCancellationToken.Cancelled then Exit; // Callback-Code Writeln('Task finished gracefully.'); end); @Rollo62 Use the above approach to avoid capturing Self. You also need to check once again whether task was canceled when you synchronize, before you touch anything from TMyClass. also this will only work if the code that runs within the task does not touch anything from the class. If you can't avoid that you need to store task in field and wait for its completion before you destroy object.

FWIW, here's an example of improper use of FreeAndNil causing a race condition because a context switch happened between between the nilling and the free: https://supportcenter.devexpress.com/ticket/details/t812550/an-av-occurs-if-the-spell-checker-whose-usethreadedload-property-is-set-to-true-reloads

Equivalent, but not identical. Do keep in mind that there is one slight difference - FreeAndNil() nils the pointer before destroying the object. It is basically doing this: var tmp := FMyObject; FMyObject := nil; tmp.Free; So, if the call to Free() happened to raise an exception (ie, due to memory issues, or a bad pointer, etc), then the difference is whether FMyObject gets nilled or not. But in normal well-behaving code, this difference is negligible.

You will have to call Get8087CW() first and save the value before calling Set8087CW(), then do your work, and then call Set8087CW() again with the value you saved. Do this in each of your exported functions that suffer from the problem.

@Roger Cigol Here another thing to try Download and run Api Monitor from http://www.rohitab.com/apimonitor Use the correct bit version with your EXE and put the filter as shown in this screenshot Run your exe or you can attach it at anytime, so you are not limited to monitor everything, you can leave the exe running alone until the problem manifest, then attach the monitor and capture the log. After capturing the log, compare it with log from your own device and see where the failure exist after that you can share with us important pieces of the failure. Give extra attention to the failed API calls and their passed parameters, this is important, also as the monitor log record the handles and result so a comparison might narrow the failure origin. Feel free to expand the the API logging list for your own running EXE and that one device, you might find it useful reporting many failed API or wrong doing or repeated calls, also you can record SyncObjs API like Low Level APIs eg.RtlCriticalSectionxxxx... Mutex,Events... like these

As usual, there is no correct answer. Just opinions/options. Option 1: Just use FreeAndNil all the time. This way, you don't have to think about it, you can code it up in the Delphi IDE auto-complete stuff (and other tools like MMX). It is doing a bit of extra work, and calling an extra method, but you would need to doctor up some very contrived examples to have the speed penalty from FreeAndNil make any kind of impact on your code performance. Option 2: Use FreeAndNil if you free objects in the middle of a method when there is code executing afterwards and you are scared you may accidentally use the freed variable. Also use FreeAndNil in explicit cases where a valid state of an object variable is NIL. If you free objects as the last few lines of a method (or in a destructor) dont use FreeAndNil and rejoice at the nanoseconds of processing speed you have saved compared to option 1 Option 3: never use FreeAndNil. If you use FastMM there is an option on it to catch the use of freed memory. That option does slow down things quite a bit, but it works. That way, even if you reuse a freed object variable, FASTMM will throw an exception. Or, if you dont use FastMM then simply don't make coding errors 🙂 Seriously though, it can take ages to find errors stemming from using freed memory if you dont have FastMM debug mode on, and all the nanoseconds in the world saved from not using FreeAndNil is not worth the hours it will take you to find the bug.

This sort of topic comes up just often - and we always see a lot of great ideas - sadly the reality is we are unlikely to see many of those ideas actually implemented. Considering how much we pay for subscriptions etc - they should be making plenty of money - but that's not how it works with private equity owners - profit doesn't get re-invested. I'll trot these (now old) posts out just for fun https://www.finalbuilder.com/resources/blogs/delphi-language-enhancements (2016) https://www.finalbuilder.com/resources/blogs/delphi-103-rio-language-changes (2018) I had planned to do follow up posts with more ideas (people have sent me plenty over the years) but given the how things have gone since 10.3 language wise, what's the point? So my hopes for 13 (or what ever it's called) is a stable IDE, compiler, RTL etc - just like we all wish for every release - what's that definition of insanity - doing the same thing over and over expecting a different result 🙄

You don't "set" it. You launch it. Click the Windows Start Button and either expand the Embarcadero Delphi group, or type "Delphi" or "DPI" or "Unaware". One of those should reveal an icon for Delphi (DPI Unaware). If you launch BDS.exe by another method, add /highdpi:unaware as a command-line parameter.

Yep, I fought that headache even as a solo developer on a project. My dev machine is a laptop. The laptop's display has a different recommended scaling than the monitors attached to my docking station at the office. I would get so frustrated during commits because I only commit intentional or needed changes. I do not want commits littered with changes to Left/Top/etc due to the form designer running at a different scale/dpi. All of that headache thankfully went away after I discovered DPI Unaware mode.

Not per se. However, the problem is that once you use the DPI aware IDE, the measurements and coordinates in forms are according to your current Windows DPI and scaling settings. Which means that when someone with a different DPI or scaling opens the form, it looks like shit and the changes that someone makes, will again be impacted by their settings. So if two people with two different settings, takes turn in changing a form, you can get a form that keeps on growing or shrinking during the design. Personally, I would prefer that such a thing doesn't happen - so that I can benefit from HighDPI also in the IDE. It is not a trivial problem to solve. Pixel perfection becomes very hard once you have to deal with design time as well as runtime scaling.

My TOP list: 1. LSP improvements/quility. Now it doesn't work at all for big projects. (working on D11.3/D12). Refactoring doesn't work at all. 2. Generic Types improvements (more constraints, global generics, better work with interfaces (as/is support), better type infers, etc) 3. General IDE/Compiler/RTL/VCL quility. Better support for System.JSON / System.REST. 4. Ternary Operator (or make existing IfThen() as generic/magic intrinsic) 5. And the last one, Please, be more open for Delphi comunity - open Betas for all, open Roadmaps, Bi-monthly updates, etc.

I don't need any new features. I just need that the existing features work as intended. And there are many areas where existing features need to be made usable again (e.g. refactoring, code formatting, HighDPI). OK, one new feature would be nice: compiling for Raspberry Pi. But fixing the existing features needs to be done first.