Clicking quickly between CheckBoxItem's does not fire handleClick

[jason.saunders]

For a form made up of multiple checkbox's, clicking quickly between checkboxes doesn't hit the handleClick function.

Test case;

    isc.CheckboxItem.addProperties({
        handleClick: function () {
            console.log("handleClick:" + this.title);
            return this.Super("handleClick", arguments);
        }
    });

    isc.DynamicForm.create({
        fields: [
            { title: "Checkbox1", type: "boolean" },
            { title: "Checkbox2", type: "boolean" }, 
            { title: "Checkbox3", type: "boolean" },
            { title: "Checkbox4", type: "boolean" },
            { title: "Checkbox5", type: "boolean" },
            { title: "Checkbox6", type: "boolean" }
        ]
    })

Clicking quickly between the 6 checkboxes will show gaps in the console log.

My problem is that I am handling the handleClick event to send a notification to the server.

I also notice that (at least on Chrome when the focus outline is shown) when it it goes wrong the focus outline remains on the previous checkbox, perhaps this is indicative of the problem.

Problem occurs using following browsers:
Google Chrome 19.0.1084.56 m
Firefox 12.0
Internet Explorer 9

SmartClient Version: v8.2_2012-04-08/LGPL Development Only (built 2012-04-08)

[Isomorphic]

Most likely, doubleClick events are firing instead of single clicks. See also canvas.noDoubleClicks if you prefer to get these as two single click events.

Also note, you're overriding an internal, undocumented and unsupported method.

[jason.saunders]

Thanks, noDoubleClicks has addressed the problem. I guess that should really be the default on DynamicForm.

Re: handleClick override - in fact I'm not overriding that, I was really just illustrating were it appeared to go wrong in smartclient internals. In reality I'm actually setting the checkbox validator to serverOnly and setting validateOnChange to true.

[Isomorphic]

No, we wouldn't want to change the default or that would disable the doubleClick event, of course.

[jason.saunders]

Well yes, but are lots of devs making things happen when double clicking on plain forms/formitems?

The current situation seems to be that you can't validate checkboxes reliably unless you set noDoubleClicks on the form.

Not trying to be a pain but to be honest the noDoubleClicks solution feels like more of a kludge than a proper fix. What happens if I want to handle double clicking on something on a form that has checkboxes on it?

[Isomorphic]

We don't know what you mean by "validate checkboxes". Normal use cases would just use change/changed events. If you didn't realize these were available, just delete your code and use these simpler events. If you're doing something special, you just need to add handlers for click & doubleClick as opposed to just click.

We certainly would not want to just disable doubleClick events on the form and have developers wonder why those events weren't firing.

[jason.saunders]

I see where I've gone wrong now.

Originally (in error and by accident) validation on checkboxes was being handled using validateOnExit, this exposed the problem with double click where the clicking between two checkboxes left the focus on the first checkbox and therefore no exit event occurred.

Then, as per your suggestion, I set noDoubleClicks on the form which made validateOnExit work but then I realised its supposed to be validateOnChange. So switched to that but didn't think to remove noDoubleClicks.

After removing noDoubleClicks validateOnChange continues to work and the only minor issue is that the focus remains on the first checkbox which I'm not worrying about for the time being.

> We don't know what you mean by "validate checkboxes"
This is within the context of some generic form handling in our application which is an ASP.NET backend. All form items send validation events to the server on exit/changed as appropriate. The server can then apply cross field dependency checks and perform other dynamic form changes (e.g. when checkbox A is checked then enable form item B etc...). All of that is handled via the single smartclient "validate" request as opposed to having separate handlers/messages for blur/changed etc...