Attila Kovacs

MMX forms are not HDPI conform, they are only ok if you are using the IDE in "blurry" mode.

What do you mean with "disabling Refactor menu"?

@Mike Torrettinni folding code is a bit tricky. You have to add the spoiler tag first, then post the message, then edit it again and post the code into the folding area. At least this was my workaround, to get it work. If anybody knows a better way to do it, please share.

Ah I see, well, I tried to convert some pdb's to yaml but after it failed on every pdb's I've found I got upset and forensic wiped it from my ssd 😉 I've no idea how good this yaml converter is but after that I've doubts.

0001:00401000 0190D0A0H .text CODE why is it .text? anyway 0001:0151D808 unit.frmxyz.BtnNewClick 0151D808 + 00401000 is the actual address (400000 is the image base and 1000 is the section alignment)

to the base address I can check it. Which section should I look in the map?

does pdb2yaml gives the same yaml back?

Yeah the GUID match can be done on the PDB, at least I've seen tools for do that yeah, when the pdb works yes, but untested?

@Anders Melander Maybe this could inject it, just to test how the pdb performs http://www.pe-explorer.com/peexplorer-tour-section-editor.htm

I'd still use jobs for creating compressed backups and copy them to another location. I don't know how this batchmove works but I'm sure it won't lock anything nor will it transfer transaction logs -if any-, so high chances that the data won't stay consistent.

This is it.

Is it tested now? Btw. interestingly WM_NCDESTROY's are still coming for all of the windows. The chained list theory fails? also as switching the freeing order of the scrollbars (vertical,horizontal to horizontal,vertical) free's the horizontal fine, then vertical becomes the next in the z-order and freeing it breaks the message chain again. If it has actually something to do with the Z-Order. Edit: Just to make sure, I've compiled the testapp with D2007 and D5, and run it even on XP, it's always the same.

I can't test it as ForceQueue is not present in Berlin, but in theory looks good.

Destroying a window from a different thread? Does it work?

this is really below every standard but what about if not (csDestroying in Application.ComponentState) then it works fine and I can't see any just as simple solution

I'm currently here

Buhh. Well, this is a new problem. Still, there is no legitimate reason to call consecutive DestroyWindows.

Aha! Now I'm getting closer. Have to fire up a new form to check.

in class destructor TStyleEngine.Destroy; FreeAndNil(FControls); will free all remaining StyleHooks. Who cares by who or when will it be free'd on closing the application?

The above non-quality? "fix" resolves the problem calling nested DestroyWindow and thus stopping WM_DESTROY propagation. The application does not yield any new leaks so I don't understand your point, what am I missing?

Ok, i see what you are saying, the remove should be evt. called, free() not. But the dictionary will be free'd even if it's not empty. So, I guess doesn't matter. Edit: no, calling remove results in other leaks. It was just fine that way.

Exactly this is the problem. That is what I wanted to avoid. Those are parented to the parent of the ListView and will be destroyed by the window manager.

stylehooks are no windowed controls like the scrollbar

just copy the vcl sources to your project dir and alter them it works evt. could be further higher in the callstack

if not (csDestroying in Control.ComponentState) then begin FControls.Items[Control].Free; FControls.Remove(Control); end; in class procedure TStyleEngine.DoRemoveControl(Control: TWinControl); cut nested calls to DestroyWindow