Eto.Gtk DateTimePicker drop-down dialog fails to close and loses parent connection.

[derbyw]

I'm seeing an issue with the DateTimePicker implementation in Eto.Gtk where after the "drop down" arrow is clicked the child dialog window (with the calendar/clock controls on it) appears but can become stuck and will not disappear - it appears to becomes un-parented as you can move the parent form away and the picker will stay in place until you specifically click on the form. On my program, I can even close the parent window and the dialog will remain. On the Demo program this can be seen by clicking the drop down a few times in a row - on my system it works the first time, but eventually the dialog form no longer responds and just stays on the screen.

After more investigation, this appears to be a UI/Threading issue -- the "Close" command in CloseDialog for the DateComboBox gets called but doesn't work - if I manually close the form by managing the dlg reference to the form in DateComboBox.cs then the Close works as expected, but in that case, it is running on the UI thread -- is there a way to run something on the UI thread down in in BaseComboBox.gtk3.cs level of things? From what I can tell the Gtk Close() likely needs to run on the UI thread to work correctly and at the moment is running in an event handler thread.

[derbyw]

Further investigation shows it's not threading (directly) - I added tried changing the code to capture a SynchronizationContext on the popup call and use that to call context Close -- to no effect.

It MAY be an issue with the Gestures as I am using the modified version to add that. I will switch to "develop" branch to see --

I do have a mod make it work - mostly - where the form always comes down but you sometimes have to click on the pull-down button twice to get it to appear -- also seems more likely to happen with fast click rate on the dropdown button.

[derbyw]

Not related to gestures -- same issue happens on the "develop" branch.

[derbyw]

I now have a usable version of this now but a few things need to be different - for one, the prior version of the dialog did a grab to allow a "click anywhere" to close the dialog - which unfortunately made is so the first click on the calendar would close the dialog (so if you wanted to change year and date you needed to bring it up twice.
After removing the grab you can now close the dialog by clicking on a non-control, re-clicking to drop down button or moving focus off the control.
The one thing I'm still tying to get to work is for the dialog to either (a) track the entry field position if the parent form is moved or (b) close the dialog if the parent form is moved. Note sure I will get very far with either and current is at least equal to the existing in that regard. I'll create a PR for this so you can try the changes shortly.

[cwensley]

@derbyw thanks for reporting the issue and the diagnosis. One thing that might work is to track when the window loses focus and close it then.

[derbyw]

@cwensley Actually I think in that case the Entry widget will loose focus and what I have will shut it down properly - the problem is that once up, you can move the parent form anywhere and the pull down dialog just sits there. Seems to me if you are moving the form it's reasonable to take the dialog down -- just have to figure out how to detect it way down at the Entry widget. From my reading trying to get one window to track a widget in another window in Gtk is not going to work. I'll try to make a branch and get a PR sent on Monday.

[derbyw]

Just got even more interesting - went to try my updated code in my main app and the control is really messed up when placed on a Dialog - if it's on a form all is well but the dialog case will fail (i.e. orphaned, non parented form). I can (did) convert my code to use a Form not a Dialog but not sure how to deal with this in there different cases.

[derbyw]

@cwensley - added a PR for the issue and my proposed mod. -- see the commentary in the PR for general info on the implementation and limitations -- it's better but certainly not optimal