Thanks Robin, Che and Josh for the tips. Using wx.LIST_AUTOSIZE is
the ticket. I couldn’t find this constant listed in any
documentation.
Josh,
I'm running on a MSW platform and the autosized columns using the
default come out perfectly. I’ve modified [ filehunter.py ] which is
based on 2 ListCtrl’s and the attached screen shot image file shows
the appearance. Maybe your too-narrow-columns problem is either due
to the particular font or the particular platform implementation. (
Is that redundant due, again, to font differences or is this due to
a different bug ? )
The only way I know to precalculate the best minimum column width is
the get the current font, write all the text strings in one column
to wx.MemoryDC’s and read back each DC’s width to find the maximum
width to set the ListCtrl’s column width to. I suspect this is
basically how the wxWidget does autosizing in the first place. This
seems perfectly “do-able” even if it’s takes a lot of work, meaning
CPU cycles, not algorithm complexity. This strategy seems
platform-independent and, perhaps, this is how the basic wx.ListCtrl
should be modified to correct this bug for good. I certainly
wouldn’t hold my breath waiting for the WxWdget control to get
fixed.
Thanks Robin, Che and Josh for the tips. Using wx.LIST_AUTOSIZE is the
ticket. I couldn't find this constant listed in any documentation.
Josh,
I'm running on a MSW platform and the autosized columns using the default
come out perfectly. I've modified [ filehunter.py ] which is based on 2
ListCtrl's and the attached screen shot image file shows the appearance.
Maybe your too-narrow-columns problem is either due to the particular font
or the particular platform implementation. ( Is that redundant due, again,
to font differences or is this due to a different bug ? )
The only way I know to precalculate the best minimum column width is the get
the current font, write all the text strings in one column to wx.MemoryDC's
and read back each DC's width to find the maximum width to set the
ListCtrl's column width to. I suspect this is basically how the wxWidget
does autosizing in the first place. This seems perfectly "do-able" even if
it's takes a lot of work, meaning CPU cycles, not algorithm complexity.
If you look at the source of UltimateListCtrl in wx.lib.agw, you will
see that this is more or less how it's done. As UltimateListCtrl is
the Python port I made of the generic implementation of wx.ListCtrl,
the 2 should behave more or less in the same way. Windows, however,
has its own native version of wx.ListCtrl (which wxWidgets and
wxPython use), so we don't know exactly what MS is doing with it. The
generic implementation is a fallback for platforms who don't have a
native implementation of wx.ListCtrl (GTK, old versions of MAC).
This
strategy seems platform-independent and, perhaps, this is how the basic
wx.ListCtrl should be modified to correct this bug for good. I certainly
wouldn't hold my breath waiting for the WxWdget control to get fixed.
You may try and experiment with UltimateListCtrl (which is almost 100%
compatible with wx.ListCtrl) and see if the bus shows there too. If it
shows, a bug report would be nice on both wxWidgets and AGW so that we
can try and fix it somehow.
I ran into my problem on a large database application that I can't
seem to reconstruct easily.
I had made some efforts to use ObjectListView but my data was done in
XML, and I never figured out
a decent way to make the interface for the ElementTree.Element object
to work with OLV.
Looking at the code, which is in several places and parts after a
system restore, I have no idea what
happened to the code that gave me grief, but I knew I had to resize
after AUTOSIZE.
I guess I have some catch-up coding to do.
Josh
···
On Fri, Aug 20, 2010 at 7:18 PM, Ray Pasco <pascor@verizon.net> wrote:
Thanks Robin, Che and Josh for the tips. Using wx.LIST_AUTOSIZE is the
ticket. I couldn't find this constant listed in any documentation.
Josh,
I'm running on a MSW platform and the autosized columns using the default
come out perfectly. I've modified [ filehunter.py ] which is based on 2
ListCtrl's and the attached screen shot image file shows the appearance.
Maybe your too-narrow-columns problem is either due to the particular font
or the particular platform implementation. ( Is that redundant due, again,
to font differences or is this due to a different bug ? )
The only way I know to precalculate the best minimum column width is the get
the current font, write all the text strings in one column to wx.MemoryDC's
and read back each DC's width to find the maximum width to set the
ListCtrl's column width to. I suspect this is basically how the wxWidget
does autosizing in the first place. This seems perfectly "do-able" even if
it's takes a lot of work, meaning CPU cycles, not algorithm complexity. This
strategy seems platform-independent and, perhaps, this is how the basic
wx.ListCtrl should be modified to correct this bug for good. I certainly
wouldn't hold my breath waiting for the WxWdget control to get fixed.
Andrea, The UltimateListCtrl code has 10,000+ lines in it ! Could
you be a little more specific as to where to look for the column best-
sizing algorithm ?
Thanks,
Ray
···
On Aug 22, 4:04 pm, Andrea Gavana <andrea.gav...@gmail.com> wrote:
Hi Ray,
On 21 August 2010 05:18, Ray Pasco wrote:
> Thanks Robin, Che and Josh for the tips. Using wx.LIST_AUTOSIZE is the
> ticket. I couldn't find this constant listed in any documentation.
> Josh,
> I'm running on a MSW platform and the autosized columns using the default
> come out perfectly. I've modified [ filehunter.py ] which is based on 2
> ListCtrl's and the attached screen shot image file shows the appearance.
> Maybe your too-narrow-columns problem is either due to the particular font
> or the particular platform implementation. ( Is that redundant due, again,
> to font differences or is this due to a different bug ? )
> The only way I know to precalculate the best minimum column width is the get
> the current font, write all the text strings in one column to wx.MemoryDC's
> and read back each DC's width to find the maximum width to set the
> ListCtrl's column width to. I suspect this is basically how the wxWidget
> does autosizing in the first place. This seems perfectly "do-able" even if
> it's takes a lot of work, meaning CPU cycles, not algorithm complexity.
If you look at the source of UltimateListCtrl in wx.lib.agw, you will
see that this is more or less how it's done. As UltimateListCtrl is
the Python port I made of the generic implementation of wx.ListCtrl,
the 2 should behave more or less in the same way. Windows, however,
has its own native version of wx.ListCtrl (which wxWidgets and
wxPython use), so we don't know exactly what MS is doing with it. The
generic implementation is a fallback for platforms who don't have a
native implementation of wx.ListCtrl (GTK, old versions of MAC).
> This
> strategy seems platform-independent and, perhaps, this is how the basic
> wx.ListCtrl should be modified to correct this bug for good. I certainly
> wouldn't hold my breath waiting for the WxWdget control to get fixed.
You may try and experiment with UltimateListCtrl (which is almost 100%
compatible with wx.ListCtrl) and see if the bus shows there too. If it
shows, a bug report would be nice on both wxWidgets and AGW so that we
can try and fix it somehow.
Andrea, The UltimateListCtrl code has 10,000+ lines in it ! Could
you be a little more specific as to where to look for the column best-
sizing algorithm ?
Thanks,
Ray
···
On Aug 22, 4:04 pm, Andrea Gavana <andrea.gav...@gmail.com> wrote:
Hi Ray,
On 21 August 2010 05:18, Ray Pasco wrote:
> Thanks Robin, Che and Josh for the tips. Using wx.LIST_AUTOSIZE is the
> ticket. I couldn't find this constant listed in any documentation.
> Josh,
> I'm running on a MSW platform and the autosized columns using the default
> come out perfectly. I've modified [ filehunter.py ] which is based on 2
> ListCtrl's and the attached screen shot image file shows the appearance.
> Maybe your too-narrow-columns problem is either due to the particular font
> or the particular platform implementation. ( Is that redundant due, again,
> to font differences or is this due to a different bug ? )
> The only way I know to precalculate the best minimum column width is the get
> the current font, write all the text strings in one column to wx.MemoryDC's
> and read back each DC's width to find the maximum width to set the
> ListCtrl's column width to. I suspect this is basically how the wxWidget
> does autosizing in the first place. This seems perfectly "do-able" even if
> it's takes a lot of work, meaning CPU cycles, not algorithm complexity.
If you look at the source of UltimateListCtrl in wx.lib.agw, you will
see that this is more or less how it's done. As UltimateListCtrl is
the Python port I made of the generic implementation of wx.ListCtrl,
the 2 should behave more or less in the same way. Windows, however,
has its own native version of wx.ListCtrl (which wxWidgets and
wxPython use), so we don't know exactly what MS is doing with it. The
generic implementation is a fallback for platforms who don't have a
native implementation of wx.ListCtrl (GTK, old versions of MAC).
> This
> strategy seems platform-independent and, perhaps, this is how the basic
> wx.ListCtrl should be modified to correct this bug for good. I certainly
> wouldn't hold my breath waiting for the WxWdget control to get fixed.
You may try and experiment with UltimateListCtrl (which is almost 100%
compatible with wx.ListCtrl) and see if the bus shows there too. If it
shows, a bug report would be nice on both wxWidgets and AGW so that we
can try and fix it somehow.
Andrea, The UltimateListCtrl code has 10,000+ lines in it ! Could
you be a little more specific as to where to look for the column best-
sizing algorithm ?
Thanks,
Ray
···
On Aug 22, 5:06 pm, Josh English <joshua.r.engl...@gmail.com> wrote:
I ran into my problem on a large database application that I can't
seem to reconstruct easily.
I had made some efforts to use ObjectListView but my data was done in
XML, and I never figured out
a decent way to make the interface for the ElementTree.Element object
to work with OLV.
Looking at the code, which is in several places and parts after a
system restore, I have no idea what
happened to the code that gave me grief, but I knew I had to resize
after AUTOSIZE.
I guess I have some catch-up coding to do.
Josh
On Fri, Aug 20, 2010 at 7:18 PM, Ray Pasco <pas...@verizon.net> wrote:
> Thanks Robin, Che and Josh for the tips. Using wx.LIST_AUTOSIZE is the
> ticket. I couldn't find this constant listed in any documentation.
> Josh,
> I'm running on a MSW platform and the autosized columns using the default
> come out perfectly. I've modified [ filehunter.py ] which is based on 2
> ListCtrl's and the attached screen shot image file shows the appearance.
> Maybe your too-narrow-columns problem is either due to the particular font
> or the particular platform implementation. ( Is that redundant due, again,
> to font differences or is this due to a different bug ? )
> The only way I know to precalculate the best minimum column width is the get
> the current font, write all the text strings in one column to wx.MemoryDC's
> and read back each DC's width to find the maximum width to set the
> ListCtrl's column width to. I suspect this is basically how the wxWidget
> does autosizing in the first place. This seems perfectly "do-able" even if
> it's takes a lot of work, meaning CPU cycles, not algorithm complexity. This
> strategy seems platform-independent and, perhaps, this is how the basic
> wx.ListCtrl should be modified to correct this bug for good. I certainly
> wouldn't hold my breath waiting for the WxWdget control to get fixed.
> Ray
> --
> To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
> or visithttp://groups.google.com/group/wxPython-users?hl=en
--
Josh English
Joshua.R.Engl...@gmail.comhttp://joshenglish.livejournal.com
Andrea, The UltimateListCtrl code has 10,000+ lines in it ! Could
you be a little more specific as to where to look for the column best-
sizing algorithm ?
Thanks,
Ray
···
On Aug 22, 5:06 pm, Josh English <joshua.r.engl...@gmail.com> wrote:
I ran into my problem on a large database application that I can't
seem to reconstruct easily.
I had made some efforts to use ObjectListView but my data was done in
XML, and I never figured out
a decent way to make the interface for the ElementTree.Element object
to work with OLV.
Looking at the code, which is in several places and parts after a
system restore, I have no idea what
happened to the code that gave me grief, but I knew I had to resize
after AUTOSIZE.
I guess I have some catch-up coding to do.
Josh
On Fri, Aug 20, 2010 at 7:18 PM, Ray Pasco <pas...@verizon.net> wrote:
> Thanks Robin, Che and Josh for the tips. Using wx.LIST_AUTOSIZE is the
> ticket. I couldn't find this constant listed in any documentation.
> Josh,
> I'm running on a MSW platform and the autosized columns using the default
> come out perfectly. I've modified [ filehunter.py ] which is based on 2
> ListCtrl's and the attached screen shot image file shows the appearance.
> Maybe your too-narrow-columns problem is either due to the particular font
> or the particular platform implementation. ( Is that redundant due, again,
> to font differences or is this due to a different bug ? )
> The only way I know to precalculate the best minimum column width is the get
> the current font, write all the text strings in one column to wx.MemoryDC's
> and read back each DC's width to find the maximum width to set the
> ListCtrl's column width to. I suspect this is basically how the wxWidget
> does autosizing in the first place. This seems perfectly "do-able" even if
> it's takes a lot of work, meaning CPU cycles, not algorithm complexity. This
> strategy seems platform-independent and, perhaps, this is how the basic
> wx.ListCtrl should be modified to correct this bug for good. I certainly
> wouldn't hold my breath waiting for the WxWdget control to get fixed.
> Ray
> --
> To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
> or visithttp://groups.google.com/group/wxPython-users?hl=en
--
Josh English
Joshua.R.Engl...@gmail.comhttp://joshenglish.livejournal.com
On Aug 26, 1:02 pm, WinCrazy <pas...@verizon.net> wrote:
Andrea, The UltimateListCtrl code has 10,000+ lines in it ! Could
you be a little more specific as to where to look for the column best-
sizing algorithm ?
From the SVN version of ULC, the code dealing with column resizing can
be found at line 8351; part of the code dealing with it is
interspersed in the source, but I believe it won't be difficult to
trace it.
On Aug 26, 1:02 pm, WinCrazy <pas...@verizon.net> wrote:
Andrea, The UltimateListCtrl code has 10,000+ lines in it ! Could
you be a little more specific as to where to look for the column best-
sizing algorithm ?
Sorry about the 3 duplicate replies. I was hanging on to the web page
in Firefox for several days by using Firefox's "Session Restore"
feature. When I finally did reply I kept getting a "session timed out"
Firefox error. I thought by pushing the "repost page" [sic] button as
Firefox suggested I would get a freshened page, but I couldn't tell if
this worked or not. So, I pushed it 2 more times... just to be sure.
I finally gave up and reloaded the thread web page manually... and
then posted again.
Ray
···
On Aug 26, 3:10 pm, Andrea Gavana <andrea.gav...@gmail.com> wrote:
On 26 August 2010 21:11, Mike Driscoll wrote:
> On Aug 26, 1:02 pm, WinCrazy <pas...@verizon.net> wrote:
>> Andrea, The UltimateListCtrl code has 10,000+ lines in it ! Could
>> you be a little more specific as to where to look for the column best-
>> sizing algorithm ?
>> Thanks,
>> Ray
> Wow! Why did you send the same message 4 times?
Right, once should have been enough enough
From the SVN version of ULC, the code dealing with column resizing can
be found at line 8351; part of the code dealing with it is
interspersed in the source, but I believe it won't be difficult to
trace it.
On Aug 26, 3:10 pm, Andrea Gavana <andrea.gav...@gmail.com> wrote:
> On 26 August 2010 21:11, Mike Driscoll wrote:
> > On Aug 26, 1:02 pm, WinCrazy <pas...@verizon.net> wrote:
> >> Andrea, The UltimateListCtrl code has 10,000+ lines in it ! Could
> >> you be a little more specific as to where to look for the column best-
> >> sizing algorithm ?
> >> Thanks,
> >> Ray
> > Wow! Why did you send the same message 4 times?
> Right, once should have been enough enough
> From the SVN version of ULC, the code dealing with column resizing can
> be found at line 8351; part of the code dealing with it is
> interspersed in the source, but I believe it won't be difficult to
> trace it.
