HeartWare

I have v5.85 from September with Delphi 13 support.

When these errors happen, it is often enough to do a complete rebuild of the program (at least that's my experience). If not, you'll have to eliminate code one block at a time to find the one that triggers the issue and then dive down into it and see if you can do that in another way that doesn't provoke that error.

How is that supposed to work (Delphi being a single-pass compiler)? You haven't defined the TFoo.Foo yet at the place you use it.

No - grammatically it's three different products "Delphi", "C++ Builder" and "RAD Studio". I asked it how to make code for "RAD Studio" and it didn't know, even though the headline said that it (should) know... To be what you have, it would have to be " An AI assistant trained to answer your questions and generate code for Delphi and C++Builder (RAD Studio).

My very first question pushed it up into a corner: The headline on the web page says: RAD AI Companion An AI assistant trained to answer your questions and generate code for Delphi, C++Builder and RAD Studio. So I naturally asked it: How do you generate code for RAD Studio that isn't Delphi or C++ ? To which it answered: Unfortunately, I have no knowledge on this subject. RAD Studio primarily supports Delphi and C++ for code generation.

I'm not disagreeing (don't have the knowledge to do that), but do you really think that a MUL/DIV sequence takes less time than a JMP? I know that the newer processors have all this read-ahead and stuff, but (and I honestly don't know) does it really slow it down that much to flush the read-ahead cache and the pipeline? I'm not contradicting you in any way - just surprised (but my assembly knowledge is primarily back from the Pentium age, so I'm not fluent in all the new optimizations done on-chip in modern CPUs).

What "optimizations" are you referring to? My test for unnecessary DIV/MUL when calculating to/from 96dpi? I always go via 96dpi (in the generalized function) as this will ensure that the scaled value is predictable and always the same, regardless of what the current DPI is (I get a more precise and consistent value if I go 150->96->200 than if I go from 150->200 directly - assuming that the 150 was a calculated value from 96 originally. Maybe not with 150/200 exactly, but other combinations can lead to rounding errors)

Didn't know of the "ScaleValue" but it doesn't say from the description that it always scales the value as given from 96dpi to the current scale. It seems like it has the usual weakness of being an accumulated (floating point) scaling factor, which means that it'll slowly go out of sync if you move the form back and forth between various DPI settings. I prefer my solution (or David's if he ever gives it and it is different from this (IMO faulty) implementation). From what I can deduce from the source, it also scales from the control's original scaling factor being 1, so if the .DFM file is saved in 150% it scales out from that size (144dpi) and not from 100% (96dpi). I may be wrong on this, but that's what it seems to me from the source code.

Okay - then I'll just do it the way you described... Oh, Wait! You didn't! Guess that means I'll continue doing it the way I've always done it...

You can just set Splitter.Top := 0, it will then "move down towards alBottom" until it hits the MemoBottom.Top (just like it does if you drag it in the IDE Form Designer). But generally, I don't have this issue if I make sure that there are only two items set to "alBottom" and I only modify the height of the main control (not the top of the splitter). It will "push" the splitter upwards (in my experience).

For scaling pixel values, I use this helper function: {$IFNDEF CPUX86 } {$IFNDEF CPUX64 } {$DEFINE PUREPASCAL } {$ENDIF } {$ENDIF } CONST DefDPI = WinAPI.Windows.USER_DEFAULT_SCREEN_DPI; {$IFDEF PUREPASCAL } FUNCTION Scale(Pixels,OldDPI,NewDPI : NativeInt) : NativeInt; BEGIN IF OldDPI<>NewDPI THEN BEGIN IF OldDPI<>DefDPI THEN Pixels:=MulDiv(Pixels,DefDPI,OldDPI); IF NewDPI<>DefDPI THEN Pixels:=MulDiv(Pixels,NewDPI,DefDPI) END; Result:=Pixels END; {$ELSEIF DEFINED(CPUX64) } FUNCTION Scale(Pixels{RCX},OldDPI{RDX},NewDPI{R8} : NativeInt) : NativeInt; ASSEMBLER; ASM MOV RAX,Pixels CMP OldDPI,NewDPI JE @OUT MOV ECX,DefDPI // Also clears upper 32 bits of RCX MOV R9,OldDPI CMP OldDPI,RCX JE @SKIP1 IMUL RAX,RCX IDIV R9 @SKIP1: CMP NewDPI,DefDPI JE @OUT IMUL NewDPI IDIV RCX @OUT: END; {$ELSEIF DEFINED(CPUX86) } FUNCTION Scale(Pixels{EAX},OldDPI{EDX},NewDPI{ECX} : NativeInt) : NativeInt; ASSEMBLER; ASM CMP OldDPI,NewDPI JE @OUT CMP OldDPI,DefDPI JE @SKIP1 PUSH NewDPI MOV ECX,OldDPI IMUL EAX,DefDPI IDIV ECX POP NewDPI @SKIP1: CMP ECX,DefDPI JE @OUT IMUL NewDPI MOV ECX,DefDPI IDIV ECX @OUT: END; {$ENDIF } And these CLASS HELPERs: CLASS FUNCTION TMonitorHelper.Scale(Pixels,OldDPI,NewDPI : NativeInt) : NativeInt; BEGIN Result:=HeartWare.VCL.Funcs.Scale(Pixels,OldDPI,NewDPI) // The base function from previous code block // END; FUNCTION TMonitorHelper.Scale(Value : Integer) : Integer; BEGIN Result:=Scale(Value,Screen.DefaultPixelsPerInch,PixelsPerInch) END; FUNCTION TFormHelper.Scale(Pixels,OldDPI,NewDPI : NativeInt) : NativeInt; BEGIN Result:=Monitor.Scale(Pixels,OldDPI,NewDPI) END; FUNCTION TFormHelper.Scale(Value : Integer) : Integer; BEGIN Result:=Monitor.Scale(Value) END; Then I just use Form1.Scale(8) to get a 96dpi 8-pixel scaled value at whatever scale factor the form (or rather, the monitor upon which the form is located) currently is at.

I noticed one difference between mine and @DelphiUdIT's code. In my code, the {$I} was in the INTERFACE section - in his in the IMPLEMENTATION section. Don't know if that's the culprit, but considering the other stuff that happens vis-a-vis INTERFACE/IMPLEMENTATION it could be. I always have my {$I}s in the INTERFACE section (actually, usually before the INTERFACE keyword) and that could explain why I have never encountered any issue with it.

Okay. Just tried. This Main.PAS file in an empty VCL project: unit Main; {$I INCLUDE.INC } {$IFDEF AA } hfjkdfhkj {$ENDIF } interface uses Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics, Vcl.Controls, Vcl.Forms, Vcl.Dialogs; type TForm203 = class(TForm) private { Private declarations } public { Public declarations } end; var Form203: TForm203; implementation {$R *.dfm} end. And this include file: {.$DEFINE AA } Now, compile the program. Then remove the "." from the define (remember to save the file) then compile again - I get an error on the hfjkdfhkj line. So it definitely picked up the need to recompile the Main.PAS file.

Yes, but who turns that off? Much code (even in System units) will fail with that setting off, and lots of code will be executed unnecessarily (and may even produce wrong results since it isn't supposed to be called).

If you change an include {$I} file included in a unit file, that unit file will be detected as modified and will be recompiled with a normal compile (or at least it should, and does in my experience).

In that particular case, just use isVisible:=Assigned(Foo) and Foo.Visible

Have you tried unit Unit2; interface uses Unit1; type TControlHelper = class helper(Unit1.TControlHelper) for TControl end; implementation end. (Haven't tried myself, but logically, I think it would work)

How does Rapid.TList<STRING> compare to THashSet<STRING> (only for checking if an entry exists in the list or not)? It'll be called thousands of times (the list itself will be pretty small - 5 or 10 entries)

I have this contact in India who specializes in Delphi-to-COBOL translations: Ran Slirpa (or Loof Lirpa as he's also known). I can put you in contact with him, if you wish.

CONST [ref] is on the surface the same as VAR but it allows a CLASS variable of a descendant to be passed. So where a VAR TObject only allows variables declared as TObject, a CONST [ref] TObject parameter passes a reference (like VAR does) to the instance pointer, but allows all descendants of TObject to be passed in. This eliminates the issue with a typeless VAR to FreeAndNIL also accepting non-classes.

True, but then you'd have to have the full PNG and JPG decoding library included (as well as all other image formats decoding libraries) instead of just checking the header (which, granted, wouldn't allow you to check if the file is loadable - only that it claims to be what the file extension says). It all depends on what you really want to check and how extensive the check should be.

That won't detect a .PNG file with .JPG content (it will merely detect that it is some form of picture).

Something like this (for Image Formats - the ones I detect for): Using a TBytes Helper "StartsWith" and "Contains" - but should give you an idea. Not 100% but enough for my usage, and should allow you to adapt the methodology to your own needs.

Unfortunately it's an uphill battle. You can't win. Whatever you do, they will find a way around it, as you cannot differentiate between legal individuals and a mass-request from different IPs. They can hit you from such diverse places as Australia, India, Brazil, Germany and Canada at the same time, and you have no way of knowing if they are from the same person. Is there a pattern in their requests? Do they go alphabetically? If so, you can do heurestics detection (but they can circumvent this by going random). You can also limit the speed with which you accept requests (ie. a minimum of 1 min. between requests), but they will soon detect this and space it out to a random value between 1:10 and 1:30, and you risk annoying your legitimate users.

Ooooh - someone else had the same idea 🙂