Temporarily Disable "protected override void WndProc(ref Message m)"

Question

Temporarily Disable "protected override void WndProc(ref Message m)"

Stuart Coutts 61

How do I Temporarily Disable "protected override void WndProc(ref Message m)"?

The Solution consists of two projects...
"MainProject" is all the main code written in VB
"CheckBoxComboBox" is a fancy combobox control written in C#

When running the VB code, to set up the control (.location, .size etc), the changes trigger several sections of the C# code which all start with...

"protected override void WndProc(ref Message m)"

Which is fair enough but it also happens when I call say a .location.x etc

Because I have a fair number of the controls on the form; the form can get quite stuttery, as the code continually loops thru.

I would like the ability to enable and disable this.

Is there a way to directly enable/disable this?
Or, is there a way to pass a boolean variable between the two projects?

I've tried to do both of these already, as well as enable/disable the controls but i'm not getting anywhere.

Accepted answer

0 additional answers

Your answer

Answer 1

You cannot temporarily disable a method in C# (or any language that uses a compiler pretty much). It sounds to me like your WndProc is slow and you're trying to speed it up but I doubt that it is going to solve your issue. You mention 2 projects, why does that matter here? I don't believe the # of projects is relevant here so I'm ignoring that aspect.

WndProc is called whenever Windows needs to send a message to your window (or any control for that matter). This is automatic and cannot be disabled. This is how Windows works. But WndProc is called many, many times throughout the lifetime of an app and is highly unlikely to slow anything down. It literally just takes the message type and calls an overridable method on the corresponding class. GIven we do this throughout the lifetime of OOP apps all the time this is really fast. I'd wager you'd have to be in the 100s of calls a second before your processor would even remotely notice it. The problem isn't with WndProc I'm willing to bet.

Without knowing more about your app I'm going to guess at what is going on here. Your code is adding a control to the form and moving it around. Every time you do this it is going to trigger a redraw of the UI and if you're using resizable/anchor/docked controls then they have to have their layout recalculated. This is expensive if you're doing this on the fly (like dragging a control across the window). What you need to do is optimize your logic if this is a requirement.

One approach to fixing this is to set all the properties before adding the control to the parent. Then it only has to adjust the layout once. If you really, really need to make lots of UI changes then call SuspendLayout on the form first. This prevents the form from updating until you are done. This is exactly how the designer-generated code works. The user will see the UI "freeze" while you are doing whatever you're doing but then the form will refresh once.

Stuart Coutts 61 Reputation points

2021-06-23T15:13:24.153+00:00

Many thanks for that response. That was packed full of insite.

Definitely setting up the control before adding it... 100%

I clearly didn't fully understand what the WndProc was.

Ruling the WndProc out... I quickly did a strip down version with a regular combobox and there is no noticeable delay. So I am guessing that the fancy checkbox combobox control is just super heavy; unfortunately the controls aesthetic and functionality is exactly what I'm after so i'll have to live with form taking a second to cycle.

I'm not confident enough with C# or making custom controls to go in and attempt to improve on it. If your interest it is the following control...

CheckBox-ComboBox-Extending-the-ComboBox-Class-and
Michael Taylor 60,326 Reputation points

2021-06-23T15:21:39.283+00:00

Without looking at the code it is hard to say where it is slow but custom drawing inside a combo is going to be slow by nature of what it is doing. However you should be able to profile the code and see where the delay is. If it is rendering, most likely, then not much you can do outside of optimizing that code. If it is slow adding multiple items then you can use BeginUpdate on the control to delay repainting until you are done. We normally use that when we're adding a bunch of items to a list control like this.

Outside of that you might look for a newer implementation somewhere. I know there are several commercial versions that are fast but they cost money. The code you're using is based upon a really old version of Winforms so there may be some optimizations that can be done.
Stuart Coutts 61 Reputation points

2021-06-24T08:53:18.86+00:00

Excellent thanks.

Yeh there are a couple of warnings to not add and remove items a certain way as the code is obsolete.

Much appreciated.

Share via

Temporarily Disable "protected override void WndProc(ref Message m)"

0 additional answers

Your answer