Anders Melander

No. TaskMessageDlg is just wrapper around a TTaskDialog component and unfortunately TTaskDialog doesn't provide any way to specify the cxWidth parameter of the TASKDIALOGCONFIG structure passed to TaskDialogIndirect. You could create your own wrapper that calls the TaskDialogIndirect API function instead. Actually now that I think of it you might subclass TTaskDialog and override the TCustomTaskDialog.CallbackProc method to intercept the TDN_CREATED or TDN_DIALOG_CONSTRUCTED notifications. The notification messages gives you access to a pointer to the TASKDIALOGCONFIG structure used to create the dialog but I'm unsure if you can do anything with that. There are no messages you can send the task dialog to update the width. By the way, take note that the cxWidth member specifies the width in dialog units - not pixels.

No, not using a standard TPopupMenu. The menu loop is being handled by Windows (via the TrackPopupMenu API function) and you do not have any control of how it behaves - and that's how it should be; Altering the behavior of something like a menu just leads to poor usability. The fact that you've had to resort to keyboard & mouse hooks should be a hint that they don't want you messing with it. I suggest you display a non-modal form instead. You can easily make that behave like a popup menu, with your custom behavior, without raping the system.

Yes, that's what I wrote. However the metadata comes from WinMD, which is also used by WinRT:

@Jeff Overcash Maybe read the whole thread before you reply. The issue has already been resolved.

Edit post seems to be broken so here's the link on how to read from WinMD: https://stackoverflow.com/questions/54375771/how-to-read-a-winmd-winrt-metadata-file

Isn't this just something that read metadata from WinMD and write wrappers? You can do that already so I guess the news is that they're generating WinMD from the SDK headers.

Could you give it a rest with the formatting? Your posts are hard enough to tolerate without it.

Read the documentation or example some existing code that works. The error message is pretty clear about what the problem is. I don't need to explain it to you.

MyCmd isn't initialized so that's probably the cause of the AV. You need to create an instance of TADOCommand or reference an existing instance. Get rid of the local var declaration if you meant to be using the TADOCommand with the same name on the form Apart from that you haven't told us where in your code the problem occurs.

Not being a native English speaker I just looked up what "deprecated" actually means and it turns out that it's just what you describe: Discouragement of use. My bad.

In practice we can see that MS have not updated MDI for a very long time. The window chrome for MDI child windows does not match the latest style. Yes I'm aware that it's not recommended and of the limitations. My point was that claiming that it's deprecated is just FUD aimed at driving developers towards alternatives such as SDI. Ironically my experience with replacing MDI with SDI is that the users often find SDI confusing. They feel safe with MDI because they know where their windows are - they're always inside the MDI parent. I've tried with docked windows as a middle ground but that is far too advanced for some users.

Deprecated by whom? I don't think I've ever seen that claim backed by a first hand source. I think it's a bit like the claim that circulated about Win32 being deprecated which surfaced when .NET was released. Or about GDI when GDI+ was released.

Yes it looks nice but the rules that are used by different versions of Windows to determine what DPI awareness and scaling to apply are much more complicated than what that table suggest. Trying to make a UI for editing the manifest has become a game of whac-a-mole.

Works for me too (in projects of any size).

There's this old one, as I'm sure you know: https://github.com/andremussche/map2dbg/tree/master/tds2pdb I think I tried it once, for use with VTune, without success.

How is that relevant to the topic?

The ones you found probably does something like this, so I guess that's oldish too : // ----------------------------------------------------------------------------- // // RunningAsAdmin // // ----------------------------------------------------------------------------- // Detect if we're running at an elevated security level. // ----------------------------------------------------------------------------- function RunningAsAdmin: boolean; var hToken, hProcess: THandle; pTokenInformation: pointer; ReturnLength: DWord; TokenInformation: TTokenElevation; begin Result := False; hProcess := GetCurrentProcess; try if OpenProcessToken(hProcess, TOKEN_QUERY, hToken) then try FillChar(TokenInformation, SizeOf(TokenInformation), 0); pTokenInformation := @TokenInformation; GetTokenInformation(hToken, TokenElevation, pTokenInformation, SizeOf(TokenInformation), ReturnLength); Result := (TokenInformation.TokenIsElevated <> 0); finally CloseHandle(hToken); end; except // Ignore error - although none of the above should throw an exception... end; end;

Yes, we know the macro function only works in the editor. Now you know too.

Yes they did. And some made significant contributions with bugs that can not be fixed because no one understand the code, it's poorly documented (if at all) and it's using undocumented algorithms. Maybe that's acceptable in some projects but if I'm to maintain the code then it's not. It doesn't matter how brilliant the code is if it can't be maintained. Code like that is poison to a library. There are many things that Graphics32 would benefit from but a rewrite isn't one of them. Of course if you dislike the architecture and the constraints of working within or incrementally evolving the existing framework then I can understand why you'd want to start from scratch, but by discarding over 20 years of experience and optimizations you're bound to repeat some of the mistakes - and make some new ones 🙂 As I see it Graphics32 and Image32 doesn't really target the same problem space.

A bit premature wouldn't you say. If you consider the rest of the pipeline then using optimized assembly for this will not make any significant difference. Good point. I think I would just not use TBitmap for this and either create a DIB directly or use a TBitmap32 from Graphics32 (with a memory backend).

Hmm. I can't really say. I guess it greatly depends on what you're doing. FWIW, the alpha composition part is actually documented in the help. One of the things people often struggle with is the difference between blend, merge and combine and in which situations to use what. Even I get them mixed up at occasionally. If performance is critical then it would be good to know about the different data types: TFloat, TFixed and integer. I think everybody understands float and integer but I guess fixed precision math isn't common knowledge. The graphics32 TFixed is a 32-bit binary with 16 magnitude bits and 16 fractional bits. I don't have any good links at hand. Google "fixed point".

I can't see how resampling would make it any faster unless your streaming implementation really sucks. Resampling would mean that you'd have to read all the pixel data, juggle it around, store it in a new buffer and then read from that buffer instead. Considerably more expensive than whatever solution you can come up with that just reads the data via Scanline. You haven't shown how you RGBA and RGB types are declared but assuming the R-G-B ordering are the same and the A is the last (i.e. high) byte then just read 4 bytes (that's a DWORD) from the source and write 3 bytes. Rinse, repeat. If the source is ABGR and the destination is RGB (e.g. TColor) then you can rearrange the bits like this: function ABGR2RGB(ABGR: DWORD): TColor; begin Result := ((ABGR and $00FF0000) shr 16) or (ABGR and $0000FF00) or ((ABGR and $000000FF) shl 16); end; or in assembler: function ABGR2RGB(ABGR: DWORD): TColor; asm mov EAX, ECX // Remove this for 32-bit rol EAX, 8 xor AL, AL bswap EAX end;

Set a break point on the CreateFile (and maybe OpenFile) API function and set the break condition to match the name of the file somehow.

Yes, that was my assumption. You can use the Graphics32 to map from a quadrilateral to a rectangle too (for example I use it for perspective correction), but it's true that one of the quadrilaterals must be a rectangle. However since it can do both forward and reverse transformation you can actually use two of them to do quadrilateral to quadrilateral transformation although that would not be very efficient. A better way would be to use one to create the source matrix, use a second to create the destination matrix, multiply the first with the inverse of the second and use the result as the transformation matrix. I believe that's also the method you use. I.e. Matrix = SrcMatrix * Adjoint(DstMatrix) True, but I don't think Graphics32 has ever targeted the average user. It does have a steep learning curve and does require an understanding of at least some of the low level principles - such as alpha compositing.

As far as I know Graphics32 has supported 64-bit for ages. Doesn't it work for you?