Skip to content

Instantly share code, notes, and snippets.

@theredpea
Last active February 5, 2018 22:50
Show Gist options
  • Select an option

  • Save theredpea/d9e9fbdcef61fa51985b54f506ae83c7 to your computer and use it in GitHub Desktop.

Select an option

Save theredpea/d9e9fbdcef61fa51985b54f506ae83c7 to your computer and use it in GitHub Desktop.

Techniques:

  1. iterate through all fields ; createList for each (which CreateSessionObject separate individual lists) (via createList API)
    1. To get list of fields in the first place, loops through the Current Selections bar DOM. Don't know why it doesnt at least use one of the below techniques, which reliably return which fields have selections.
    2. For each App API createList method call with { qDef: ... } I believe it must translate into similar as the CreateSessionObject below with { qListObjectDef: ...}... there is no direct Engine CreateList method
  2. getList "SelectionObject" which calls "CreateSessionObject" of type "SelectionObject" (via field API)
    1. The only way to get comprehensive results, i.e. the SelectionObject is just as limited as the CurrentSelections object is (see qSelectionThreshold). i.e. the .qSelectionObject.qSelections[1].qSelectedFieldSelectionInfo will still only be max 6 elements long.
    2. However still may not have all fields' selections in it; must call app.field(...).getData(...). Looks like that will eventually CreateSessionObject with { qListObjectDef: ... } and GetLayout. (Interestingly its qInfo.type is 'mashup', maybe because the field API is part of the "Capability" API aka the "Mashup API". Still Qlik understands the object to be a list because of qListObjectDef.
  3. Selections API ; undercover calls "CreateSessionObject" of type "CurrentSelections"
    1. But this API is limited to what CurrentSelections shows; i.e. limited to the qSelectionThreshold which is set at 6.
    2. While this method limits the results you can access, it still has a big advantage; it is the only one of these methods which is callback-based; so that you can listen and be notified if the selection even changes at all; i.e. gives you opportunity to do the work closer to when the user applies the selection. So just doing work when teh callback is called.
    3. However,when the callback is called, it is not passed any arguments, i.e. so it's not "incremental" where you can track which fields you should check for an update in selections.
    4. But regardless of getting full detail selections is convenient that this selectionState API will keep an array for you, you'll never need to iterate through fields again.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment