Anders Melander

madExcept Eurekalog

Fix or work-around? The safest work-around is to not call TBitmap.SaveTo* more than once on the same bitmap: bmp.Assign(png); bmp.SaveToFile('out_1.bmp'); bmp.Assign(png); bmp.SaveToFile('out_2.bmp'); I would guess (I would need to examine the logic more than I have time for, to be sure) the quick-fix is to modify TBitmap.WriteStream so it only counts the palette size once: if (FDIB.dsbmih.biBitCount > 8) and (FDIB.dsbmih.biClrUsed = 0) then begin // optional color palette for hicolor images (non OS2) Inc(Size, ColorCount * SizeOf(TRGBQuad)); Inc(HeaderSize, ColorCount * SizeOf(TRGBQuad)); end; but to be honest, if this was my code, I would throw out the current TBitmap.WriteStream implementation and rewrite it from scratch. It's a horrible mess.

Here's the algorithm used when saving a TBitmap: Calculate Size based on HeaderSize, the number of pixels, color depth, and current value of BitmapInfoHeader.biClrUsed (number of entries in the palette). Calculate number of entries in the palette: ColorCount Adjust Size with the value of ColorCount: Size := Size + ColorCount * SizeOf(Pixel) Set BitmapFileHeader.bfSize = Size Write BitmapFileHeader to file Set BitmapInfoHeader.biClrUsed = ColorCount Write BitmapInfoHeader to file Write palette entries Write pixels BitmapFileHeader is a local variable that is nilled and initialized each time. BitmapInfoHeader is a class variable that is used to store the bitmap properties. Can you spot the bug? 

I think it has always worked. It was just near impossible to understand how to use it. I used it for D11->D12 and D12->D13. Each time I had to do it a few times before I got it right.

Is there any reason why you aren't just using the bundled migration tool (apart from the (unsurprisingly) horrible usability of it)?

Kudos on managing to avoid the one style we can all read. Rename across units have never worked for anything but the most trivial code (okay, maybe in the first couple of versions). And without that it's useless. I can manage rename in a single unit on my own, without the help of refactoring (but of course I wouldn't mind it). MMX doesn't have rename refactoring. I haven't got it installed anymore, so I can't verify, but every time I install it it's because I need rename refactoring and every time I discover that it can't do it properly and uninstall again. What you are referring to as "rename refactoring" is just a text search/replace in MMX.

I share that experience - but it was an optional component so you could have just chosen not to install it.

I think we all have this problem. Version control helps but it's still annoying.

and...?

I know the actual implementation wasn't the point, but I just can't leave code like that unchallenged. It haunts me. function TBaseFoo.BetterFoo: IFoo; var Item: TComponent; begin Result := nil; Item := Self; while (Item <> nil) and (not Supports(Item, IFoo, Result)) do Item := Item.Owner; end;

I think we have a case of tunnel vision here. Extracting the version number from the About Box is obviously not the way to do it; There's no contract that specifies how the returned string is formatted and if they change the format, the code breaks. "Delphi 14.0 Version 12.34.567.890 by Embarcadero®" The solution is really, really simple and does not involve the ToolsAPI at all: Assuming this is being done from a package or a DLL, use GetModuleFilename to get the filename of the host application (i.e. bds.exe). Use GetFileVersionInfo to get the version info.

Just like GPS navigation systems made people forget how to find direction, apparently AI has made people forget how to think for themselves 🤔 From where do you think the about box gets its version number information?.

It should have been hidden for Delphi. Having it visible but but disabled, with no way to make it enabled, is just confusing; Poor UI design. https://learn.microsoft.com/en-us/windows/win32/uxguide/win-dialog-box#disabling-or-removing-controls-vs-giving-error-messages

That's nice. If I send you this 800.000 line legacy project I need to clean up, when can you have it ready for me? 🙂 It was written by someone who apparently had a sporadically stuck shift key, didn't like white space, and couldn't make up his mind if 1, 2, 3, or 8 space indents were the way to go.

Apart from the AI stuff, you do know how to determine the IDE version and build number, right?

A bit of Googling tells me that the purpose of the certificate is to enable it to scan encrypted HTTPS traffic.

Is that a problem? If so, why?

Nah. Although I have no love for Russia, I have no beef with Kaspersky (and these days I trust the US just as little) and I've found that it's the one that works best for me. I'm using the free version, FWIW.

Well, I got this one during install so I'm already a little bit "excited"... https://threats.kaspersky.com/en/threat/Trojan.Win32.Lazzzy.gen/

But at least you can not satisfy someone every time.

There are so many bugs and limitations in TListView (the Windows control, not the VCL wrapper) that I have found that as soon as I spend more than 10 minutes trying to work around something in it, it's often a better idea to replace it with something else. Just yesterday I needed the first column in a listview right-aligned; Forgetaboutit - and out it went.

Delphi 11

As I said, I haven't timed it - and it depends. MUL is dirt cheap. DIV is a little more expensive but not nearly as bad as it once was. Branches are almost always bad but if OldDPI=NewDPI most of the time then the jump out is obviously worth it. I honestly wouldn't bother doing this in asm in the first place. Unless you are using it to scale graphics in real-time, or something like that, then it's a completely wasted effort. Also remember that pascal code can be inlined (avoiding the call overhead), while asm functions can't. I would replace the MulDiv with a simple expression; You likely don't need the 64-bit and overflow handling baked into MulDiv (which is a Windows API function, btw - not cheap).

That's not a fork... Never mind. Not my problem.

Exactly