.Net API Hooking or .Net Common Dialogs subclassing

  • Thread starter Thread starter pavel.gritsay
  • Start date Start date
P

pavel.gritsay

Hello everyone,

I have met a problem.
If anyone on Earth knows why does .NET 2.0 is subclassing Common
Dialogs' owner window, and why doesn't it set back the prevous WinProc
address when quiting but is calling DefWndProc directly???

Does MS think that none will subclass those dialogs for particular
needs? hmm...

The only way found was API hooking, just to hook SetWindowLong and
resubclass it again but here again MS comes into the scope, I could
find no chances to hook APIs, which were DLLImported.
Can you guys give me any suggestions?
 
Hi,

If this is the case and if you know when microsoft's subclassing happens you
can try to subclass after. This way all the messages will go through your
WndProc first and then you can let MS code call the DefWndProc as they wish.
 
Well, actually the problem is that I can not catch the moment when it's
unsubclassed.You see when closing common dialog removes the subclassing
and set the address of DefWinProc. This doesn't allow me to subclass it
again as I don't know when to do this.
 
For some purposes you can try to use Dialog Workshop .NET components instead
of subclassing
These components are designed to replace standard Windows Forms dialog
components. Specifically,
you can add your own WinForm in the dialog (add your controls, preview pane,
etc.),
customize File list view control, add MRU files tab (like in VB6), etc.

Also each dialog can be displayed as modeless window or it can be inserted
as a child control in
your own Windows Form.

Supported dialogs: open/save, browse for folder, print, color, font, run,
about, page setup, etc.

Please visit for details: http://www.componentage.com

Best regards,
Alex
 
Back
Top