Leaderboard

Personally, I see no reason to add more options to obfuscate my code. I can do well enough with goto and with when I need to scratch that itch. And when I really want to spice things up, there is always absolute.

Alternatively, your UI seems to be very similar to a table/grid layout so you could potentially use a grid component with support to input fields such as combo boxes. Those grids are usually highly optimized to handle thousands of rows with various data types and input options. They usually allow the dynamic instantiation of input controls (such as combo boxes) when a row is actually being edited to save resources. I highly recommend DevExpress' ExpressQuantumGrid: https://docs.devexpress.com/VCL/171093/ExpressQuantumGrid/vcl-data-grid Or their ExpressVerticalGrid: https://docs.devexpress.com/VCL/403720/ExpressVerticalGrid/concepts/vcl-vertical-grid Both of which I extensively use for this kind of tasks.

You say you have hundreds of TComboBoxes, but the screenshot above only shows 7 (presumably 11?). If this screen is similar for the rest of the app, where each item on the side list displays its own page with just a handful of ComboBoxes on it, then a simple solution would be to NOT load every page at one time, but instead to load one page at a time only when it is made visible to the user, and then unload it when it is no longer visible to the user. That will greatly speed up your load times, and then you don't have to resort to using hacks like owner-drawing, OnDropDown refreshes, etc. You can move each page to its own TFrame that you create and destroy when needed, that way you still regain design-time support for your page layout.

I guess I just have a different experience. In 30 years I have not had my system infected with a virus, I have not fallen for a phishing attack, and have never been infected with ransomware. The idea that I should install something like Webroot which would actively interfere with my ability to use my computer and do my job makes no sense to me given the that track record. BTW, I don't buy this line that Defender doesn't "perform well." But I don't think I'll get into that off-topic conversation. I will say that I am amused by this a little. You've identified software on your computer that is actively interfering with your ability to use it and do your work, but you have convinced yourself that it is somehow in your best interest. 🤷‍♂️

All components that have the form as Owner (which includes all components dropped on the form in the IDE designer) are automatically destroyed when the form is destroyed. So your query components are destroyed but whether that automatically releases serverside resources depends on how the component, especially its destructor, is implemented. But a TFDQuery will close the query when it is destroyed, so your scenario is OK.

Oddly enough, I implemented a serial modbus protocol in Turbo Pascal over 35 years ago to talk to PLCs. https://github.com/LarsFosdal/DOSTimberDryingKiln/blob/main/source/MODBUS.PAS

Yes, by all means, fix the barn door after the horses come home, LOL!

As does the Delphi debugger.

But we have GetIt 🤦‍♂️ Package management it something I have been harping on about for years (as have others). https://www.finalbuilder.com/resources/blogs/delphi-package-manager-rfc I am working on a solution this is where it's at right now - https://delphi.dev Still a work in progress - contributions welcomed.

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.

1. Debuggers, debuggers, debuggers - multithread handling is abysmal today 2. Make HighDPI actually works as intended - it is useless in a team as is - unless everyone runs the same scaling 3. Generics constraints for enumerated types to enable the use of conversion to/from ordinal values, use set operators, etc. 4. Native ARM64 compiler for Delphi for Windows (and Linux/Raspberry PI, but Windows has prio) 5. A 64-bit IDE that ensured that EMBT was dogfooding 64-bit VCL and RTL and raise the quality As for AI, I wouldn't mind an AI that could look at code and suggest improvements - perhaps as a part of the static code analysis, or one that could explain "what does this code do". I don't really need or want an AI to generate code. If it is a standard, a lib should already exist. If it doesn't and there is no standard that covers the need, I'd be happy to have an AI outline alternative approaches - but given that the wide scope of parameters that goes into a design, I think it is unrealistic to expect that it would come up with the ideal suggestion without us writing a huge requirement. The output of VLLM generators is extremely dependant on precise and accurate specification statements, and writing those are almost as hard as writing good code. As for AI and privacy - keep your secret credentials separated from your code. Other than that, I don't think that many of us write code that truly needs to be hidden for secrecy reasons, although it is obvious that it will be necessary to ensure that privacy permeates the use of AI.

From my codebase: // disable range checks and overflow checks so that Abs() functions in case Value = Low(Value) {$R-} {$Q-} function CopyIntegerToAnsiBuffer(const Value: Integer; var Buffer: array of AnsiChar): Integer; var i, j: Integer; val, remainder: Cardinal; negative: Boolean; tmp: array [0..15] of AnsiChar; begin negative := Value<0; val := Abs(Value); Result := 0; repeat DivMod(val, 10, val, remainder); tmp[Result] := AnsiChar(remainder + Ord('0')); Inc(Result); until val=0; if negative then begin tmp[Result] := '-'; Inc(Result); end; Assert(Result<=Length(Buffer)); i := 0; j := Result-1; while i<Result do begin Buffer[i] := tmp[j]; Inc(i); Dec(j); end; end; function CopyIntegerToWideBuffer(const Value: Integer; var Buffer: array of WideChar): Integer; var i, j: Integer; val, remainder: Cardinal; negative: Boolean; tmp: array [0..15] of WideChar; begin negative := Value<0; val := Abs(Value); Result := 0; repeat DivMod(val, 10, val, remainder); tmp[Result] := WideChar(remainder + Ord('0')); Inc(Result); until val=0; if negative then begin tmp[Result] := '-'; Inc(Result); end; Assert(Result<=Length(Buffer)); i := 0; j := Result-1; while i<Result do begin Buffer[i] := tmp[j]; Inc(i); Dec(j); end; end; function CopyInt64ToAnsiBuffer(const Value: Int64; var Buffer: array of AnsiChar): Integer; var i, j: Integer; val, remainder: UInt64; negative: Boolean; tmp: array [0..23] of AnsiChar; begin negative := Value<0; val := Abs(Value); Result := 0; repeat DivMod(val, 10, val, remainder); tmp[Result] := AnsiChar(remainder + Ord('0')); Inc(Result); until val=0; if negative then begin tmp[Result] := '-'; Inc(Result); end; Assert(Result<=Length(Buffer)); i := 0; j := Result-1; while i<Result do begin Buffer[i] := tmp[j]; Inc(i); Dec(j); end; end; function CopyInt64ToWideBuffer(const Value: Int64; var Buffer: array of WideChar): Integer; var i, j: Integer; val, remainder: UInt64; negative: Boolean; tmp: array [0..23] of WideChar; begin negative := Value<0; val := Abs(Value); Result := 0; repeat DivMod(val, 10, val, remainder); tmp[Result] := WideChar(remainder + Ord('0')); Inc(Result); until val=0; if negative then begin tmp[Result] := '-'; Inc(Result); end; Assert(Result<=Length(Buffer)); i := 0; j := Result-1; while i<Result do begin Buffer[i] := tmp[j]; Inc(i); Dec(j); end; end; {$IFDEF RANGECHECKSON}{$R+}{$ENDIF} {$IFDEF OVERFLOWCHECKSON}{$Q+}{$ENDIF} No heap allocation. I guess I could avoid that DivMod now and do something better. The main point is that a good runtime library should have building block functions like this that allow us to perform such conversions without forcing heap allocation. The RTL should have functionality like this on top of which all conversion functions can be built. Then the RTL function can be optimised and everyone benefits.

Thanks again - this old F6 disease is still present in Delphi 12!

Project Magician follows a different scheme: It has an option to remove all child entries so that only the base values are effective. Unfortunately it doesn't force you to change base values only nor does it warn if you don't.

Unfortunately, changing any version information values at least once will break inheritance and the values in that build configuration have their own life. There is no built-in way to establish inheritance - unless the entries are removed from the dproj with some exterenal tool. That is the reason why Project Magician has this option