Anders Melander

The version I use works. I don't have time to check the difference in how we do it but you can see for yourself if you want to: https://bitbucket.org/anders_melander/dwscriptstudio/src/15b205a8a7b4d461b786452aa4e0ee548779fe92/Source/amScriptDebuggerMain.pas#lines-1184

I would guess that the override is based on the message number but it should be easy to determine; Just try it.

The omission of brc32.exe is probably an installer bug Use brcc32.exe instead or better yet, use the MS resource compiler rc.exe

I just did: TCanvas.Pixels: 320 mS skia4delphi: 130 mS TBitmap.Scanline: 60 mS

Here's a C implementation: https://github.com/yparitcher/libzmanim The code looks well written.

You could roll your own: https://en.wikibooks.org/wiki/Computer_Programming/Hebrew_calendar Here's some code but I have no idea about what language that is: http://www.chelm.org/jewish/calendar/algorithms.html

https://docs.microsoft.com/en-us/windows/win32/com/activex-controls-registry-information You can add the 16x15 bitmap to your Delphi project using Project > Resources and Images. Searching the Delphi source for "ToolboxBitmap32" I can see that TActiveXControlFactory has a ToolboxBitmapID property which you can use to specify the resource ID of the bitmap. The value of this property is written to the registry when the ActiveX control is registered. A .dcr file usually just contains the Delphi design time glyph of a component - I.e. the glyph you see on the component palette in Delphi. It has nothing to do with ActiveX controls.

https://en.wikipedia.org/wiki/Law_of_triviality

Exactly. It's pretty pointless to suggest different ways of doing conversion if the conversion will be done with TryStrToFloat, StrToFloat or the like. And it's even more pointless when this is in all likelihood premature optimization.

The only built-in way to determine if a string can be converted by TryStrToFloat is to use TryStrToFloat. You could reverse engineer TryStrToFloat to make a version that only parsed the string and didn't actually do the conversion but my guess is that the majority of time used by TryStrToFloat is used by the parser, not by the conversion. But if you are reading from a text file then it's likely that the I/O will be your real bottleneck and as David hints at, you should profile first and optimize next.

It depends on what you mean by "can be converted to number". If your definition is that TryStrToFloat returns True, then the answer is no. If you're willing to give up some of the features of TryStrToFloat then the answer is yes, but you are going to have to implement it yourself - in assembler. But why do you need it to be faster? Is it a bottleneck for you?

https://www.rabbitmq.com/protocols.html#amqp-10

Are you asking if RabbitMQ supports AMQP 1.0?

You don't need to add your own sub-fora. Just post in the main Delphi Third-Party.

This belongs in Delphi Third Party.

Well, it's not that I don't envy the versatility of C++ but I really don't enjoy trying to maintain (or even just read) code that fully uses that versatility.

One hour into the video I wanted to shoot myself in the head - But then I remembered that I no longer program in C++ 🙂 Apart from that; Good stuff. When I heard Bjarne at the end I thought: He sounds tired of C++. Maybe he should try Delphi 🙂

That request is almost older than Delphi itself. I get that they're not interested in making it easier to use old versions of the product, but I don't get that they aren't interested in making the lives of 3rd party developers easier (in this regard at least).

I haven't used the Develop Express spreadsheet (except that it seems that all their other controls now has dependencies on it 😞) but I would think it'd be trivial to maintain a dictionary on the side that links objects to cells...? type TCellReference = record Row: integer; Column: integer; end; TCellStuff = TObjectDictionary<TCellReference, TObject>; Also, if the spreadsheet architecture is anything like their other controls, then you should be able to customize what class is used to represent cells.

Y-key broken?

I agree. In my own code I assume "unknown version" = Last known version+1. That way new versions doesn't break the code and I very rarely need to update the include file.

I've just committed updated packages for Delphi 11 and added Delphi 11 to GR32_Compiler.inc (and cleaned it up a bit).

I would think that it's just a matter of adjusting the dependencies of the existing packages with the corresponding D11 dependencies and recompile, but I'll look into it.

There's only one L in ProDelInterface27.