> On Jan 4, 2018, at 12:27 AM, Motti Shneor <motti.shn...@me.com> wrote: > >>> If I last elect to add such out-of-table popup - can you think of a decent >>> way to disable opening those in-table popup button cells when more than one >>> line is selected? >> >> If you choose this route I think a better UI is to change the in-table popup >> bindings to apply to only the specific row. I wouldn’t disable the popup in >> this case as it will always behave as expected, and disabling would seem to >> be an odd UI to me. > > But it is very confusing. You select 5 lines, then press the popup and it > opens. Then you select some new “Species” option. Mac UI rule is “Action is > always applied to current selection”.
It is just my little quibble, and worth the grain of salt that it is, but I would say that behavior is not typical in a table, where the controls in a row are expected to act on that row only. For instance, if the control was a checkbox or radio button, would you expect it to effect every selected row, or the row with the control? A popup menu is just a larger arbitrary set of options, but essentially serves the same purpose as those controls. Now, if it was a “command” type, i.e. that it didn’t show a value but allowed a user to select an action, by all means it should effect the selection. But being in every row would then seem odd ;-) Anyway, I wouldn’t say it is necessarily a bad UI, and as long as you have also implemented robust undo it would be probably be OK for most people. > However - when I uncheck the same thing on the same binding on the > NSTableColumn / NSPopupButtonCell — nothing happens!!! this is mighty weird > for me. You mean it doesn’t disable on multiple selection? At any rate there are clearly some oddities with in-table bindings. > I remember you wrote “Table editing mechanism is interfering” - but how? and > how can I affect it? I might be talking out of my hat but I think that what might be happening is that the table knows you clicked in a row but is letting the popup handle it (because the control need to to operate properly) but on mouse-up the table decides to handle the click by changing its selection to to clicked-in row. You can verify this by implementing -tableViewSelectionDidChange: (as delegate or just observe notification) and checking the model value to see whether it had changed. If it hadn’t, it means that the tableview is changing the selection before bindings can apply its change. If this turns out to be the case, one possible workaround is to cache the selection and apply the change to all previously selected items and re-select. Since you only want to do this when changing the “species” value you can use KVO to detect a change. > Here I have some success — I was able to implement the NSMenuValidation > protocol, and Identify both popup button’s menu-items, using their TAG. When > binding the “Content” and “Content Values” of those popups, you can specify > “Content Placement Tag” (an integer) and then you can tag a template > menu-item in the .xib with the same number, and it will be replaced by the > content. > > Now when content binding replaces the single template menuItem with all those > entities - ALL OF THEM carry that tag!!! so here’s how I could do it last. > > My validation is… well…. VERY complicated in this case, and I was able to > write only part of it now, to the point where > 1. Invalid items get disabled. > 2. Invalid item titles are modified to include the REASON for invalidation > (hard to explain - scientific software) > 2. Invalid items get HIDDEN — unless the “Option” key is pressed. > > This is beautiful - same validation applies to both Popup outside the table > and in the table. > > Still it maddens me - the popup OUTSIDE the table behaves very strangely on > the display. Sometimes it will “honor” the option key, sometimes not. Every > time I press that popup button the whole window resizes and the popup becomes > bigger and bigger, although it doesn’t display anything very long. Maybe some > auto layout issue, I don’t know - but still this is strange. Can’t say, but if your assumption on autolayout is correct, it should only resize based on the content, so it shouldn’t always go up, it should also go down when the content is shorter. HTH, Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
