The inkprovider would only be automatically created if you were using one of those application classes as those are actually injecting the inkprovider. If you're still having an issue then I would recommend contacting the support group and providing a sample that demonstrates the issue.

Hi, Andrew.

We have the same problem in our application.

We do use CAB, though we never derived from any classes mentioned above.

What should we do?

Thanks, Andrew! I was going to mention that we were using CAB but it didn't seem relevant. You fix worked for us though.

You must be using CAB in which case the default behavior for our cab application class (you must be deriving from IGWindowsFormsApplicationBase<TWorkItem, TShell> or one of its derived classes) is to create an inkprovider for each form. You can prevent this by overriding the ProvideInkSupport property and return ShowInkButton.Never.

What you are saying sounds good, but it happens not to be the case. We do not have an UltraInkProvider on any of our forms, or anywhere in our application! We are not even referencing the ink assembly; when we switched to 2007.3 all these ink buttons simply appeared on our controls. The only way I have found to disable these buttons is to place a provider on the form and then set its ShowInkButton property to false. But this is kludgy, requires a lot of work, and we don't really want to reference the ink assembly in the first place. There must be some sort of "global" ink provider that you are unaware of, and we would like to know how to disable it.