Re[2]: [lmi] wxHTML table header alignment

[Vadim Zeitlin]

On Wed, 11 Mar 2009 10:04:29 +0000 Greg Chicares <address@hidden> wrote:

GC> | - Added {wxTextCtrl,wxComboBox}::AutoComplete() and 
AutoCompleteFileNames().
GC> 
GC> AutoComplete() might be useful for lmi. In some "input sequence"
GC> fields, we permit both numbers and certain "keywords"; I'm thinking
GC> of a completion feature for the keywords. I looked at
GC>   http://docs.wxwidgets.org/trunk/classwx_text_ctrl.html
GC> but didn't see this function documented there; should it be?

 It's in wxTextEntry (from which wxTextCtrl inherits) and so can be found
at http://docs.wxwidgets.org/trunk/classwx_text_entry.html

 I'm not sure if this can be used for the input sequence fields though as
the set of their possible values doesn't seem to be finite at all and auto
completion only works for the entire contents of the text control, not for
a single word/token in it (unless you combine it with something like the
much-discussed-but-yet-to-be-written wxMasjedEditCtrl mentioned at
http://wiki.wxwidgets.org/Development:_Student_Projects#Masked_Edit_Control).

GC> | - Added support for drop down toolbar buttons (Tim Kosse).
GC> 
GC> Like ms excel's font, font size, and font color toolbar dropdowns?

 No, these are just normal (well, not quite normal as Excel doesn't use the
standard controls) comboboxes and it was always possible to put them, as
well as arbitrary other controls, in a toolbar. The drop down toolbar
buttons are what Firefox or Internet Explorer use for their "Back" button,
i.e. it's just like a standard button but it also has a drop down menu.

GC> | - Optimize wxGenericTreeCtrl::Collapse/ExpandAllChildren()
GC> 
GC> Does that suggest that the following idea would now be easier to
GC> consider?

 I don't think this changed any functionality, it just made these functions
more efficient (which is noticeable for big trees).

GC> On 2008-02-23 03:33Z, Greg Chicares wrote:
GC> !
GC> ! * For msw, I thought the numpad '*' and '/' keys normally worked
GC> ! like '+' and '-', but for all tree-control branches at once: i.e.,
GC> ! "expand all" and "collapse all", somewhat as described here:
GC> !
GC> ! http://88.191.26.34/XYwiki/index.php/Tree
GC> !
GC> ! But when I tried that with a treeview control in ms "control spy",
GC> ! only '*' had the effect I expected, and only when the root node
GC> ! was selected, so I guess wx is just doing whatever msw normally
GC> ! does.

 Yes, I don't think '/' has any special meaning for the native control.

GC> | Nevertheless, if you think this would be a good enhancement,
GC> ! then please feel free to add it.

 I don't think it's a good idea to do this by default as people might use
'/' key for something else but it is certainly possible to do this in LMI.

GC> | - Show busy cursor in wxLaunchDefaultBrowser and add 
wxBROWSER_NOBUSYCURSOR.
GC> 
GC> A stray thought: maybe we should use wxLaunchDefaultBrowser instead
GC> of wxHtmlHelp.

 It was possible to do this before, wxLaunchDefaultBrowser() just makes it
simpler, so this shouldn't really change anything for this question. But
it's indeed much more common to show help in the (users default) browser
rather than doing it inside the application itself nowadays.

GC> | - Added "enabled" and "hidden" attributes to radio box items in XRC.
GC> 
GC> Another half-baked thought: we might use that to hide certain
GC> radiobuttons that would always be grayed on certain skins due to
GC> problem-domain esoterica. What happens, though, if for even more
GC> esoteric reasons such a radiobutton becomes selected (by the
GC> program, not the user)? Would it then automatically become
GC> unhidden?

 No, there is no code to do it in place currently. IOW I think this is
going to be very confusing so we probably ought to do something about (the
simplest would be to assert if the program tries to do this).

GC> | - Documentation for wxWidgets has been converted from LaTex to C++ headers
GC> |  with Doxygen comments and significantly improved in the process
GC> 
GC> I've written lots of "///" doxygen comments in lmi, and I've been
GC> meaning to ask whether you knew of any new tool that might have
GC> displaced it. Now I don't need to ask. It's not that I dislike
GC> doxygen; it's just that I don't read slashdot or freshmeat or
GC> whatever, so I don't know when I've fallen behind the times.
GC> If you want to comment more on this

 Not particularly, but I just wanted to say that Doxygen is a de facto
standard for writing this kind of documentation nowadays which is why I
prefer to use it for my other projects too even though it's certainly not
ideal.

 Regards,
VZ