0

So i cannot get this to work in a fiddle (because the owner seems to disallow external reffing of his library), so I fear I have to stick to prosa and some snippets. Basically I want to use the anytime plugin for time selection, looks like this:

enter image description here

library source code is here

Good thing is, is accurate by the minute, which is a requirement. It does destroy the tabbing behaviour though. If you tab, you tab into the time selector. Which is unwanted in 99% of all cases I can come up with. I broke it down that I have to overwrite this function:

   var AnyTime = {};

    AnyTime.picker = function(id, option){
  __pickers[id] =
        {
         key: function (event) {
           //apply patch, e.g. if(key === 9){return;}
        }
    }

Is there a way I can do this from the outside, without having to destroy his file? e.g. when I update the file, I don't wanna have to think of updating this function

Is my question clear? I want to keep his file as is, and then from one of my files call something like this (won't work obviously):

var tempKeyFunc =  AnyTime.picker.__pickers[id].key;
AnyTime.picker.__pickers[id].key = function(){
   if(key === 9)
{
   return;
}else{
tempKeyFunc();
}
Toskan
  • 13,911
  • 14
  • 95
  • 185
  • IMO that widget looks horrible for usability. I'd just use select dropdowns or three input fields or an input with masking. – elclanrs May 06 '14 at 01:14
  • @elclanrs - it's very nice for touch (if it's large enough). – jfriend00 May 06 '14 at 01:15
  • it is on top of the ability to actually enter the time manually. There is some people who love pickers and love moving the mouse around. I am not one of them. – Toskan May 06 '14 at 01:17
  • Short answer: there is no way to access local variables from outside the function. – Felix Kling May 06 '14 at 01:27
  • Another possibility might be to bind to the $(‘#anytimeId’) keydown event and cancel it or move the focus to the next element inline. – Adi Katz May 06 '14 at 02:10
  • well canceling events and stuff, how do you know which event gets fired first? @FelixKling so in short, his plugin design sucks – Toskan May 06 '14 at 03:00
  • The one that gets bound first fires first. If the plugin creates the element and the event, binding your event first will be difficult. – Kevin B May 07 '14 at 14:39
  • @KevinB that is a myth ;) events get fired randomly, i had to learn this the hard way. Depends on the browser ofc. – Toskan May 07 '14 at 18:11
  • No, it isn't. you just have to understand how the event binding and event triggering takes place. For example, an event bound directly to an element will always trigger before an event that is delegated to that same element because the event happened on the element, then bubbled up to the delegate target. – Kevin B May 07 '14 at 18:14
  • well, but if you bind two events the same way to an element, then you will never be sure. Delegate is deprecated in jquery, so I actually never used it. – Toskan May 07 '14 at 18:21

1 Answers1

0

Tabbing into the picker is important for accessibility; that is not destroying the tabbing behavior but rather supporting it.

Sorry that you think the plugin design sucks.

IMHO, when it comes to usability, what really sucks is having to scroll through three drop-downs of individual number fields, when you could more quickly click on three buttons in a row.

Andrew M. Andrews III
  • 1,989
  • 18
  • 23
  • the plugin should be an option. We are talking about using the mouse or pressing something like 1305 - which is 4 buttons, right? to get the time. Ok maybe 13:05 if the user doesnt know i allow short cutting it. I think the plugin is great, tab - means always switch to the next element though, check out the datepicker of jquery ui. If I wanna force! people to use the plugin then I will not allow them to use an input box – Toskan May 07 '14 at 18:10
  • I agree that the plugin should be an option and the user should be able to key in a time numerically. The issue is, if the user keys a time, it must be in the right format. The plugin prevents that problem, but it is not optimal. Ideally the plugin would have more "natural" keyboard support. It is currently designed to support the keyboard functionality defined in the ARIA v1 specification for a datepicker, in order to be compliant with accessibility standards. I am working on a new picker that will have more "natural" support for keyboard input, but it is still many months from release. – Andrew M. Andrews III May 21 '14 at 15:16
  • 1
    Meanwhile, there is a workaround to make the picker optional, demonstrated at http://www.ama3.com/anytime/#buttonCreationDemo ... it is not optimal, but as I said, it is a workaround. – Andrew M. Andrews III May 21 '14 at 15:18