I just use a windows.forms.tabcontrol and added a TabPage. After that I dragged an UltraChart into the TabPage. Now whenever I change something in the code of the form with the TabControl and go back to designer-mode, VS2008 already throws that kind of exception above.

Any word on this?  I am evaluating your latest NETAdvantange Win Suite as a replacement to the v2 controls already used extensively in my project.  I am getting exactly the same error.  As the other poster mentioned, I have a UltraWinChart on a form inside a tab page.

The only difference is that the original design was using v2 UltraWin controls and I upgraded by replacing the references, as noted in a Knowledgebase article from your site.  However the results are the same.

I am planning on purchasing the upgrade license, if I can get this to work seemlessly. Otherwise, I will have to start over, and will re-evaluate the project effort.

Mark

bug 14814 has been confirmed fixed in the following versions:

Unfortunately, I have the latest release of you tiral software (9.1.20091.1000). 

I attempted to start over with the original code and manually replace the v2 chart controls with the v9 controls.  It worked until I closed and re-opened Visual Studio (2008). 

I am not really sure what the resolution on your end was to fix this issue, or if there is additional action needed in my application (VB.NET 2008) I need to take.  However, it renders my current form unusable, as I cannot even visually take action while this message is present. 

Any other thoughts on this?

Thanks, Mark

the fix didn't make it into the release version of 9.1.  there is a hotfix available which fixes the problem, but i'm not sure if you can download it with the trial version.

Further to my previous post, this fix is not right.  It has broken our application.

We have a number of infragistics controls on a usercontrol.  This usercontrol is then added to a System.Windows.Form.TabPage.

For all sorts of reasons we are accessing that usercontrol by geting the tabpage and then Controls(0) on the tabpage.

Since the hotfix there are now two controls on the tabpage instead of one and Controls(0) returns a IGWinToolTip!

Bottom line here, the Infragistics controls are on a usercontrol! if you have to add the IGWinToolTip it should be added to the usercontrol ( the direct parent of the Infragistics control in question) not at some random place in the control heirachy! 

Even better, I have written a number of controls using the System.Windows.Forsm.Tooltip and adding it directly to the controls.  E.g. we have a CustomTextBox inherited from the System.Windows.Forms.TextBox and the ToolTip becomes a child control of the TextBox.  Why can your controls not operate in the same manner each containing their own ToolTip without messing up the control heirachy?

to the man,

i ran your sample project against the build scheduled to be released in may.  there is still a problem, so the scenario in 10779 must be slightly different from yours.  i entered a new bug, # 17442.  we'll try to get this fixed for the june service release.

Thanks David,

I appreciate how difficult it can be with the tooltip parenting.  I managed to code round the issue, realising that expecting just one control in the collection and not testing for the correct one was bad programing practise anyway.  My code is much more robust as a consequence.

I have attached a sample app showing tooltip offset the problem.  This should be compiled against v 8.3

The tooltip offset related to use in a TabControl is pending release under another bugfix (10779).  Sorry to have doubly inconvenienced you with two bugs.  To be certain that the fix for 10779 addresses the issue you're experiencing, if you could provide a sample project we will add that to our criteria for verifying the fix.

The parenting issue is by design; without that design there would be problems with tooltips appearing underneath other controls.  For example if your chart were in a panel centered on a form, the tooltip would not be visible outside the bounds of that panel.

I assure the tooltip's place in the control hierarchy is not random, it's actually one of the more complex pieces of our code, and as you can see it's one of the most problematic.  Unfortunately we don't have a more elegant or consistent solution to this without using unmanaged code.

So the side effect of changing the control at index 0 is unavoidable, I think.  Hopefully you can work around this by using the string indexer on the Controls collection, or by looping through it and finding an instance of your UserControl.

I am reviewing 10779 again now to ensure it will be fixed in the upcoming hotfix, which is currently being reviewed by our QA team.  I hope we can get you over these hurdles quickly so you can get back to coding your app instead of struggling with our bugs so much.