Knowledgebase contradicting itself...

I'm not familiar with the case which led to the article which recommended adding a call to ForceNativeMessageFilter but I do know something about the newer case which recommends against it. In the latter case, the call to ForceNativeMessageFilter caused an issue and we found Infragistics documentation that states that you shouldn't call ForceNativeMessageFilter if the application will also call Application.AddMessageFilter. The AVM calls Application.AddMessageFilter internally. In this case, the conflict caused a bug in the application. There may be other cases where you wouldn't see any incorrect behavior.

I don't see a way to avoid the catch 22. Is this an issue for you or is it just something you noticed when reading the new article?

Hi Matt, this is currently not an issue for us.

We used to experience the "sticky menus" from the second KB article, but adding the ForceNativeMessageFilter didn't help there (so we didn't add it).

As Matt indicated, this is not a safe thing to do.  In general, I would recommend NOT solving problems with low-level calls like this.  It always leads to trouble!  In the OpenEdge environment, we cannot always use solutions that would work in a straight .NET environment.  I would recommend that someone update the original KB article to indicate that this may have solved one person's problem, but that it is not safe.  It is also possible that that article was written before we started using AddMessageFilter.  I don't think we've done that from the beginning.  Matt can chime in if that's not correct.  But if that is the case the original KB article is no longer valid.

We started using AddMessageFilter in 10.2B and 10.2A02 so it wasn't there from the very beginning, but close. We didn't know that ForceNativeMessageFilter conflicted with AddMessageFilter until two days ago so it's understandable that the article has hung out there for so long. I agree that it should be changed to say that we don't recommend using that solution.

Lieven, I went back to your original case and tested the reproducible. The problem still occurs even in OpenEdge 11.5 (Infragistics UltraControls 14.2), so it really is a catch-22.

In your repro, ForceNativeMessageFilter corrects the issue and does not cause any other visible problems. Other applications might not be so lucky, because the AVM makes a call that Infragistics documents as incompatible with ForceNativeMessageFilter (see Matt's comment above).

Fortunately, the customer in the new case found that the problem he had used ForceNativeMessageFilter to correct no longer occurred in his current OpenEdge version (11.3).

We haven't yet heard from anyone who has both a problem that ForceNativeMessageFilter corrects and a problem caused by using ForceNativeMessageFilter, but that could conceivably occur. Anyone in that situation should contact Technical Support so we can look for a solution that does not require ForceNativeMessageFilter.

In the meantime, I will remove article 000033230 from the public knowledge base because we can no longer recommend that solution, and add a note to article 000058698 for readers to contact Technical Support if they are currently using ForceNativeMessageFilter to correct a specific problem.

Thanks for pointing out the conflict between the two articles.

Thanks Roberta.

Thanks!