A combobox alternative

[stam]

Hi all,
Looking for testers for this small group-control that provides a more advanced comboBox.

Differences with built-in control:
- Resizable field and dropdown menu (depending on if dropdown is showing)
- Search as you type
- Keyboard navigation
- get/set text and list by setting textContent and listContent of the group
- Placeholder/hint text to aid user input (also settable as custom prop)
- All properties have getters/setters - also comes with a controller stack (plugin) to add a control to a stack and edit it's props
- a message ("comboAction") is emitted when a value is selected or typed

skComboBox.jpg (12.14 KiB) Viewed 558 times

I would be very grateful for feedback and raising any issues
More detail, API and download from my GitHub repo: https://github.com/stam66/skComboBox

Many thanks,
Stam

[stam]

I've updated the controller stack to allow drag/drop of an skComboBox to a topLevel stack (based on code by @PaulDaMacMan from his stack posted here - thanks Paul, it works extremely well!). I've also tightened up the interface.

Add an skComboBox by drag/drop or double-click (if no topLevel stack available, it copies instead). Option-doubleClick to copy.
Selecting an skComboBox in a topLevel stack will allow editing of its properties in the controller stack but all properties can be get/set in code.

Updated controller:

The GitHub link is https://github.com/stam66/skComboBox, but for convenience also attaching to this post.

Stam

[dunbarx]

Stam.

I tried playing with this. The first time I dragged one onto a new stack I saw that clicking on the arrow offered three choices in a pulldown. Very like the standard type in LC. But I could not access any of the other features in the original stack. When I deleted the control and pulled another to the same stack, it did not work at all.

Need to read the manual?

Craig

[dunbarx]

Ah.

I see that the new combo has to be selected for the other features to work back in the main SK stack.

I could not change the submenus and make the new items stick. And afterwards, the actual SK gadget was unresponsive.

Not a well presented list of issues, I know, but just a first try...

Craig

[stam]

Hi Craig,

I see that the new combo has to be selected for the other features to work back in the main SK stack.

Yeah - how else would that work? it's like setting the properties in a the property panel... you have to select the object in the IDE.

I could not change the submenus and make the new items stick. And afterwards, the actual SK gadget was unresponsive.

I've never seen any unresponsiveness - can you provide a recipe to reproduce?

I did realise that typing text in the fields is problematic, because it's set on textChanged (meaning that as soon as you type a single char it updates the selected object and the field exits and you have to type 1 char at a time). I'll change that to on closeField, so it only updates the selected object on exiting the field and you can type freely.
Having said that I have never had any difficulties making changes "stick".


I'm refactoring the code for the drag/drop which isn't quite done, but will post an update when it is and will include the slight change to make typing in the controller work properly...

Thanks for testing,
Stam

[stam]

I see that the new combo has to be selected for the other features to work back in the main SK stack.

I could not change the submenus and make the new items stick. And afterwards, the actual SK gadget was unresponsive.

Not a well presented list of issues, I know, but just a first try...

Craig

Hi Craig,
The issue with entering text in the controller stack should be fixed.
I've also made it more obvious you can't set any properties when no skComboBox is selected in the IDE.

I have not managed in any way to make this unresponsive or not make changes stick - if you can reproduce these issues, please let me know the recipe so I can fix.

As mentioned, the stack should be used in a similar way to a property inspector (since I've yet to figure out how to use the PI for a group, I've had to build my own).
The control at the top of the stack is to drag/drop or double-click to place an skComboBox in a topLevel stack, this will not work within the plugin's stack. The tooltip hopefully clarifies this, but if it's confusing I can add a label...

Note: to actually use the an skCombobox that has been placed in a topLevel stack, you need to be in browse tool or have placed it on to a stack which is then made into a palette, but this is no different from the built in combobox and should be used in the same way.
Also: This is a group. If you have Selected grouped on, you won't be able to edit in the stack as it will only see the component selected, not the parent group (could this have been why you found this unresponsive?).

This stack isn't really needed for changing properties - you can change all the properties via script.
I've changed the tooltips to just show the property names, should be straightforward to use.
For example to change the placeholder/hint text and the choices from the text box with the skCombobox selected you can just type:

Code: Select all

set the placeholderText of the selectedObject to "This is a hint"
set the listContent of selectedObject to "1 - something" & return & "2 - something else" & return &  "3 - final choice"

One thing that may be less clear is how to resize the dropdown. If resizing when collapsed, in only resizes the text entry field height (the width is resized for both field and dropdown).
If dropdown is visible when editing, in will instead resize the dropdown - but always to the width of the text entry field.
To keep the dropdown showing when entering edit mode/pointer tool, either hold down the optionKey or ensure the mouse is within the rect of the group (as should be the case if using cmd-0).

skComboBox documentation and download from my GitHub: https://github.com/stam66/skComboBox
For convenience, stack is attached below...

Many thanks for testing - and do let me know if any persistent problems...

[stam]

Minor changes:
- Fixed an issue with the reset-to-defaults
- Changed the behavior to make it even clearer when an skComboBox is or isn't selected:
Instead of covering the property editors with a graphic to make them inaccessible, the stack resizes to show or hide the property editors respectively:

Updates always available on GitHub: https://github.com/stam66/skComboBox
For convenience stack attached below.

Grateful for feedback
Stam

[dunbarx]

Stam.

Your v.2 gadget seems to work mostly fine. If you make the textSize too large, the "title" field (not the menuItem list) overloads. Also, the action is different from the stock version (and other such) in that the menuItem list is invoked on mouseUp, which is different than most, which fire on mouseDown.

Craig

[dunbarx]

Stam.

You should prevent the gadget from responding if the cursor is outside the rect of the group. Right now I can invoke the menuItem list, and if I fool around a bit, I can scroll and select from anywhere on the card. Also, how do you trap "menuPick"?

Craig

[stam]

Stam.

Your v.2 gadget seems to work mostly fine. If you make the textSize too large, the "title" field (not the menuItem list) overloads. Also, the action is different from the stock version (and other such) in that the menuItem list is invoked on mouseUp, which is different than most, which fire on mouseDown.

Craig

Hi Craig - do you mean the text gets too big for the field? - the assumption I made (because of what I would do) is that the user would resize the group to fit the text - I didn't want to automatically set the size because there may be a desire to set the size independently of text size (ie big field with smaller text).

The text size resizes both the field and the dropdown text sizes, so both may need to be resized separately.
It's easy enough to resize automatically if that's what seems more logical?

PS: rawKeyUp is used because the group widget needs to check for the hint/placeholder text, easier to do it that way and I don't really see a problem with it not being the same as the built in widget, which doesn't provide placeholder text... But if you're referring to clicking the disclosure triangle that is again on purpose. I dislike buttons where the user can't change their minds by moving out of the clicked area. Is that a major issue?

[richmond62]

I am not sure if the components in the group resize as the group is resized.

[stam]

You should prevent the gadget from responding if the cursor is outside the rect of the group.

I'll admit this one has me completely stumped. Scrolling and arrowKeys are set in the group's rawKeyDown handler and should not respond if the field hasn't go the focus. However in rawKeyDown, if I add the line

Code: Select all

if the long id of control id sFieldID <> the focusedObject then pass rawKeyDown

the issue persists because weirdly enough the field (control id sField) still has the focus even though it's not focused! Confirmed by putting the long name of the focusedObject in msg from inside rawKeyDown.

The field seems to maintain the focus even if clicking out of and making it lose its focus ring.
What's weirder is if you click a 2nd time outside of the group widget, this is then no longer the case.
For the life of me I dont' understand this.

I didn't want to limit access to the mouseLoc being within the rect of the widget because if you're tabbing through and just want to set by keyboard, that won't work... one of the main reasons I wanted this because the build-in widget needs you to tickle it with the mouse...

I honestly don't understand how the group will still respond to it's own handler (and the focusedObject still being reported as the field), when deactivated by clicking outside of this... is it a bug?

Also, how do you trap "menuPick"?

Because I'm aiming to make script widget of this, for now this is a message that is emitted up the messagePath - when a text item is set, it emits the message comboAction pID, pText - which you can trap in the parent. pID is the long id of the group control, pText is the textContent of the group widget.

Once this is a script widget, it will appear in the list of handlers under that control. I'll see about adding this to the group itself but would need care as the group's script is long and I would probably need to assign it as a behavior to free up the actual group script.

[stam]

I am not sure if the components in the group resize as the group is resized.

I realise it's difficult to read everything above when there's a lot of text. For your convenience:

One thing that may be less clear is how to resize the dropdown. If resizing when collapsed, in only resizes the text entry field height (the width is resized for both field and dropdown).
If dropdown is visible when editing, in will instead resize the dropdown - but always to the width of the text entry field.
To keep the dropdown showing when entering edit mode/pointer tool, either hold down the optionKey or ensure the mouse is within the rect of the group (as should be the case if using cmd-0).

In other words you can resize both field and dropdown independently, depending on whether the dropdown is showing in pointer tool or not.

[stam]

You should prevent the gadget from responding if the cursor is outside the rect of the group. Right now I can invoke the menuItem list, and if I fool around a bit, I can scroll and select from anywhere on the card. Also, how do you trap "menuPick"?

Craig

Hi Craig and thanks for testing this further and picking up what I think is probably a bug (I've posted this in Bug triage for opinions).

As mentioned, restricting actions to only happening when the mouse is within the rect of the group defeats the purpose of keyboard navigation, so that was always a no-go. I never though to test what you did (kudos btw ) and still don't understand why it happens click once outside of the field and stops happening if you click a 2nd time on the card... sigh...

In the mean time, I addressed the issue but adding the line "Focus on nothing" in exitField/closeField. I really didn't think this would need to be done, but it obviously does and this fixes it.
Thanks for picking this up!


Regarding your other comments (to recap the above reponses)
1. the group does not auto-resize on textSize change - mainly because I wanted to disconnect the size of the fields from the textSize. The rects of the field and dropdown can be adjusted independently as above. For simplicity I have stuck with one parameter affect both fields' textSize and arbitrarily have made the drop-down's text 1 point smaller than the field entry textSize - but not sure that I'll stick with that.
2. MouseUp is intentional/personal preference
3. The equivalent of menuPick is a message called combAction pID, pText that is emitted up the message path when a value is set. This means it needs to be handled in one of the group's parents (parent, card, stack, backscripts). The reason for this as mentioned is that this is the requirement for the message to appear as a preset in the left column of the script editor, and can be added to the widget's script much like menuPick in a the normal widget.


Thanks once again for the ongoing testing!
The new version that addresses the wanton weird scrolling is available at the GitHub URL above, but also attached for convenience,

Stam

[bobcole]

Stam:
My compliments on your comboBox. It is quite handy.
It is almost 1000 lines of code which I don't have to figure out on my own.
Thanks,
Bob