ExpandoTextCtrl auto-expand behavior with mousewheel.

In the wxPython demo the ExpandoTextCtrl does not auto-expand when
using the mouse wheel to change font size. Should it?

Reasoning is:
in the demo module: ExpandoTextCtrl.py the line:
    self.eom.SetFont(dlg.GetFontData().GetChosenFont())
causes the widget to auto-expand, but the CTRL mouse wheel, although
causes the font to change size the control does not.

End of question.

Just thoughts (not a request):
Personally I'd like to see the auto-exand be controlled by the style
flag:
        self.eom = ExpandoTextCtrl(p, size=(250,-1), sytle= ...)
wx.lib.expando.ETE_REFIT_FONT_CHANGE
wx.lib.expando.ETE_REFIT_ON_FONT_SIZE
wx.lib.expando.ETE_REFIT_ENTER
wx.lib.expando.ETE_REFIT_CHAR
wx.lib.expando.ETE_HORIZONTAL
wx.lib.expando.ETE_VERTICAL

ETC_ is for events. ETE like TE_MULTILINE might be for styles
OR have some getter/setters too or instead of style flags

Optional idea, expand horizontally on CHAR events, expand vertically
on ENTERKEY events
Mindbending optional idea, have __init__ args vertical, horiztonal
which are each flag attributes for the direction they autoexpand on.

Seperate but connected issue:
Also when adding this widget into a sizer with the flag wx.SHAPED, it
looked like weirdness happened (mostly because I haven't totally
figured out how to work with this widget yet.

It'd be nice to use the wx.SHAPED flag in a sizer to tell this widget
to expand horizontally IF the idea of those style flags are of
interset.

In the wxPython demo the ExpandoTextCtrl does not auto-expand when
using the mouse wheel to change font size. Should it?

Reasoning is:
in the demo module: ExpandoTextCtrl.py the line:
     self.eom.SetFont(dlg.GetFontData().GetChosenFont())
causes the widget to auto-expand, but the CTRL mouse wheel, although
causes the font to change size the control does not.

Changing the font with Ctrl-Wheel is a native behavior of the widget that wx does not implement or control, and apparently we also do not get any notifications of the change, at least on the messages that wx listening to. In other words, I don't think there is currently any way for the expando ctrl to adapt to the font being changed this way.

End of question.

Just thoughts (not a request):
Personally I'd like to see the auto-exand be controlled by the style
flag:
         self.eom = ExpandoTextCtrl(p, size=(250,-1), sytle= ...)
wx.lib.expando.ETE_REFIT_FONT_CHANGE
wx.lib.expando.ETE_REFIT_ON_FONT_SIZE
wx.lib.expando.ETE_REFIT_ENTER
wx.lib.expando.ETE_REFIT_CHAR
wx.lib.expando.ETE_HORIZONTAL
wx.lib.expando.ETE_VERTICAL

ETC_ is for events. ETE like TE_MULTILINE might be for styles
OR have some getter/setters too or instead of style flags

I'll look at patches for adding support for new styles, although I would prefer keeping the ETC prefix. (EVT_ETC_ is for events)

Optional idea, expand horizontally on CHAR events, expand vertically
on ENTERKEY events

I think this would cause more problems than benefits.

Mindbending optional idea, have __init__ args vertical, horiztonal
which are each flag attributes for the direction they autoexpand on.

How would this differ from the ETE_HORIZONAL/VERTICAL style flags?

Seperate but connected issue:
Also when adding this widget into a sizer with the flag wx.SHAPED, it
looked like weirdness happened (mostly because I haven't totally
figured out how to work with this widget yet.

It'd be nice to use the wx.SHAPED flag in a sizer to tell this widget
to expand horizontally IF the idea of those style flags are of
interset.

wx.SHAPED tells the sizer to maintain the aspect ratio of the item, but the ETC is able to change its own size (and aspect ratio) when needed to fit the text, so I don't think there is any harmonious way for the two to work together...

···

On 10/30/11 7:37 PM, DevPlayer wrote:

--
Robin Dunn
Software Craftsman

Mindbending optional idea, have __init__ args vertical, horiztonal
which are each flag attributes for the direction they autoexpand on.

How would this differ from the ETE_HORIZONAL/VERTICAL style flags?

That was just messy brain storming; Perhaps with arguments you'd have WHAT
causes a vertical expansion verse what causes a horizontal expansion.
Just the two style flags implies that whatever caused a vertical expansion
and what caused a horizontal expansion would be a fixed thing, like
perhaps maxWidth reached means "now expand down instead of horizontal"

so the WHAT with __init__ arguments could be designed on either
horizontal=WM_ENTER, vertical=WM_CHAR # keys
or horizontal=wx.LEFT|wx.RIGHT, vertical=wx.BOTTOM # or border limits
set by sizer
or horizontal=2, vertical=1 # expand the higher proportion (as in a
    sizer.Add(obj, proportion)) before the lower proportion
or horizontal=next_widget_below, vertical=next_wiget_on_left,
    # when border of said widget is touched expand in the other direction
or if there is a better idea to flag when one border should expand verse another

Here's a thought; horizontal = 79 # as in expand horizontal until 79
chars in a line is hit
# a Python coding practice

But my chatter there wasn't a request for development on it at all.
Nor did I personally had a use case for it.
Just ideas that popped into my head and I blabbled them out.

Seperate but connected issue:
Also when adding this widget into a sizer with the flag wx.SHAPED, it
looked like weirdness happened (mostly because I haven't totally
figured out how to work with this widget yet.

It'd be nice to use the wx.SHAPED flag in a sizer to tell this widget
to expand horizontally IF the idea of those style flags are of
interset.

wx.SHAPED tells the sizer to maintain the aspect ratio of the item, but the
ETC is able to change its own size (and aspect ratio) when needed to fit the
text, so I don't think there is any harmonious way for the two to work
together...
Robin Dunn

Too bad the term wx.SHAPED was used instead of wx.RATIO
wx.SHAPED could have been used to flag that the data IN the widget
would imply a shape.

For example:
txt1 = 'long line of text with only on return key where the writer
goes on and on in a never ending line that just could be any thing
that has but one return, that the coder wants to wrap with the
textcontrol fills with this text and expands horizontal all the way to
the edge fo the frame.'

txt2 = 'long line of text with only on return key where the writer
goes on and on in a never ending line that just could be any thing
that has but one return, that the coder wants to wrap with the
textcontrol fills with this text and expands horizontal all the way to
the edge fo the frame.'

tx32 = 'long line of text with only on return key where the writer
goes on and on in a never ending line that just could be any thing
that has but one return, that the coder wants to wrap with the
textcontrol fills with this text and expands horizontal all the way to
the edge fo the frame.'

frame = wx.Frame(...); panel = wx.Panel(...)
etc1, etc2, etc3 = ETC(), ETC(), ETC() # An expando-like-widget
box = wx.ShapedBoxSizer(wx.SHAPED, WM_ENTER)
etc1.SetValue(txt1); etc2.SetValue(txt2); etc3.SetValue(txt3);
box.AddMany( (etc1, 0, flags, 0), (etc2, 0, flags, 0), (etc3, 0, flags, 0))
panel.SetSizerAndFit(box)
....etc.

would make a frame with 3 horizontally long widgets because there's
only one return char.

Where as
txt1 = '''bla bla bla
spam spam span
eggs eggs eggs
runaway runaway etc
killer rabbit
thanks for the fish
green no blue aaahhhh
african swallow
bla bla bla
spam spam span
eggs eggs eggs
runaway runaway etc
killer rabbit
thanks for the fish
green no blue aaahhhh
african swallow'''

txt2 = txt1[:]
txt3 = txt1[:]

these txt data would make 3 vertically long widgets;

One potential use case that comes to mind: copying a nuke-like web page
into a set of columnular like textctrls for editing; perhaps a forum reader,
or newspaper like website.

No comments expected on this. It's out there for anyone so inclined to
muse over.

···

On Mon, Oct 31, 2011 at 3:09 PM, Robin Dunn <robin@alldunn.com> wrote: