Timeline for Interdependent SetterBars with symbolic contents
Current License: CC BY-SA 3.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 13, 2017 at 4:11 | vote | accept | Reb.Cabin | ||
| Sep 12, 2017 at 16:35 | answer | added | kglr | timeline score: 1 | |
| Sep 12, 2017 at 16:04 | answer | added | andre314 | timeline score: 2 | |
| Sep 12, 2017 at 15:24 | comment | added | Lukas Lang | @Reb.Cabin You might want to have a look at this question regarding the use of associations | |
| Sep 12, 2017 at 15:22 | answer | added | Lukas Lang | timeline score: 2 | |
| Sep 12, 2017 at 15:18 | comment | added | Reb.Cabin |
@J.M. I tried associations. With the original control spec, namely {{source, src[dest][[1]]}, src[dest], SetterBar}, associations produce the same undesirable results as my first proposal. I have long hypothesized that associations are just an alternative syntax for the traditional, single-bracket, pseudo-functional, pattern-matching notation like src[dest], which produces an internal lookup table (almost certainly a hash table). Semantically, I don't know of a difference between an association and the equivalent set of single-bracket definitions like my original definition of src.
|
|
| Sep 12, 2017 at 15:10 | comment | added | Reb.Cabin |
@klgr that works nicely, with "SetterBar" remaining as the control type (the control type defaults to a slider, which is weird because the domain is discrete, but was explained in the referenced older question as a side effect of an implicit Dynamic).
|
|
| Sep 12, 2017 at 13:40 | comment | added | J. M.'s missing motivation♦ |
This is less about the GUI and more about the code, but: have you considered making src an Association[]?
|
|
| Sep 12, 2017 at 13:36 | comment | added | kglr |
Maybe, MapIndexed[#2[[1]] -> # &, src[dest]] in place of {1 -> src[dest][[1]], 2 -> src[dest][[2]]} to cover cases where src[_] can be of any length?
|
|
| Sep 12, 2017 at 13:29 | history | asked | Reb.Cabin | CC BY-SA 3.0 |