Closed mirh closed 8 months ago
I have updated the code to not get stuck. It will not work with 5.1.5 due to AGIO connecting to the same udp port. Maybe your hack fixes this. The fix is on the LargeScreen branch.
Sorry, I meant a hack to have new AOG behave like 5.1.5, so that I'm not obliged to keep using the 2021 version forever and ever (you'd think open-source projects would never give you reasons for self-inflicted downgrades, but I swear they seem to have some user coordination handicap on the main repo)
************** Exception Text **************
System.ArgumentNullException: Value cannot be null.
Parameter name: value
at System.Windows.Forms.ComboBox.ObjectCollection.SetItemInternal(Int32 index, Object value)
at System.Windows.Forms.ComboBox.ObjectCollection.set_Item(Int32 index, Object value)
at RateController.FormSettings..ctor(FormStart CallingForm, Int32 Page) in ..\AOG_RC-LargeScreen\RateAppSource\RateController\FormSettings.cs:line 78
at RateController.FormStart.productsToolStripMenuItem_Click(Object sender, EventArgs e) in ..\AOG_RC-LargeScreen\RateAppSource\RateController\FormStart.cs:line 825
at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
at System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e)
at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met)
at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met)
at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
at System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
at System.Windows.Forms.ToolStrip.WndProc(Message& m)
at System.Windows.Forms.ToolStripDropDown.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Anyway, the UI doesn't get stuck anymore indeed. But it has broken buttons though, and clicking on Products throws this.
Try this on line 100 of FormStart.cs:
UDPaog = new UDPComm(this, 16666, 17777, 16660, "127.0.0.255"); // AGIO
//UDPaog = new UDPComm(this, 17777, 15555, 1460, "127.255.255.255", true, true); // AOG
That makes it work 100% perfect. So I guess it's cool that I can both get new RC to work with old AOG, or my dear old AOG function into new AOG so RC runs OOTB.
But is there no way to detect this ahead of time? Or at least not fail spectacularly, and just conditionally fallback to either a warning screen or the old UDPagio behaviour? It's kinda eerie the amount of crazy whimsical scenarios that I encountered, that I don't think a normal joe could have figured (let alone fixed) in nine lives.
New sowing season, new opportunities to test this I guess...
Since 627ef2946d3ddc670f49d6c92c4b616892c23878 the RC app will throw an error and get stuck completely uninteractable when using older AOG versions.
I'm not saying you should go out of your way to support them (thankfully I could find a way to hackjob the new ones to behave like 5.1.5), but nevertheless the user should never have to figure out the meaning of exceptions at least.