I have a form that implements System.Windows.Forms.IMessageFilter. The implementation of this interface requires a certain method that intercepts windows messages of certain types so that you can do some pre-filtering on them. The program works, but I have recently found that it has a real annoyance during debugging sessions. There are many forms in this solution, and only one form currently has this implementation (though I expect 4-5 more to get it). This form used to be created as it was needed, but it was a painfully slow form to create. Therefore, I changed it around so that a single instance of the form is created at startup, and the single instance is changed as needed. This works because it is the initial setup of the form, which happens during the constructor, that takes so long.
The problem I have run into is that the prefilter checks to see whether the form is visible, and if it is, then it may do something, and if it is not it does nothing. That is pretty painless....except that it is being called whenever a form is shown. This has no impact during runtime, as all that happens is that a simple check of a Boolean is performed and then it proceeds. During debugging, however, if I am stepping through form creation, the attempt to display the form triggers a call to this method, which just checks the Boolean and returns, which would mean that the form tries to display again, which prompts a call to the method again. In other words, I get stuck when I try to step through form creation because the act of display (or something prior to that, since it doesn't seem entirely consistent) causes a switch to the IDE to step through this method, followed by another attempt to display, which causes another switch to the IDE, and so on forever.
As a gneral rule, I can get around this by setting breakpoints somewhere after the form gets displayed. This can be tricky to do when debugging dlls, but it can be accomplished. It's pretty annoying, though. The best solution would be a #DEBUG directive that could remove that method during a deubgging session, but leave it in place if I am not in a debug session. Is there such a thing?
The problem I have run into is that the prefilter checks to see whether the form is visible, and if it is, then it may do something, and if it is not it does nothing. That is pretty painless....except that it is being called whenever a form is shown. This has no impact during runtime, as all that happens is that a simple check of a Boolean is performed and then it proceeds. During debugging, however, if I am stepping through form creation, the attempt to display the form triggers a call to this method, which just checks the Boolean and returns, which would mean that the form tries to display again, which prompts a call to the method again. In other words, I get stuck when I try to step through form creation because the act of display (or something prior to that, since it doesn't seem entirely consistent) causes a switch to the IDE to step through this method, followed by another attempt to display, which causes another switch to the IDE, and so on forever.
As a gneral rule, I can get around this by setting breakpoints somewhere after the form gets displayed. This can be tricky to do when debugging dlls, but it can be accomplished. It's pretty annoying, though. The best solution would be a #DEBUG directive that could remove that method during a deubgging session, but leave it in place if I am not in a debug session. Is there such a thing?
