C because I know pretty much what is happening under the hood and it doesn't change much. Second point is important for older folk who just want to do their job and not have to learn new syntax with every project.

Sometimes elements that appear to be common at first are not really common. Say for example, both forms have a name field. One might jump to the conclusion that the name field is common to both forms and factor it out for reuse. Then down the track one of the forms needs the name field to be changed to say nick name. Now we realise in hindsight that just because the code was identical between the forms in the first instance they were not really common code and more refactoring is now required. When you factor out common code try to make sure the cut is in areas that are unlikely to change if requirements change.

I get the Daily Insider by email. Recently the links started opening inside a codeproject frame. Is there an option to prevent the Daily Insider news links opening in a code project frame? I find it very annoying to have to click "Remove Frame" every time. Putting the linked articles in a frame screws with mousewheel scrolling the article and drastically reduces the available screen real estate for reading the article. All for what? I already know that the link to the article has come through Code Project! Regards, Felix

Preventing Unexpected Message Pumping in Third Party Libraries - An example using DirectShow[^]

Hi Dybs, naturally that is a great solution if you can easily identify SomeEvent and NestedEvent, however in my case this is not so easy, there are many events that can lead to a DirectShow call and many events that could be unsafe to process nested within another call. I could search through my code and put locks in all event handlers that look likely to cause trouble but this discipline would need to be maintained in maintenance and future development, so is not ideal. The solution you propose is really a special case of my proposal to override the wndproc of all forms (by using a custom BaseForm class). The whole point of an event queue and a single gui thread is so that in programming these events one can consider them as occurring serially. Overriding message processing for the whole app will place some overhead on all activity so I'd rather avoid the wndproc solution. Another disadvantage is that by effectively discarding some messages I might see strange behaviour, for example if a user started typing while in the lock the letters entered up to the point of releasing the lock would be lost. The alternative solution I'm going to investigate is to start a second thread with its own message loop and make all DirectShow calls synchronously on that thread. Due to good architectural choices early on in the project the references to DirectShow in my application are limited to one module so it should be easy to ensure that all calls are routed through the second thread. If it works I'll post an article here to explain the solution. Regards, Felix

Yeah, it is not ideal. As there seem to be so many helpful knowledgeable people on here, I'll describe the actual problem I'm trying to solve and see if there are any other ideas. The problem I'm having is that inside one of my event handlers I'm calling some DirectShow code. Inside the DirectShow code a message loop is run to handle the COM calls. Unfortunately this inner message loop pumps my input events so if I click quickly with the mouse I can get a second event handler running nested inside the first at the point of the DirectShow call. I'm not sure what the correct term is for this behaviour so I am calling it reentrant event processing (although it is not strictly rentrancy as the event handlers are likely to be different ones). The problem arises because all the event handler code assumes that it is single threaded (which it is) and that events will be processed in order from the queue. I get unpredictable crashes of my application due to this problem. One solution I am looking at is to simply discard user input messages and timer messages while a message is being processed, hence the original topic of this thread. Another more complicated but better solution is to run a second thread with it's own message loop and invoke the COM calls on that thread. I haven't looked into the details of this too much as yet. I've got a simple project that demonstrates the problem which I can post if anyone would like to see it. Thanks for your help! regards, Felix

Thanks for your answer. I think I may have to add a custom BaseForm class that overrides the wndproc and which all of my Forms inherit from. That way I could insert global message processing which would be similar to writing a custom message loop.

Hi All, I have a situation where I need to do some custom message filtering. Unfortunately I need more functionality than provided by the IMessageFilter system or by overriding a Form's wndproc() method. What I need is to be able to run code before and after a message is processed and optionally drop selected messages. As I understand it: The IMessageFilter system only allows filtering out selected messages (can't run code after they have been processed) A Form's wndproc method only sees messages destined for that form. (I need to handle all messages for the entire application) In an unmanaged application say in visual c++ it would be a simple matter of implementing ones own getmessage/dispatchmessage loop. In the dotnet framework the actual message loop is implemented in native code and is inaccessible to the programmer. Does anyone know a solution for this? Regards, Felix