[wxPython] horiz scroll bar thumb's width for styledTextCtrl.

When one creates an instance of a wxStyledTextCtrl the vertical
scroll bar appears and disappears properly and the thumb is sized
appropriately and its size changes appropriately when you resize the
window.

However, the behavio(u)r of the horizontal scroll bar is odd.
The thumb is tiny and resizes only slightly when one widens the
window. It's as if somehow the stc has a preset idea of how wide
the text area will be, and that internal width is rather large, like
2000 characters or so (just a SWAG on that).

The SciTE editor itself seems to do this as well.

Is there some way to fix this? I have spent some time poring over
the various bits of code in wxPython and wxWindows, but before
spending days on this I was wondering if I have missed
something simple.

Anyone know more about this?

···

#--------------------------------
Jeff Sasmor
jeff@sasmor.com

However, the behavio(u)r of the horizontal scroll bar is odd.
The thumb is tiny and resizes only slightly when one widens the
window. It's as if somehow the stc has a preset idea of how wide
the text area will be, and that internal width is rather large, like
2000 characters or so (just a SWAG on that).

Actually, it's 4000.

The SciTE editor itself seems to do this as well.

Is there some way to fix this? I have spent some time poring over
the various bits of code in wxPython and wxWindows, but before
spending days on this I was wondering if I have missed
something simple.

Scintilla doesn't keep track of the length of the longest line, which would
be needed to have a horizontal scrollbar that behaved like the vertical one,
but would be too time consuming on long files.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

[Jeff, Robin]:

> window. It's as if somehow the stc has a preset idea of how wide
> the text area will be, and that internal width is rather large, like
> 2000 characters or so (just a SWAG on that).

Actually, it's 4000.

   As of Scintilla 1.46 there is a SetScrollWidth method so that you can
decide what the assumed width should be. This feature requires cooperation
from the platform layer so may need work in wxSTC.

Scintilla doesn't keep track of the length of the longest line, which

would

be needed to have a horizontal scrollbar that behaved like the vertical

one,

but would be too time consuming on long files.

   With the word wrap feature now working, much of the infrastructure is in
place for being able to calculate the maximum width more quickly. There
would still be a large cost in time or a lesser cost in time with a large
cost in memory of 7 times the document size. As the results of assuming a
particular width are not that bad, its not a high priority to provide
dynamic width calculation.

   There may be better ways to do this than I see. Simple techniques such as
working mostly with the widths of the widest and second widest lines and
only looking at other lines if the widest shrinks thinner than the second
widest do not work when simple changes such as starting or removing a
comment start can affect the widths of many following lines. I can start to
design complex ways of dealing with this but unlike word wrapping, which was
a similar problem, the payoff is not sufficient compared with the benefits
of working on other functions.

   Neil

Well, the version in wxPy seems to be 1.45.
Intellectually, I'd be curious to know why use
4000 as opposed to say, 512. Anyway, just
being able to set the width at all would be great,
I don't see much need for the dynamic approach,
for a text editor, something like 200 chars would be
fine. Especially for editing Python since > 79 chars
is officially deprecated :wink:

Maybe this'll appear in some upcoming version
of wxPython!

···

#--------------------------------
Jeff Sasmor
jeff@sasmor.com
----- Original Message -----
From: "Neil Hodgson" <nhodgson@bigpond.net.au>
To: <wxpython-users@lists.wxwindows.org>
Sent: Thursday, September 05, 2002 8:14 PM
Subject: Re: [wxPython] horiz scroll bar thumb's width for styledTextCtrl.

[Jeff, Robin]:

> window. It's as if somehow the stc has a preset idea of how wide
> the text area will be, and that internal width is rather large, like
> 2000 characters or so (just a SWAG on that).

Actually, it's 4000.

   As of Scintilla 1.46 there is a SetScrollWidth method so that you can
decide what the assumed width should be. This feature requires cooperation
from the platform layer so may need work in wxSTC.

Scintilla doesn't keep track of the length of the longest line, which

would

be needed to have a horizontal scrollbar that behaved like the vertical

one,

but would be too time consuming on long files.

   With the word wrap feature now working, much of the infrastructure is in
place for being able to calculate the maximum width more quickly. There
would still be a large cost in time or a lesser cost in time with a large
cost in memory of 7 times the document size. As the results of assuming a
particular width are not that bad, its not a high priority to provide
dynamic width calculation.

   There may be better ways to do this than I see. Simple techniques such as
working mostly with the widths of the widest and second widest lines and
only looking at other lines if the widest shrinks thinner than the second
widest do not work when simple changes such as starting or removing a
comment start can affect the widths of many following lines. I can start to
design complex ways of dealing with this but unlike word wrapping, which was
a similar problem, the payoff is not sufficient compared with the benefits
of working on other functions.

   Neil

_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwindows.org
http://lists.wxwindows.org/mailman/listinfo/wxpython-users

Hi,

When I close my application, I always get this message with various descriptions of objects. Is this a bad thing? Should I be cleaning up these wxWindows resources in my program somehow?

FWIW, I do occasionally get a wxWindows crash, saying that a particular piece of memory couldn't be read. Usually happens when I'm editing a value in a grid. I don't know if these two things are related.

Robb

I actually get a plethora of these with every wxPython app I have, at least some of them are what I would call "valid" (my data-model objects really do keep pointers to large numbers of wxColours and a few wxFonts, wxMasks, wxPens, wxIcons and wxBitmaps, it's part of their data-model). I almost always have at least one leaked grid-table reference (no idea why that always happens, as it doesn't happen for every grid, just always seems to be one left over), and often a leak to a wxImageList (understandable, I make one a module global). As a note, every app I have tends to have grids.

BTW: I spent about 2 hours this afternoon getting a Win98 box with a bug to give me a traceback (with a novice operator doing the clicking as I tried to guide her over the phone) couldn't get a scrollable console window, so couldn't get the darned traceback to show up because the 20 or so memory leak-message lines were scrolling it off-screen. I could have sworn there was a way to simply switch on scrolling in the command.com window, or use redirection to get stderr to a file, but doesn't seem like there is. Oh well.

Back to the subject: if you're holding references to wxPython objects _after_ the app exits, you should expect these messages. Otherwise there may be a problem, but it's not a critically important error in many cases.

Good luck,
Mike

Robb Shecter wrote:

···

Hi,

When I close my application, I always get this message with various descriptions of objects. Is this a bad thing? Should I be cleaning up these wxWindows resources in my program somehow?

FWIW, I do occasionally get a wxWindows crash, saying that a particular piece of memory couldn't be read. Usually happens when I'm editing a value in a grid. I don't know if these two things are related.

Robb

_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwindows.org
http://lists.wxwindows.org/mailman/listinfo/wxpython-users

--
_______________________________________
   Mike C. Fletcher
   Designer, VR Plumber, Coder
   http://members.rogers.com/mcfletch/

[Mike C. Fletcher]

BTW: I spent about 2 hours this afternoon getting a Win98 box with a bug
to give me a traceback (with a novice operator doing the clicking as I
tried to guide her over the phone) couldn't get a scrollable console
window, so couldn't get the darned traceback to show up because the 20
or so memory leak-message lines were scrolling it off-screen. I could
have sworn there was a way to simply switch on scrolling in the
command.com window, or use redirection to get stderr to a file, but
doesn't seem like there is. Oh well.

Here is something that might help you. On Win98 you can only set the dos
console to a maximum of 50 lines. The default is something like 25 lines.
Sure, it scrolls, but the memory leak messages can easily blow away the
Python traceback message.

So here is an alternative. Run your wxPython app using execfile() from
within the Python shell. For example:

C:\Code\PyCrust>python
Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.

execfile('pycrustapp.py')

C:\Code\PyCrust>

The benefit of this is that the Python shell will throw up the traceback
message and pause. I've found this to be the easiest way to get at pure
Python errors. Hope that helps.

···

--
Patrick K. O'Brien
Orbtech
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------
Web: http://www.orbtech.com/web/pobrien/
Blog: http://www.orbtech.com/blog/pobrien/
Wiki: http://www.orbtech.com/wiki/PatrickOBrien
-----------------------------------------------

In fact, that's what I wound up doing (more or less). I had her fire up Python and run the commands in the main module one-by-one until the error occured. Turns out I'd used a new feature in the latest pre-release version of wxPython which wasn't available in their slightly older version. Upgrading them to the lastest release fixed everything.

BTW: we did set the console to 50 lines eventually, but even then she wasn't actually seeing the traceback (okay, okay, it was more like 80 lines of memory-leak messages :slight_smile: , there's a _lot_ of objects with refs to colours in this app).

Thanks for the tips,
Mike

Patrick K. O'Brien wrote:

[Mike C. Fletcher]

...

So here is an alternative. Run your wxPython app using execfile() from
within the Python shell. For example:

C:\Code\PyCrust>python
Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.

execfile('pycrustapp.py')

...