Button autochildren of Window not calling "blur" if autochild name ends with "Button"

[ESutherland]

what UI interaction you are trying to achieve, from the end user's perspective.
There are a bunch of formItems that rely on the blur event to do formatting/validation. When I put forms in windows with a submit button, clicking the submit button should cause blur on whichever field had focus and perform any corresponding formatting/validation.

what you expected to happen
[FONT=Arial, Verdana, sans-serif]After adding an invalid date into a DateItem, I clicked my submit button which calls DynamicForm.validate() and saves if validate() returns true. Even with the dateitem having a value 12/12/asdf, form.validate() returned true. This prompted me to do some further investigation and found that blur doesn't happen when the button is an autochild and ends with the word "Button". Doesn't seem to matter if the button is a member of a VLayout within the window, or directly on the Window items. In my example you can see that the blur event only happens when you click the button which does not end in "Button".[/FONT]

browser(s) and platform(s) where you see the problem
Google Chrome Version 56.0.2924.87

contents of the SmartClient Developer Console "Log messages" area, with appropriate log categories set to DEBUG or INFO level
N/A

stack traces from either IE (in the Developer Console) or Firebug (in the Firebug console) for any JavaScript errors that have occurred.
N/A

sample code and sample data (tip:enclosing code snippets in [ code] ...[/ code] tags will format them as code, making your report much more readable)

 isc.Window.create({
            height: 500,
            width: 500,
            initWidget: function () {
                this.Super("initWidget", arguments);
                this.addItem(this.addAutoChild("someForm"));
                this.addItem(this.addAutoChild("asdfasdfButton"));
                this.addItem(this.addAutoChild("asdfasdfBtn"));
            },
            someFormDefaults: {
                _constructor: isc.DynamicForm,
                fields: [
                    {
                        name: "Field 1",
                        editorEnter: function(form, item, value){
                            item.setValue("");
                        },
                        blur: function (form, item) {
                            item.setValue("Focus Left");
                        }
                    }
                ]
            },
            asdfasdfButtonDefaults: {
                _constructor: isc.Button,
                width: 200,
                title: "will NOT cause blur"
            },
            asdfasdfBtnDefaults: {
                _constructor: isc.Button,
                width: 200,
                title: "will cause blur"
            }
        });

SmartClient version (available on lower left of Developer Console)
SmartClient Version: v11.0p_2017-02-16/Pro Development Only (built 2017-02-16)

[Isomorphic]

Regarding your actual use case, have you seen FormItem.formatOnBlur? You might be reinventing this feature through blue events, which have intractable browser idiosyncrasies (we make them as consistent as we can).

Also, usage issue: you can define df.fields in AutoChild defaults, because those fields would be shared across all instances. You can instead pass the field definitions into addAutoChild.

The autoChild name shouldn't be affecting behavior, we'll check on that.

[efisch]

SmartClient Version: v11.0p_2017-03-10/Pro Development Only (built 2017-03-10)

Isomorphic Administrator - I don't how far you went with actually investigating this... because regardless of the use case that ESutherland was talking about, this is absolutely a bug with the isomorphic code base. If you look in the file ISC_Containers.js - you will see that when the function called "getDynamicDefaults" is called for child on a Window class, it checks to see if that child ends with the word "button", and if it does so, it sends back the property object with "canFocus" property set to the same value as "this.canSetFocusInHeaderButtons".

Having that logic written as it is, no one is allowed to create any children on a Window that ends in the name "button" without it affecting the ability for that child object to gain focus. Just a guess, but this is probably not something that is desired functionality for anyone using this class... especially because good naming convention would be to end a button object with the word "button", and this logic does not allow for that.

I personally ran into this issue because I have a window with a form, two date fields, and a button that are all autoChildren of the Window, but also have autoParents of a layout within that Window as well. When a user clears one of the date fields, and then directly after that goes to click the submit button, the focus never leaves the date field that I change... so when I call getValues on the form - the "cleared out" field still has the value that was there prior to me clearing it out. However, if I clear that field, click on another field, thus losing the focus in the initial field, the value in the initial box will be correctly represented when I call getValues on the form item.

Not only did I find the bug in the source code, but I actually tried it in the implementation to verify that it works as I am saying it does. When I created that same window, but with the property canSetFocusInHeaderButtons to true, voila, the button gained focus properly and I got the correct value when I called getValues.

I could write this all out in code if you cannot figure out what I am talking about, but I believe that I have outlined it in such a way that should be easy to find.

As for the actual fix of this issue, all that would be required is another check within that getDynamicDefaults function which would ensure that the child object ending in the word "button", also belongs to the list of header controls in order for the canFocus to be set to the canFocusInHeaderButtons property value. I don't know exactly how you implement these changes, but I cannot imagine it would take very long to figure that out either.

I understand that we don't have a paid support plan, but for the sake of everyone using your software, when someone helps you out and points out a bug for you... rather than jumping down their throat and telling them their implementation is incorrect, perhaps you could take the same five minutes that it took me to find this bug and actually make the software better for everyone.

[Isomorphic]

Thanks for figuring out the underlying problem, that will help us resolve this more quickly.

Your other commentary is waaay off base however.

This issue was assigned to be looked at when you posted it, as we told you. It was (correctly) assigned low severity since it would only affect people who make their own custom AutoChildren (rare) and happen to rely on focus/blur in a Window (rarer still) to roughly replicate the built-in formatOnBlur feature (at this point, it's reasonable to assume just your team is affected, *and* you've been given a better approach). Also note that we have no way of knowing, at the outset, that it's going to be a 5 minute investigation, so we can't, for example, bump it up in the queue because we know it's a small task (as we sometimes do).

Further, here's what you characterize as "jumping down their throat": "Also, usage issue: you can define df.fields in AutoChild defaults, because those fields would be shared across all instances. You can instead pass the field definitions into addAutoChild."

Hmm. We would characterize that instead as "politely letting you know about a usage issue that might bite you in the future". Especially since the very next thing we said was that we'd look into the issue you reported?

We can't be wasting any more time responding to rants from your team, as this forces a support lead to come out and explain how industry-standard triage and prioritization procedures will affect you, which means everyone else's issues are delayed by a bit. So please don't do this again.

[Isomorphic]

We've now made a change to the framework to address this issue. Please try the next nightly build, 11.0p or 11.1d branch, dated March 14 or above.

Regards
Isomorphic Software Support

[efisch]

Thank you for fixing this issue.

In regards to our previous comments, I apologize for the tone that was used. It will not happen again.

I do have a question. You mentioned that people creating their own custom AutoChildren as being "rare" - why is that? We absolutely love the AutoChildren system that you guys have created and we use it all the time. Really for anything that we create, we almost exclusively do so by creating objects with various AutoChildren on them. Is this not good practice? Or were you simply implying that it is more common for people to take the higher-level approach and construct objects in more of a traditional JavaScript way? I personally think that using AutoChildren is the best way to create dynamic and streamlined code, so I am hoping that it is a good thing that we have been using them so heavily. Thanks again.

[Isomorphic]

Thank you for the apology. We know that's not easy to do.

We highly recommend you continue to use AutoChildren. As far as why others don't, we're not entirely sure, it's just something we've noticed in terms of the questions asked here and the codebases we've seen at customers.

It may be that this style of encapsulation, in which subcomponents are created but not made configurable, is sufficient for most people:

http://www.smartclient.com/smartclie...ComponentReuse

AutoChildren gives you the further ability skin your custom components in multiple ways, makes them more easily extended, and cuts down on some boilerplate code. Most of the benefits are not obvious until you've created a library of your own reusable components for multiple projects.