Hi Mark, Look ok. Is there a reason you chose to have setButtonEnabled call setButtonsEnabled instead of having setButtonsEnabled call setButtonEnabled in its loop? That way folks using setButtonEnabled don't pay the price of the loop setup and wrapping the single label in an array.
You don't have to change the way you have it since it would be rare for this API to actually be used so much it would be a performance issue. I'm just pointing out things I think about when I see code. In the SDK, I think we use both patterns. The commitSelectedItem calls commitSelectedItems because there is supposed to be a single valueCommit event at then end of a set of selection changes and there is no way for commitSelectedItem to know if it should dispatch valueCommit or not, but if there is no aggregate event I think having the single do the work is slightly more efficient. Anyway, thanks for doing this work. -Alex On 5/4/13 7:02 AM, "Mark Kessler" <kesslerconsult...@gmail.com> wrote: > Ok I put it together this morning. Can see the modified example on my site > [1] with view source enabled. The git history at [2]. and So you don't > actually have to goto either, I will paste the current methods below. 4 > Methods brought down to two methods. The new common method I will end up > using later. Yes I wish to keep the string based method... this would be a > perfect case for method overloading if it were supported in AS. > > [1] http://people.apache.org/~mkessler/examples/FLEX-33524/app.swf > [2] > https://github.com/KesslerConsulting/example/commits/master/frameworks/project > s/spark/src/spark/components/supportClasses/ButtonBarBase.as > > > /** > */ > public function getButtonIndices(labelValues:Array, fieldName:String = > ""):Array > { > var buttonIndices:Array; > > > if (!dataGroup || labelValues.length < 1 || labelValues == null) > { > return []; > } > > if (fieldName == "" || fieldName == null) > { > return findRowIndices(labelField, labelValues); > } > else > { > return findRowIndices(fieldName, labelValues); > } > } > > > /** > */ > public function setButtonEnabled(labelValue:String, > enabledValue:Boolean, fieldName:String = ""):void > { > setButtonsEnabled([labelValue], enabledValue, fieldName); > } > > > /** > */ > public function setButtonsEnabled(labelValues:Array, > enabledValue:Boolean, fieldName:String = ""):void > { > var btnCurrent:ButtonBarButton = null; > var buttonIndices:Array; > var indicesTotal:uint = 0; > var loopingIndex:uint = 0; > > > buttonIndices = getButtonIndices(labelValues, fieldName); > indicesTotal = buttonIndices.length; > > if (indicesTotal == 0) > { > return; > } > > > for (loopingIndex; loopingIndex < indicesTotal; loopingIndex++) > { > btnCurrent = > dataGroup.getElementAt(buttonIndices[loopingIndex]) as ButtonBarButton; > btnCurrent.enabled = enabledValue; > } > } > > > -Mark > > > On Sat, May 4, 2013 at 12:41 AM, Alex Harui <aha...@adobe.com> wrote: > >> Hi Mark, >> >> My personal preference is for #2, but only slightly. IMO, fewer APIs are >> better as long as they are discoverable, but you can go with #1 if you >> want. >> My only thought was that it appears that at least internally most of the >> code could be in a setButtonEnabled() method and even the array version >> would just call that method. >> >> -Alex >> >> -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
