On 19 February 2011 05:08, James Paige <[email protected]> wrote: > On Fri, Feb 18, 2011 at 04:24:21PM +1300, Ralph Versteegen wrote: >> On 18 February 2011 05:00, James Paige <[email protected]> wrote: >> > On Thu, Feb 17, 2011 at 03:44:12PM +1300, Ralph Versteegen wrote: >> >> On 17 February 2011 06:12, James Paige <[email protected]> wrote: >> >> > mjohnson just pointed out on a slimesalad thread that menu item tags get >> >> > set AFTER the menu action. >> >> > >> >> > For the "Save" menu, this is guaranteed to be the wrong thing to do, and >> >> > the more I think about it, the more it seems wrong for all special menu >> >> > types... (except possibly text boxes?) >> >> > >> >> > I feel like I need to add a menu item bitset to control whether the tag >> >> > setting happens before or after the menu action. >> >> > >> >> > What I want to discuss is what the default should be, and what the >> >> > possible backcompat consequences could be if the default is the reverse >> >> > of what it is now. >> >> > >> >> > ---- >> >> > James >> >> >> >> Actually, it turns out that I already made tag changes occur before a >> >> triggered textbox is loaded in r3751 without realising it. Opps. >> > >> > My thought on text boxes from menus is that a tag would most often mean >> > "I already saw this text box" and therefore it might matter for >> > instead-chaining of the first text box. >> >> So do you want to keep this change or revert it? > > I say leave it for the moment, and we can fix it when we resolve the > general case > >> >> Do tags actually affect any menu actions aside from loading textboxes >> >> and saving the game (and hero/item special tags which is already a >> >> fixed bug)? Changing tags after saving the game doesn't sound like a >> >> bug which I'd expect anyone to be relying on. >> > >> > Yeah, fixing just the "save" case seems really safe. >> > >> > Rather than a bitset, maybe a Default/Before/After choice is the way to >> > go? >> > >> > --- >> > James >> >> Aside from back-compatibility, I'm not really in favour of this >> bitset, because it seems like mostly-useless complexity. >> >> I'd rather we not add a default option because then you're left >> wondering what the default is. Instead just initialise the bitset to >> the default value (and add a fixbit to apply the existing default to >> existing menu items). > > That is a very good point. Just before/after does seem less confusing > now that i think about it more. > >> And anyway, wouldn't the new default be to always apply tag changes >> before triggering actions, because that seems the obvious thing to do? > > Yes, I think setting the tag first is most logical. > > Here is a thought. Maybe the default for menu tags should be "before" > across the board, including text boxes. > > The case I was worried about with text boxes, a menu item that sets a > tag and then calls a textbox that uses the same tag in the instead-chain > of the first box could be detected and adjusted to "after" in the fixbit > code. > > foreach menu > foreach menuitem > if opens textbox and checks tag > if textbox has same tag for instead change > default to "after" instead
This sounds like a good plan. > --- > James _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
