Verbs don't allow enough control over the popups that appear.

ID:1824419
 
Apr 4 2015, 8:04 am
Applies to:DM Language
Status: Open
Issue hasn't been assigned a status value.
I am currently having to code effectively two different versions of some verbs to get the behavior I am looking for...

One that executes from the verb panel, and the other in right click menus for mobs...this is because there's hardly any control over the popup that comes up with verbs...

mob
    verb
        Kick_From_Group(var/a as null|mob in usr.group)
            if(a)
                src<<"[a] was removed from your group."
                group-=a


That's the closest I could get to what I wanted...but there would be a few ways to fix this...

Either add a new verb setting...such as "set popup=1" is normal, "set popup=0" would force it to pick automatically, the 1st entry so it can be determined without hassle...could be potentially useful for a spell like Telekinesis which grabs items, and a popup in the middle of battle would be rather useless...so just grab the item...

The other option would be "set popup=2" which if there's only one entry would still force the popup to come up unless you've already picked, such as by right clicking someone and using the verb with them directly...

***Other possibilities include allowing us access to code to determine how the verb was invoked, which possible values would include called by code, verb panel click, or right click menu...possibly also by macro or typed in on the users command bar as well...so this might be trickier since there's so many more possible ways...

The other possibility is letting me simply have control over the buttons that are displayed in this window...I don't know the possible syntax that could be used for potentially allowing access to this though...

***The final possibility I have thought of is to add another input type which is "nothing" rather than "null" which would trigger the "Cancel" button to show up and "null" would trigger the "None" button as it does now...since "Cancel" shows up by default, although not in input but in the case of these verbs...then it would simply force the dialog to open even with only one entry so it could be properly cancelled if needed...

*-*-*-*-*
Of course you could simply change the behavior and make it show up when you click the verb panel with only one possible entry so that you can make sure the user really wants to do it, which if they used right click, they would be sure...but not technically if they click the verb since they don't know what option or options may be available, and if it automatically goes on for them, it may do something undesired automatically.
Apr 4 2015, 10:08 am
Ugh, the constant ... is maddening. I'm finding it very, very difficult to wade through your posts.

I honestly don't see how the current behavior is inadequate, but then you didn't actually say what you're trying to accomplish. The "as null|mob" (or null|anything, or what have you) says that a mob or null is allowed, null being the cancel/none option. That seems plenty good to me. If null is not allowed and there's only one item, the input never pops up because there's no ambiguity.
Apr 4 2015, 10:13 am
The reason I want it to popup still is because their hitting a verb...even if there's only one option, it's not immediately apparent to the user what the option is...but it uses it anyways...

I tried using null|mob to force the dialog to appear...when using input() however it just adds a cancel button...

In this instance it has OK, Cancel, and a button that says "None".

It works fine, but I don't want 3 buttons...and cancel does what I want input() to do with a cancel button...prevent further code execution...but it just returns null or whatever the default value is...

Similar to what the added 3rd "None" button is doing in this case...

But at least the null|mob option brings up the dialog when there's only one real choice...because null has never been an actual valid choice in anything I've ever made...
Apr 4 2015, 10:22 am
I think I see what you mean for verb execution, because there "None" means "I mean null but run the command anyway", but I don't see why an input() would be unacceptable. If the verb simply launched an input() box, you shouldn't have the "None" option; there should be your list, and the OK and Cancel buttons.
Apr 4 2015, 10:32 am
He wants to be able to use the verb in right-click context menus, as well as actually seeing the input prompt (with "OK" and "CANCEL") when using the verb (through the panel, or command input) when the specified list has only one item in it.

Using input() would not work for the right-click case.
Apr 4 2015, 10:34 am
In my example since it uses "usr.group" it allows the verb to populate with right click commands, as well as the verb panel (obviously)

If I use input() with my list though it negates the use of these commands in the right click menu completely, which is what I want to avoid.

I could potentially create one verb for the verb panel, and another for the right click menu but excluding that, the way to make a single verb populate with the right click menu, but also pop up with a single option still is to use "null|mob"

I know lots of people have been complaining for a long time about input() though and nothing has been done, mainly because interfaces can easily make up for the short-comings of input() and the need for users to modify the style of everything can't possibly all be coded into the language natively, but I'm not looking for an overhaul, just that there's a similarity between how input() works and how these other dialogs are working.

They both look like an input() dialog to me, but they work differently, and are called up in a slightly different way is all. Either "Cancel" should do nothing when it's added with null|anything in input() like cancel does here.
Not just return null.

Cancel could become standard in inputs, or get rid of the default "Cancel" button in these windows, and let it return null and popup with the cancel button only when the null flag is set.
Apr 4 2015, 11:06 am
In response to Super Saiyan X
Super Saiyan X wrote:
He wants to be able to use the verb in right-click context menus, as well as actually seeing the input prompt (with "OK" and "CANCEL") when using the verb (through the panel, or command input) when the specified list has only one item in it.

Using input() would not work for the right-click case.

I think I see what you're saying. I don't really see the utility of having the popup when there's only one item, but I understand why it'd be impossible to control that currently if the goal is to have the same verb work in two different formats.
Apr 4 2015, 11:26 am
The player may not be aware that the verb can only select one thing which might not be what the player wants. The single-item menu is basically a confirmation window so the player can back out without having to have a second confirmation window, which is undesirable when the selection box does appear and already acts as a confirmation window.