What am I doing wrong with the BarManager?

I have two forms, one is an MDI parent, and the other is the client. The parent has a MainFrameBarManager created at design time, and the child has a ChildFrameBarManager, created at runtime and stored as a generic BarManager. Everything works fine until I go to close the form, then an exception is thrown from the bowels of the barmanager code: Key cannot be null. Parameter name: key at System.Collections.Hashtable.get_Item(Object key) at Syncfusion.Windows.Forms.Tools.XPMenus.BarManager.GetManagerFromForm(Form form) at Syncfusion.Windows.Forms.Tools.XPMenus.BarManager.GetManagerFrom(Form form) at Syncfusion.Windows.Forms.Tools.XPMenus.MainFrameBarManager.UpdateBars() at Syncfusion.Windows.Forms.Tools.XPMenus.MainFrameBarManager.OnFormDeactivated(Form form, Boolean updateBars) at Syncfusion.Windows.Forms.Tools.XPMenus.MainFrameBarManager.set_LatestActiveMdiChild(Form value) at Syncfusion.Windows.Forms.Tools.XPMenus.MainFrameBarManager.OnFormClosed(Form form) at Syncfusion.Windows.Forms.Tools.XPMenus.BarManager.FormClosed(Object sender, EventArgs e) at System.Windows.Forms.Form.OnClosed(EventArgs e) at System.Windows.Forms.Form.WmClose(Message& m) at System.Windows.Forms.Form.WndProc(Message& m) at System.Windows.Forms.ControlNativeWindow.OnMessage(Message& m) at System.Windows.Forms.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) at System.Windows.Forms.UnsafeNativeMethods.SendMessage(IntPtr hWnd, Int32 msg, Int32 wParam, Int32 lParam) at System.Windows.Forms.Control.SendMessage(Int32 msg, Int32 wparam, Int32 lparam) at System.Windows.Forms.Form.Close() at Syncfusion.Windows.Forms.Tools.XPMenus.MdiSysMenuProvider.DestroyMDIActiveChild() at Syncfusion.Windows.Forms.Tools.XPMenus.MdiSysMenuProvider.HandleMouseUp(Point ptclient) at Syncfusion.Windows.Forms.Tools.XPMenus.BarControlInternal.OnMouseUp(MouseEventArgs e) at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) at System.Windows.Forms.Control.WndProc(Message& m) at Syncfusion.Windows.Forms.Tools.XPMenus.BarControlInternal.WndProc(Message& m) at System.Windows.Forms.ControlNativeWindow.OnMessage(Message& m) at System.Windows.Forms.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) at System.Windows.Forms.UnsafeNativeMethods.CallWindowProc(IntPtr wndProc, IntPtr hWnd, Int32 msg, IntPtr wParam, IntPtr lParam) at System.Windows.Forms.NativeWindow.DefWndProc(Message& m) at System.Windows.Forms.NativeWindow.WndProc(Message& m) at Syncfusion.Windows.Forms.Tools.XPMenus.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg) at System.Windows.Forms.ComponentManager.System.Windows.Forms.UnsafeNativeMethods+IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData) at System.Windows.Forms.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context) at System.Windows.Forms.Application.RunDialog(Form form) at System.Windows.Forms.Form.ShowDialog(IWin32Window owner) at System.Windows.Forms.Form.ShowDialog() at TecoloteResearch.POST.SelfHost.Activate() in C:\ITG\Projects\ACEIT\POST\Source\POST\Classes\SelfHost.vb:line 76 I am using the new 1.5.1.1; I patched a full 1.5.0.0 install this morning. One interesting thing that I noted is that previously the constructor was being called twice (I saw the explanation in a previous post, although I think it is very lame that it does this). However, now the constructor is only being called once. I did not notice if this was because of the change to 1.5.1.1, or if it is maybe because of something that I did. I am pretty sure that I am calling all of the same things as before; I basically took all of the code from InitializeComponent and moved it into the constructor, right after the call to InitializeComponent. The same calls are being made, and in the same order, so it seems like everything should work. - Steve

Steve, It does seem like something is not being setup properly. Do you call the BeginInit and EndInit calls in the ChildFrameBarManager? Could you please attach a sample? Thanks Praveen Ramesh

Thanks, but I figured out the problem; I was setting the MdiParent property of the form before the command bars were configured (which happened later depending on whether or not there was an MdiParent). Apparently the barmanager code does not recognize this as a problem at the time, and in fact everything else worked perfectly fine up to the point when the form closed. At that time, because something hadn't been initalized at the beginning, some object was null that shouldn't have been, hence the exception trying to use it as a key into a hashtable. Anyway, in connection with this problem, "dummy" instance of the form was never created (I suspect that is the null object it was trying to access). This prompted my second question, as to why you guys need the dummy instance of the form, as everything was working fine without it. So I reorganized the code and everything works now. However, I am still rather frustrated regarding this requirement for a dummy instance, since it means that I have to be really careful not to do anything in it, and it also forces me to have a noarg constructor (but at least it can be private).

Steve, Please see my comments in your other forums regarding the dummy instance. Regards, Praveen