winform problem

  • Thread starter Thread starter Lloyd Dupont
  • Start date Start date
L

Lloyd Dupont

I have some C# code using interop heavily.
Is it possible that, in some ways, that when I call some non managed code
it, somehow call WndProc?

basically is it possible to have a stack like that
=====
WndProc
SomeEvent
NativeCode
WndProc
SomeOtherEvent
NativeCode
WndProc
......
====

Also, I want to wrap any event management in some sort of start/end code
block.
I have no main window (instead I started with Application.Run() and I have
multiple visible windows).
Is there a "Main" event queue which I could wrap?

because even If I override
class Form1 : Form
{
override WndProc()
{
StartBlock();
try { base.WndProc(); }
finally { EndBlock(); }
}
}
it's not goind to be called if I have event on some Form2, or is it?

How could I be user ALL forms get a special start/end treatment around
events?
Is it only possible?

--
Regards,
Lloyd Dupont

NovaMind development team
NovaMind Software
Mind Mapping Software
<www.nova-mind.com>
 
Lloyd,

The short answer is NO.

The only such place would be the thread message loop. Application class is
the one that runs the message loop. It provides method for installing
message filter, but this filter can only pre-process messages (it is called
before the message to be dispatched to the application).

Even if it was allowing pos-processing of the messages it wouldn't be of a
great help. Don't forget that only fiew messages comes through the message
loop (posted messages); the posted messages are basically mouse, keyboard,
windows timers, WM_PAINT (in some cases) as well as couple others. Most of
the messages are sent, meaning that they are not dispatched by the message
loop, but rather it is most likely direct call to the windwos prcedure.
Internally when message is sent across the thread boundaries they go through
the message queue as well, but all is hidden inside Windows and is not
exposed by the API.

What I'm trying to explain here is that most of the messages goes directly
to the target form or control and cannot be handled anywhere, but inside
form's WndProc.

Actually there is one solution that I just came up with. You can use
NativeWindow class to subclass all your forms. These NativeWindow instances
will fire the pre- and post- events and will pass the message for actuall
processing to the forms. This way you can attach this to any form without
the need of deriving from the class. You can even wrap everything in a class
and hide the details of all this subclassing and stuff, so the code will
register/unregister forms and hook the events on one place.

HTH

Stoitcho Goutsev (100) [C# MVP]
 
Ho cool!
I was thinkind to have all form inherit from a form of mine design.
but I have designer problem with my interop code. (my interop code
unfortunately requires setting environment variable and specific directory
layout) but.. you give me idea how to solve that!!!

Stoitcho Goutsev (100) said:
Lloyd,

The short answer is NO.

The only such place would be the thread message loop. Application class is
the one that runs the message loop. It provides method for installing
message filter, but this filter can only pre-process messages (it is
called before the message to be dispatched to the application).

Even if it was allowing pos-processing of the messages it wouldn't be of a
great help. Don't forget that only fiew messages comes through the message
loop (posted messages); the posted messages are basically mouse, keyboard,
windows timers, WM_PAINT (in some cases) as well as couple others. Most
of the messages are sent, meaning that they are not dispatched by the
message loop, but rather it is most likely direct call to the windwos
prcedure. Internally when message is sent across the thread boundaries
they go through the message queue as well, but all is hidden inside
Windows and is not exposed by the API.

What I'm trying to explain here is that most of the messages goes directly
to the target form or control and cannot be handled anywhere, but inside
form's WndProc.

Actually there is one solution that I just came up with. You can use
NativeWindow class to subclass all your forms. These NativeWindow
instances will fire the pre- and post- events and will pass the message
for actuall processing to the forms. This way you can attach this to any
form without the need of deriving from the class. You can even wrap
everything in a class and hide the details of all this subclassing and
stuff, so the code will register/unregister forms and hook the events on
one place.

HTH

Stoitcho Goutsev (100) [C# MVP]

Lloyd Dupont said:
I have some C# code using interop heavily.
Is it possible that, in some ways, that when I call some non managed code
it, somehow call WndProc?

basically is it possible to have a stack like that
=====
WndProc
SomeEvent
NativeCode
WndProc
SomeOtherEvent
NativeCode
WndProc
.....
====

Also, I want to wrap any event management in some sort of start/end code
block.
I have no main window (instead I started with Application.Run() and I
have multiple visible windows).
Is there a "Main" event queue which I could wrap?

because even If I override
class Form1 : Form
{
override WndProc()
{
StartBlock();
try { base.WndProc(); }
finally { EndBlock(); }
}
}
it's not goind to be called if I have event on some Form2, or is it?

How could I be user ALL forms get a special start/end treatment around
events?
Is it only possible?

--
Regards,
Lloyd Dupont

NovaMind development team
NovaMind Software
Mind Mapping Software
<www.nova-mind.com>
Click to expand...
Click to expand...
 
Back
Top