I have two questions.
1) I found a little gem of code for how to make a control scroll smoothly.
Great. But it overrides the WndProc method, so to use it, I had to tear out the FlowLayoutPanel I'd dropped on the form at design time, subclass FlowLayoutPanel, and then finally instantiate my new class and create all the properties manually and change all references to the control to be this.Controls["ControlName"]. (Or I guess I could make a class-level variable which is essentially what the control originally was, though how do they let you use intellisense on it when it's not declared anywhere?)
So now I'm just wondering if there was in fact a runtime way to do it.
Can I do something simple as this, where MainPanel is the name of the control:
MainPanel = (SmoothScrollingFlowLayoutPanel)MainPanel
It can't be that easy, can it? Even so, it's annoying because I still have to have the subclass (which may be a good design decision but I'd like the freedom to one-off it). So would it be possible to put the code into the parent of the FlowLayoutPanel something like this:
private Delegate void WndProcHandler(ref Message m);
private WndProcHandler w;
public void SomeCode() {
w = MainPanel.WndProc; // get reference to existing wndproc method
MainPanel.WndProc = WndProcSmoothScroll; //replace with new method
}
private void WndProcSmoothScroll(ref Message m) { // make smooth scrolling work
if (
(m.Msg == WM_HSCROLL || m.Msg == WM_VSCROLL)
&& (((int)m.WParam & 0xFFFF) == 5)
) {
m.WParam = (IntPtr)(((int)m.WParam & ~0xFFFF) | 4);
}
if (w != null) { w(); }
base.WndProc(ref m);
}
I realize this is probably pretty naive. I'm treating the WndProc method like it is an event, and it's not.
2) So then my second question is, if WndProc was an event instead of a method, how would I do the same thing—store a copy of the original list of handlers for an event, install my own event handler to run first, then call all the original event handlers?
TASTY BITS
In case anyone is interested I noticed an optimization possible in the smooth scrolling code:
//m.WParam = (IntPtr)(((int)m.WParam & ~0xFFFF) | 4);
m.WParam = (IntPtr)((int)m.WParam ^ 1);
Since we want to turn the last 16 bits from 5 to 4, we can just flip the last bit (XOR) rather than AND then OR.
If I understand your question correctly, all you want to do is override WndProc
at runtime. If so, all you need is a little Win32 magic.
Every control has a "handle" which identifies it so the operating system can send messages to it. This handle is exposed through the Handle
property on every control. The underlying Win32 system actually allows you to listen to any control's WndProc
as long as you have its handle. This means that you don't have to inherit from a Winforms control to modify its Win32 behavior. System.Windows.Forms.NativeWindow
in .NET wraps this underlying functionality.
Here's an example of how you might accomplish this:
class SmoothScrollIntercept : System.Windows.Forms.NativeWindow
{
public SmoothScrollIntercept(IntPtr hWnd)
{
// assign the handle and listen to this control's WndProc
this.AssignHandle(hWnd);
}
protected override void WndProc(ref Message m)
{
// listen to WndProc here, do things
if ((m.Msg == WM_HSCROLL || m.Msg == WM_VSCROLL)
&& (((int)m.WParam & 0xFFFF) == 5))
{
m.WParam = (IntPtr)(((int)m.WParam & ~0xFFFF) | 4);
}
base.WndProc(ref m);
}
}
Then in the code behind, attach the intercept to the control:
SmoothScrollIntercept intercept = new SmoothScrollIntercept(myControl.Handle);
// myControl is now using smooth scrolling, without inheriting from the control
No, what you are asking for is impossible. You'll have to subclass as you did before.
Even if it were an event, you wouldn't be able to do what you're after. The public interface for an event only exposes add
and remove
; there is no way to obtain or assign the actual delegate(s) attached to the event.
However, looking at the problem from a different perspective, you may be able to make use of the IMessageFilter
interface in order to accomplish the end result you're looking for.
Edit
After looking at your code again, IMessageFilter
won't work, as you cannot modify the message within PreFilterMessage
; you can only examine or suppress it. Your best bet at this point is to override WndProc
in the parent Form
and try to make your manipulations there. It doesn't look like there's a generic solution to your problem.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With