Anders Melander

I know the SaveDC/RestoreDC doesn't solve your problem. In my code it's just there to leave the canvas in the same state as it was in when I got it. The key point from my code was the clearing of the pen handle since in my case I had problems with the pen color. Try reversing the order of the pen and brush assignments. I've had similar problems and as far as I remember that was what I did to solve it.

My mistake. The ACanvas in my code is a DevExpress TcxCanvas - I didn't think about that. I think that if you use SaveDC/RestoreDC with a TCanvas then you'll need to lock the canvas to guard against the DC being changed. Something like this: ACanvas.Lock; try SaveDC(ACanvas.Handle); try ... finally RestoreDC(ACanvas.Handle, -1); end; finally ACanvas.Unlock; end;

They are Windows API functions: https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-savedc

I've just read the Delphi 5 help and as far as I can see Delphi 5 does produce DRC files. What makes you say it doesn't?

I use the following to draw corners (top-right in this example): const CornerSize = 8; var Triangle: array[0..2] of TPoint; begin ACanvas.SaveDC; try ACanvas.Brush.Color := clRed; ACanvas.Brush.Style := bsSolid; ACanvas.Pen.Handle := 0; // Work around for messed up pen handle sporadically causing line not to be drawn ACanvas.Pen.Color := GetHighLightColor(ACanvas.Brush.Color); ACanvas.Pen.Style := psSolid; Triangle[0].X := AViewInfo.BoundsRect.Right-1; Triangle[0].Y := AViewInfo.BoundsRect.Top; Triangle[1].X := Triangle[0].X - CornerSize; Triangle[1].Y := Triangle[0].Y; Triangle[2].X := Triangle[0].X; Triangle[2].Y := Triangle[0].Y + CornerSize; ACanvas.Polygon(Triangle); finally ACanvas.RestoreDC; end;

Why would you want to do that? Just curious.

You're the only one talking about timers, but even if you used a grandfather clock the method would work. If you break the application at random you will have 50% higher likelihood of hitting lineB than lineA and each time you do this the likelihood increases. This is exactly how a sampling profiler works. Are you saying sampling profilers are a hoax?

Why wouldn't a profiler, real or not, help there? What do you think a profiler does?

Yes, of course that didn't do anything. Why would you expect it to? I think you need to take a step back and think about what you are doing instead of just trying random stuff. Take control of the problem. The numbers you have posted shows that you are either measuring time in microseconds or using the thousand separator incorrectly. If you are measuring microseconds then stop that. Numbers that small are not relevant here. One of the first things you should have done would be to locate the bottleneck by profiling your code. If you don't have a profiler or don't understand how to use one then you can emulate a sampling profiler by just running the application a few times and pause it in the debugger. Unless the slowdown is evenly distributed then there's a statistic likelihood that the call stack will show you where the application is spending the majority of its time.

No you're right - I misread the documentation of the callback. The callback function does get passed the window handle of the task dialog though: ...which can then be used to modify the window. Not that I would recommend it.

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.