Anders Melander

If you PM me the source of your GDI implementation I'll see if I can easily derive a Graphics32 version from it.

That's not entirely true. If you do an Upgrade migration then it copies the package settings. If you do a Version migration then it doesn't. The UI could have made the distinction clearer... [Edit] Sorry, I see you already made this point. For some reason you later posts didn't show when I wrote the above. The forum has been extremely slow for me the last few days. It's almost unusable. We're probably getting DDOSed harvested by some engine.

Here's the Graphics32 Thick Lines example; Using TCanvas.LineTo (which is basically just a GDI LineTo) a single line takes 4.8 microsecond. That's over 10,000 lines per 50mS. If we're comparing GDI vs Graphics32 1:1 then it's the 206,000 vs 6,000,000 values that should be compared since those are both for aliased 1-pixel lines. That's on my new system. On my old system (~15 years old) things are quite a bit slower but still over 2,000 lines per 50mS: Interestingly, GDI on my new system is almost 5 times faster than the old, while Graphics32 is only twice as fast. This is likely because Graphics32 is CPU-bound while GDI is GPU-bound. Those are all slower than Graphics32. Apart from that I would definitely use a chart libraries for something like this rather than roll my own, but that's just me. One thing that has prevented me from using TeeChart in the past (way back, to be honest) was that it didn't draw anti-aliased, which made the graphics look like something from the 80s - and although I do love 80s music, the graphics sucked back then 🙂. Does it do anti-aliasing these days? What does you chart control/update logic look like? Are you doing something like this: procedure TFoo.OnMouseMove(...); begin UpdateValues; RepaintChart; end; or like this: procedure TFoo.OnMouseMove(...); begin UpdateValues; Chart.Invalidate; end; procedure TFoo.OnChartPaint(...); begin RepaintChart; end; or maybe: procedure TFoo.OnMouseMove(...); begin UpdateValues; Chart.Invalidate; Chart.Update; end; procedure TFoo.OnChartPaint(...); begin RepaintChart; end;

- or one could create a single, nicely anti-aliased tag bitmap and use 9-patch to paint it. With some additional logic, you can even have overlapping labels. I made a demo of this some years ago but I can't find the source anywhere. I assume you meant GDI+. Using stuff that's bundled with Windows doesn't increase the footprint and the amount of code to wrap the API is negligible.

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.