You might find that instances of CAdUiPaletteSet's keep turning into CAdUiDockControlBars when called with FloatControlBar method.
Applications normally manage the state of docking windows (CControlBars) using the standard MFC methods CFrameWnd::DockControlBar(), CFrameWnd::FloatControlBar() and CFrameWnd::ShowControlBar() (Docking windows should not be shown/hidden using calls to CWnd::ShowWindow()).
Applications can continue to call CFrameWnd::DockControlBar() and CFrameWnd::ShowControlBar() normally. However, when calling CFrameWnd::FloatControlBar(), applications will need to "swap" the floating frame class if the control bar passed to FloatControlBar() is a kind of CAdUiPaletteSet. Applications can perform this "swap" by calling the new method AdUiSetFloatingFrameClass() before and after the call to FloatControlBar():
CRect mRect(100,100, 300, 600);
CMDIFrameWnd* pAcadFrame = acedGetAcadFrame();
CRuntimeClass* pCurrentFloatingFrameClass = AdUiSetFloatingFrameClass(RUNTIME_CLASS(CAdUiPaletteSetDockFrame));
acedGetAcadFrame()->FloatControlBar(GetPaletteSet(),CPoint(mRect.left, mRect.top),CBRS_ALIGN_TOP );
Why is all of this necessary? MFC's CFrameWnd class caches a pointer to the floating frame class used as a private member of the class. This class pointer is used to instantiate a floating frame for dock control bars when they are floating by CFrameWnd::FloatControlBar(). AdUi needs to continue to support for custom dialogs derived directly from CAdUiControlBar. So AdUi host applications need to use two different floating frame classes, one for those derived from CAdUiControlBar and another for those derived from CAdUiPaletteSet.
Unfortunately FloatControlBar() is not a virtual method so it is not possible to override it in the application frame class to automatically detect the control bar class and use the correct floating frame. Instead applications must detect the control bar class themselves and manually swap the floating frame class before calling CFrameWnd::FloatControlBar().