madshi.net

For what it's worth, I have seen this, too. I have a user who uploaded 5 bug reports with no main thread and they were all freeze detection. What's more, she was able to continue using the application without any problems -- except that when the freeze detection interval elapsed, she would get anoth...

Oops, change cdecl to stdcall or it will crash in 32-bit. (I fixed it in my code sample above)

fixed code in above.

This is not pretty, but it works. It should definitely be added in a more orderly fashion. Add this to TExceptionBox.Create:: var H: HMODULE; _SetThreadDpiAwarenessContext: function (dpiContext: THandle): THandle; stdcall; DPIAwareOld: THandle; begin {$ifdef log}log('TExceptionBox.Create'); indentLo...

Even Berlin update 2 doesn't have the headers for the new dpi calls. Bah.

Resurrecting this thread, because solving this should be really easy now. With Windows 10 Anniversary Update, there is a new user32 procedure called SetThreadDpiAwarenessContext that should fix this problem, assuming the madExcept reporting dialog is in its own thread: https://msdn.microsoft.com/en-...

I have plenty of experience with win32 API, but it would take looking through the MadExcept code to give you any useful details, and like you my list is too full. Theoretically this is a simple matter of looking at the current DPI, and then MulDiving all of your coordinates and sizes used when creat...

Well, so much for my idea.

As it turns out, you can't change DPI awareness once it is set. So if the application is DPI aware, you can't temporarily disable it.

The only solution is to factor the DPI into the dialog construction.

Maybe you can work around the issue yourself, then you don't have to wait for me? madExcept.pas exports these: // do you want to be notified when a madExcept exception box was created/destroyed? var OnExceptBoxCreate : procedure (exceptBox: HWND; simpleMsgBox: boolean) = nil; OnExceptBoxDestroy : p...

Yeah, I'm aware of the problem. madExcept's windows are created by pure win32 APIs, instead of using VCL, because madExcept's windows must be thread safe, which the VCL is not. Making all this high-DPI capable is surely possible, but would cost quite a bit of development time, so I'm not sure how q...

An easy way to test this is to create a new VCL application and make sure to set it as a high-dpi aware application in the manifest settings (Delphi 10 Seattle). Have a button that throws an exception. Compile, then change your display scaling in Windows 10 to 200% (which is the default on a Surface...

I've been working on making my application completely high-dpi aware. On my new Surface Book, which defaults to 192 DPI, the MadExcept exception report dialog is almost completely unusable because it is not scaling itself based on the monitor DPI. 100% scaling is super small on a 3000x2000 monitor t...

Unfortunately that brings me back to the problem I had in this thread (and the breakpoints still disappear when the process runs anyway). I will see if I can duplicate that problem in a small test project. So the problem of an infinite AV on startup (as reported in that thread) can't be reproduced ...

Unfortunately that brings me back to the problem I had in this thread (and the breakpoints still disappear when the process runs anyway). I will see if I can duplicate that problem in a small test project.

If I create an empty fresh project, I can use paserver on a VM to deploy and debug the project with breakpoints functional. If I enable madExcept for the project and drop a madExcept control on the form, and then try to deploy and debug, breakpoints stop working (but I can still see threads in the r...