<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 5 June 2017 at 05:57, James Paige <span dir="ltr"><<a href="mailto:Bob@hamsterrepublic.com" target="_blank">Bob@hamsterrepublic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="gmail-">On Sat, Jun 3, 2017 at 8:28 PM, Ralph Versteegen <span dir="ltr"><<a href="mailto:teeemcee@gmail.com" target="_blank">teeemcee@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>Showing a textbox and a menu at once is wonky, and I didn't understand at all how it worked until spending 20 min reading the source, so I think it's safe to say tahat very few people do.<br>Keypresses only affect the top-most menu, but they generally are also interpreted by the textbox, except the textbox is not affected if the menu suspends gameplay.<br></div><div>(Interestingly, opening a menu is the only way to suspend choicebox cursor controls)<br></div><div><br></div><div>So, if not suspending gameplay, pressing enter will cause both the textbox to close and the menu to activate... unless the selected menu item is one of the builtin menus, in which case the enter keypress will be cleared when leaving the menu, so that the textbox doesn't close.<br></div><div><br></div>Even worse, when showing a textbox with a choice box at the same time as a menu the arrows keys affect both of them! This clearly should be fixed, but I think the Enter behaviour is bad too.<br></div><div><div><br></div><div>Currently you can give the menu sole focus by setting it to suspend gameplay, and you can give the textbox focus by setting "No player control of menu", although then you need to use a script to close the menu.<br><br></div><div>Clearly to change anything we need a backcompat bit, but it's not easy to see what to change to. I want to simplify, not make it make complicated.<br>I think we need to track whether the textbox or the menu has focus (whichever was opened last), and maybe even (virtually) put the textbox in the menu stack.<br></div><div>So if a menu is opened from a textbox, or a textbox from a menu, then it takes focus; but we also will want a way to override that; maybe the 'No controls' menu bit can be repurposed.</div></div></div></blockquote><div><br></div></span><div>I agree, the current behavior is a mess, and anything it does now is just implementation quirks, not planned or desired behavior.<br></div><div><br>I love the idea of menus or textboxes having focus. Now that you mention it, one of my forgotten plans as part of converting things to slices was to allow the text box layer and the menu layer to change their order so either one could be on top.<br></div></div></div></div></blockquote><div><br></div><div>Hmm. It makes sense that whatever has focus is on top (though I'm a big fan of focus-follows-mouse :). And you would always override it anyway.<br><br></div><div>If a menu or textbox is opened without taking focus, then the textbox/menu that opened it needs a way to close it when it closes. Menus can already close textboxes but not the other way around.<br><br></div><div>Thinking about the most common case, a textbox with a menu instead of a choice box, would be helpful. Of course that's another feature. (Should we turn choiceboxes into menus? Or put a simplified menu editor in the textbox editor (meaning it doesn't create a new menu ID in the menu editor, but does create a MenuDef when you load it)? Or just add a shortcut for creating a new normal menu and linking it to the textbox?)<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>If I remember correctly, my original intention for the "No player control of menus" was a somewhat ill-conceived pre-slice idea bout using menus as informational displays while the player was still waking around and acting normally. I don't know if anybody ever use that bit that way or not.<br></div></div></div></div></blockquote><div><br></div><div>I think it's used that way in Entrepreneur; or were all those displays slices only?<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div></div><div>Also, maybe we should think ahead to the possible ability to have mutliple textboxes open at once, on a stack.<br></div></div></div></blockquote><div><br></div></span><div>That could be useful, but lets not worry about it too much until somebody has a game idea that needs it.</div></div></div></div></blockquote><div><br></div><div>Maybe it's difficult to come up with a situation where it would be *needed*, but aren't there a number of RPGs that show two textboxes at once? Just don't ask me to name any... I can't remember playing any.<br></div><div>It's hard to see how that would actually work, though.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div></div><div>(I also think it's strange that ESC doesn't advance textbox, so would like to add a backcompat or pref bitset for that.)<br></div></div></div><br></blockquote><div> </div></span><div>That sounds reasonable to me :)<br><br></div><div>I don't remember why I excluded ESC from doing that in the first place.<br></div></div></div></div>
</blockquote><div><br>Also, I suggest we make suspendboxadvance suspend choicebox 
controls too. They're useless when you can't hit enter, unless you use a
 script to advance the box instead, but that would be really weird... <br></div></div><br></div></div>