On Sun, Aug 31, 2008 at 05:03:27AM +1200, Ralph Versteegen wrote: > On Thu, Aug 28, 2008 at 6:35 PM, <[EMAIL PROTECTED]> wrote: > > james > > 2008-08-27 23:35:09 -0700 (Wed, 27 Aug 2008) > > 211 > > Re-wrote the textbox conditional editor to use TextBox object. > > Gosh almighty, some of that text box code was messy! It's still bad, > > but I managed to entirely strip out the ct() and order() layers of > > abstraction > > --- > > U wip/common.bas > > U wip/common.bi > > U wip/loading.bas > > U wip/subs2.bas > > Wait, how is moving from the ct() array to the > box_conditional_type_by_menu_index function an improvement? It does > exactly the same thing, but now the type of each menu item is stored > way off somewhere instead of in textage (on the same lines as the > grey() definitions, which wouldn't be all that great, but it would be > better (in general) to have all the data for a menu item in the same > place - Of course, now I'm talking about a flexmenu-successor new menu > framework.)
The main reason that box_conditional_type_by_menu_index is better than ct(order()) is because box_conditional_type_by_menu_index makes the arrangment of the code based on the display-order of the menu items as they appear in custom, which is a fairly logical way to lay out the code. ct(order()) is based on the order of the data elements in the awful awful .say lump, which ony makes sense if you stare at the .say documentation and chant the lord's prayer backwards while burning black candles. It is still a matter of maintaining a mapping between a menu and a tangle d data file, but I think it is easier (at least for me) to stomach this way. I would have kept the new function nice and close to the code that actually uses it, but I wanted to keep it below the "OPTION EXPLICIT" line. I can move it later after I have cleaned up more. --- James Paige _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
