HeartWare

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.