asp.net: June 2009 Archives

I think I've mentioned the custom File Upload Dialog for Coolite previously which sadly doesn't seem to work with Coolite v0.8 due to a breaking change that's not mentioned in the Version 0.8.0 -BREAKING CHANGES forum post. In summary, the ParameterCollection object no longer has a "ToJsonObject" method, but this has been replaced/renamed with "ToJson". Changing the source for the file upload dialog and re-compiling resolves this.

I also found that, as mentioned in ScriptContainer location not honoured in 0.8 against 0.7, the behaviour of the Coolite ScriptContainer has changed as it now seems to have been split-out into the ScriptContainer and StyleContainer controls. Easily solved, but no less annoying that I had to spend time doing so.

Previously: extJs: Combobox .getValue oddity

Here's a quick-hacky solution (a better one would be to ensure your combobox's are selection-only):

Ext.override(Ext.form.ComboBox, {
    getValue: function()
    {
        return this.value;
    }
    });

It might only have been auto-gen'd from the sourcecode, but it's still better than nothing: Coolite Toolkit Documentation. The quality of (or lack of) documentation seems to be a fairly frequent complaint on the Coolite forums, and as there's not quite always a one-to-one mapping between Coolite and extJs, looking at the (comprehensive) extJs documentation isn't always useful.

In addition, to anyone working with Coolite, I would strongly recommend downloading the sourcecode and reviewing it when you come across strange/unexpected/confusing behaviours. It's not that difficult to step-through and get a fairly good idea of what's going on!

At least in extJs version 2.2.1 (the version baked into Coolite v0.8), the getValue function on the Ext.form.ComboBox appears to be thus:

function()
{
  if (this.valueField&&this.forceSelection)
  {
    return typeof this.value!="undefined"?this.value:"";
  }
  else
  {
    return Ext.form.ComboBox.superclass.getValue.call(this);
  }
}

Of interest is the fact that differing code-paths are taken based on the "forceSelection" property. If it's set (i.e. thou shalt choose something from this combo and not enter free-text), then the .value property is used as the return value of the call to getValue, otherwise a call is made to superclass.getValue, which returns something quite entirely different!

Instead of, as expected, returning the "key" value, it returns the displayed value. This is thanks to superclass.getValue being defined as:

function()
{
  if (!this.rendered)
  {
    return this.value;
  }
  var v=this.el.getValue();
  if (v===this.emptyText || v===undefined)
  {
    v='';
  }
  return v;
}

Whilst I've logged this as an "oddity", it is (seemingly) "by-design" as the combo-box allows for user-entered values, which is what the "forceSelection" code-branch causes. That said, I firmly believe that if the "selected value" is one that has been chosen from the contained items, then getValue should return in the same way as it does with forceSelection being false.