mrjt Messages: 705 Registered: March 2007 Location: London
Contributor
While trying to fix a problem I had with these controls I have made some modifications (and hopefully improvements) to the functionality and design (no offense intended unodgs, most of the code was lovely ).
The problems I've tried to fix are:
Only being able to use the popup functionality with an EditDate control (my app requires a custom date format)
SetDate not actually setting the date.
No support for SetData/GetData
Interface changes:
SetDate - now sets the selected date and moves the calendar view to display the selection
GetDate - return the currently selected date
Added: SetView - moves the calendar view without changing the selection
Added: SetData/GetData same as Set/GetDate
Added: GetView - returns the view (day will always be 1)
Added: HasCursor - return true if the mouse is over a date
Added: GetCursor - returns the mouseover date (day will be 0 if HasCursor == false)
(Has/GetCursor are to support possible future improvements, perhaps a WhenBar callback)
Other changes:
Added chameleon support (this needs some more work)
Simplified internal structure (inc. removing some redundant members)
Can now be used as pop-up by any control (TimeDateCtrl modified to support this)
I believe I've kept the interface working as it did before (with the exception of SetDate, which didn't work properly IMO) so this should not break any existing apps. When I've got some more time I'll put together an example and add some more stuff.
Thanks to unodgs for the ctrl, I'm very glad he wrote all complicated code .
unodgs Messages: 1366 Registered: November 2005 Location: Poland
Ultimate Contributor
That's great. Thank you! I'll move your changes to uvs today.
In my sources I also have some modifications to DateTimeCtrl like ability to edit time, but I'll merge them later. Thanks again for corrections.
unodgs Messages: 1366 Registered: November 2005 Location: Poland
Ultimate Contributor
I merged your patch. However you must fix one thing that was broken by this patch. Click on drop button - callendar will apear, click again on it - instad of closing calendar the calendar is hidden for a very short time and then is popuped again. This was controled by IgnoreMouseClick().
mrjt Messages: 705 Registered: March 2007 Location: London
Contributor
Ah yes, interesting. The window was being closed on the mouse-down event (change of focus) and reopened on the mouse up. Adding the IgnoreMouseClick() to Calendar::Deactivate fixes this (and correctly matches other normal DropList behaviour):
WhenPopDown();
IgnoreMouseClick();
Close();
Also: You might want to change the WhenPopDown callback, I'm not sure what I was thinking when I named that. WhenCancel/WhenSelect would be clearer and match PopUpTable better. I'll happily do this myself when I've got a more up-to-date source.