Leaderboard

I don't know the answer to the question, but it may be useful: https://github.com/malcolmgroves/FluentLiveBindings

My goals for Indy 11 include adding use of LIBSUFFIX on the packages, changing the structure of the source folders, and reducing the steps needed to compile and install the packages. A few years ago, Embarcadero sent me a document listing the available commands that GetIt had implemented at the time (I'm assuming the same set of commands still applies today). There are CompileProject and InstallPackage commands listed in that document.

Yes, do not use TObject::Free() in C++, use the native delete operator instead. The delete[] operator is for freeing arrays allocated with the new[] operator, so the generated code is definitely wrong in that regard. A general rule of thumb is: allocator ->deallocator new -> delete (single item) new[] -> delete[] (array of items) (m|c|re)alloc() -> free() (C runtime) I also question the expert's decision to set the component's Owner to NULL, but without knowing what the expert actually does and what its input is, I could not say for sure if that is correct or not.

At one point, yes, to work around a bug in old versions of DCC32 related to the unit's use of the Zlib object files. There is a comment about that issue at the top of the Indy 9 version of IdCompressionIntercept.pas (though this version has a more detailed comment about it). I don't know if that bug is still an issue anymore, but the DCC32-based batch scripts still compile IdCompressionIntercept.pas separately (the MSBuild-based batch scripts do not).

I believe X->Free() is coming from the Delphi compatibility and is only used when importing Delphi object. Meaning it works only with TObject descendant. On the other hand delete X is a standard c++ operator that works with all objects whether they descend from TObject or not. On this page, there is an explicit note that says :

I have added a workaround for https://quality.embarcadero.com/browse/RSP-31170

maybe @dummzeuch indended to tag @Remy Lebeau instead?

Thank you François! I ended up creating my own TEmbeddedComboBox and used the handling suggested in Remy's answer to your linked SO question.. and SCORE! procedure TEmbeddedComboBox.WndProc(var Msg: TMessage); begin inherited; if Msg.Msg = WM_GETDLGCODE then Msg.Result := Msg.Result or DLGC_WANTTAB; end;

Have a look at this answer on StackOverflow. It is about a TEdit, but IMO the same concept applies to a TComboBox.

Use a TTimer to change the color of the button periodically. If you need a lot of them, you can derive your own TFlashingButton class/component to have an easy to use flashing button on the tool palette.

I had situations where an ADO connection to MS SQL Server would just "lock up" whilst executing a SQL statement and the call never returned. No exception, no error, just a lockup. I suspect it had something to do with our IT department's scheduled backup job saving the SQL Server VM because it always happened around that time of night. Since lockups like that are out of the programmer's control, all I could do was design a workaround and it turned out that a watchdog thread worked brilliantly.

This one was fixed in 10.4 https://quality.embarcadero.com/browse/RSP-23093 @NamoRamanaYou should provide a simple test case that reproduces the issue. Otherwise we are all guessing and hand-waving.

"Let it crash" is not on my list of stability strategies.

Please, don't inject common sense into the Anti-With argument 🙂 That said, I used to write WITH six even eight levels deep. Thought nothing of it, surely everyone knew the classes referenced within that and it was clear which one the property belonged to.. Returning to that code ten years later was less fun..

I am still failing to understand how banishing with from the language would help refactoring code that uses it. Don't get me wrong - I am no big fan of that thing either and very very rarely use it - but all the hate usually comes from the fact that it's been used in hard to maintain code. That code has been written already and needs to get fixed. Yes, if it were not part of the language anymore at some point in the future code would not contain it anymore - but people that want to write bad code would still have plenty of opportunities to do so.

It's not only about deleting components, it basically affects any change, like reparenting, renaming and even resizing. The best part is that you will only find out by either viewing the parent form/frame in the IDE, or at runtime. The core reason is that inherited forms/frames/data modules often (not always) have extreme redundancy. Look at their DFM files. They repeat their parents content. This is especially funny when you have a huge ImageList that gets copied again and again into dozens of subclasses. The only solution I could ever find is to always pay attention to your DFM files. At every commit in your source control system, do check out your DFM files! Undo changes that were added automatically although you didn't change anything. When I work in Delphi with things that involve the user interface, I spend roughly 30 % of my time reverting redundant changes in DFM files.

Hi I have this problem with a Standard resolution from 1920x1080

Hmmm... another new feature in delphi that doesn't actually work properly.. I think I'll give it a miss for now.