HeartWare

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 🙂

Which is why I suggest a mode that works internally in 96dpi but shows (and allows edit) in the monitor's native DPI. Yes, it will mean that you are restricted to placing components on a 2x2 grid if your monitor is at 200% and the grid will be unsymmetrical if you're at 150%, but since all components will be locked into the same grid, you can still align the positions and sizes.