You can try to use a creation filter to place an element in the tab item area. Another way to try this would be to add a "dummy" Form to you MDI parent. Give it the "add new" icon and no caption. Then handle the TabSelecting event of the UltraTabbedMdiManager. When the tab being selected is for this dummy Form, it means the user is clicking the "add new" button tab. Cancel the TabSelecting event, add your new Form, and select it.

If I go with the dummy tab approach, how would I prevent drag-drop between groups for the tab representing the dummy form?  What other events should I hook to prevent it from behaving like a "real" tab?

I'm also running into a problem where I insert the "fake" tab in the InitializeTabGroup event, which in turn fires the Selecting event even though I haven't clicked on it.

I'd feel safer if there were a way to do it via a creation filter and still maintain the correct visual style.  Like I said, I've got the creation filter working to put the UIElement in the right place, it's getting the visual styling to match that I'm having trouble with.

If I use the dummy Form method, then I don't have a style matchup issue.  The issues I do have are what I outlined above: reordering tabs on tab group scrolling, injecting dummy tabs on InitializeTabGroup, managing the transitory state to deduce when the tab has really been clicked or not, detecting the difference between a "real" tab and the dummy Form-based tab when events are raised in response to user interaction, etc.  I understand that you're recommending using the dummy Form method, but that appears to require a lot more coding, special case handling, etc. since I'd be attempting to use a MdiTab to function differently than how it was meant to operate.

The working code that I do have is based on injecting a custom UIElement using an IUIElementCreationFilter.  Obviously that custom UIElement won't reflect the same look as tabs because it's not a tab, but I've already solved the problem of ensuring proper location & sizing related to scroll buttons, etc.  It works very well for what I need, in that it doesn't interfere with any of my application's existing logic for tab creation, removal, activation, serialization, etc.  The only trouble I'm having is that I'd like this UIElement to look more like a tab.  What I'm looking for is guidance on how to make this UIElement's visual styling match the tabs, or at least reflect a reasonable approximation.

I was trying to avoid probing the style management API (or even reading it directly from the XML in the ISL file) for tab-related UI roles and draw the UIElement myself, but that's my next course of action if something less tedious is not available.

I'm not sure why the styles wouldn't be working because I haven't tried to do anything like this before, but if you post a simple sample on the thread, I could take a look and see why the appearance doesn't match up.

I'm still in the business of using a creation filter because of some custom UI that's being displayed on each of my MdiTabs.  I need a close button on each tab, so I would have to go back and remove it via a creation filter for the dummy tab.  So, either way I go (custom UI Element or dummy Form), I still need to use a creation filter.

I already have working code that creates space for the "new tab" button via TabGroupSettings.SpaceAfterTabs which works well when the scroll buttons are present, and also solves the problem of keeping it visible and at the far right regardless of whether some of the tabs in the group are scrolled out of view.  Using the dummy Form approach would require modifying the tab order every time a tab group is scrolled, and possibly adjusting the tabs' sizes to be certain that there is enough space to accommodate the "new tab" button.  The point is, the custom UIElement is working almost perfectly for me currently, and I've already accounted for a lot of the complications that you're referencing.  I'm up for dealing with the complexities of the tab layout code, and trudging through the creation filter logic, I just need some guidance on how to match up the visual styling.

The tab metrics calculations are incredibly complex. I would really recommend not trying to do this. What happens when scroll buttons are introduced? Are partial tabs visible behind the scroll buttons or not? What about when multiple tab rows are used or the Font style changes? There are many factors which can cause a lot of complications here. I would recommend trying to make it work with a dummy Form or with a Button outside of the tab area. As far as the issue you're running into, you can get around that by setting a flag to True when you load your dummy Form and then setting it back to False afterward. In the TabSelecting logic, don't run the "add new" code while the flag is True.