Hello again, Guy!
As for the documentation, if you follow it, you're at least ensuring you'd get some sort of notice (through changelogs) if something there is changed the next version.
The main client-side (Ext JS, from Sencha) documentation is at: https://docs.sencha.com/extjs/6.6.0/classic/Ext.html
Notice Ext.NET uses the "classic toolkit" as you'll see references about in Sencha website.
As for the C# API docs, you are safer to rely on IntelliSense in Visual Studio, but we also keep a documentation page available at https://docs.ext.net/
component is at: https://docs.sencha.com/extjs/6.6.0/...ltiSelect.html
The MultiSelect's ListConfig
events are handled by an Ext.view.BoundList
Keep reading below if you want to learn some quirks on the documentation-driven solution for this thread. It turns out we pointed you to a solution that could be replaced by something safer between version updates. Hopefully this could help you -- and others -- to solve also other issues before needing to seek help. Which is probably what you want when you asked about documentation.
If you check the itemdblclick event document entry
, you'll see it has the parameter names as
this, record, item, index, e, eOpts
. But watch out as, probably to avoid breaking changes Sencha introduced in the past (by renaming the parameters of the events), in Ext.NET we map the parameters into
item, record, node, index
! Unfortunately in the past Ext JS introduced many unnecessary breaking changes, and we tried our best not to forward them between minor versions to our users; and they ended up surviving even through major versions.
You can check the argument names either by the live page with developer tools or via a tool we have in Examples Explorers that, given the component and event name, it gives the argument names: https://examples4.ext.net/#/Events/Listeners/Arguments/
, then ItemDblClick
for the item in question).
So, here when we use item
, in Ext.NET, we're referring to this
in the documentation. And then item
is but the own BoundList
Further following the BoundList
documentation, there's no pickerField
within, not even as 'private', in the documentation! We relied on it to get the valueField
in the solution we suggested. So that's something that could break without any notice, at any point between releases.
Knowing that pickerField
returns just the very MultiSelect
component, we can then just find a reliable alternative into getting the component, that's on the documentation. So here's two alternatives:
1. Reference the component via App.MSReadyToPrint.valueField
(very safe, but is something that will break if you change the component's ID, or if you reuse code throughout your application).
2. Call the documented up() method
to get the enclosing component. If you do heavy code reuse throughout the application this might be the best choice, and you'd also want to handle exceptions, like the enclosing component not being something that has a valueField
With the second approach, the suggested codes should be changed to, respectively:
In a last approach, in the case you are craving for performance (which I believe it would not be the case for the little benefit it gives), you can just rely on using the constant
Hope this helps to guide you on following the documentation to understand this and for figuring out other issues!