Gavana, Andrea ha scritto:

Hello Mariano,

I've found a strange behavior in method GetPosition() of wxWindow class ( and derived ). On windows, if you create a window object frame = wx.Frame(None, -1, "TESTING") and you set the position to: frame.SetPosition( (300, 45000) ) If you call method GetPosition, the result will be: frame.GetPosition() >>> (300, 32767)

No bugs here (AFAIK), the maximum limit on Windows in 32767. Whatever greater value you will give to SetPosition() will be truncated to 32767. I may be wrong here, but this is what I remember. Moreover, unless you are using a 15 meters Warner Bros Cinema wide screen, why in the world are you setting 45000 pixels for the y-position? Most of the PCs works at 1280x1024 or, on bigger screens, at 1600x1200 pixels in resolution. It's very uncommon to find higher resolution screens. In this case, where is the point in setting 45000 pixels for the frame position? Andrea. _________________________________________ Andrea Gavana (gavana (AT) kpo (DOT) kz) Reservoir Engineer KPDL 4, Millbank SW1P 3JA London Direct Tel: +44 (0) 20 717 08936 Mobile Tel: +44 (0) 77 487 70534 Fax: +44 (0) 20 717 08900 Web: http://xoomer.virgilio.it/infinity77 --- To unsubscribe, e-mail: wxPython-users-unsubscribe (AT) lists (DOT) wxwidgets.org For additional commands, e-mail: wxPython-users-help (AT) lists (DOT) wxwidgets.org

I must use positions over 32767 because I have an wxScrolledWindow, which contains <n> objects.
Each item has size: width=300, height=120.
If I insert in the scrolledWindow 300 elements, the OnPaint event will draw only the first 273 objects, because the others 274 to 300 will be designed in the same y position: 32767.
And it's wrong.

I can insert in the wxScrolledWindow also 800 elements...
There is another way to do it? ( I don't know... VirtualPosition? )

thx

Kent Quirk ha scritto: Mariano Di Felice wrote: Gavana, Andrea ha scritto:

Hello Mariano,

I've found a strange behavior in method GetPosition() of wxWindow class ( and derived ). On windows, if you create a window object frame = wx.Frame(None, -1, "TESTING") and you set the position to: frame.SetPosition( (300, 45000) ) If you call method GetPosition, the result will be: frame.GetPosition() >>> (300, 32767)

No bugs here (AFAIK), the maximum limit on Windows in 32767. Whatever greater value you will give to SetPosition() will be truncated to 32767. I may be wrong here, but this is what I remember. Moreover, unless you are using a 15 meters Warner Bros Cinema wide screen, why in the world are you setting 45000 pixels for the y-position? Most of the PCs works at 1280x1024 or, on bigger screens, at 1600x1200 pixels in resolution. It's very uncommon to find higher resolution screens. In this case, where is the point in setting 45000 pixels for the frame position? Andrea.

I must use positions over 32767 because I have an wxScrolledWindow, which contains <n> objects.
Each item has size: width=300, height=120.
If I insert in the scrolledWindow 300 elements, the OnPaint event will draw only the first 273 objects, because the others 274 to 300 will be designed in the same y position: 32767.
And it's wrong.

I can insert in the wxScrolledWindow also 800 elements...
There is another way to do it? ( I don't know... VirtualPosition? )

Yow. This seems to me to be unreasonable -- you're essentially saying "I can fit 4 people into my car, why can't I fit 4000 people into it?"

You're going to have to do the extra work to page the elements in and out yourself, and you'll probably have to handle the scroll bar manually too. If I were doing this, I'd create a panel and a separate scroll bar, stuff the objects into a collection, and draw them myself, only drawing objects that actually intersect the visual area.

If these objects are actual controls that have something more than click sensitivity, I'd suggest finding a different UI metaphor -- this one sounds painful to use. If you're just scrolling things so people can see them, maybe you can get away with a FloatCanvas and store positions as floating point objects.

It's nice to have powerful tools, but expecting them to be infinitely powerful is asking too much, I think.

--- To unsubscribe, e-mail: wxPython-users-unsubscribe (AT) lists (DOT) wxwidgets.org For additional commands, e-mail: wxPython-users-help (AT) lists (DOT) wxwidgets.org Oh yes, I think that this is a good idea, but for my restricted developer time, it's impossible for me! :-(
The concept that I don't understand is why for wxPython for Unix set the position in log type, but in windows not.
I would like ovveride SetPosition and GetPosition method, but I've seen that they are stored in a dll ( in unix in a .so file ), and for code doesn't work.

On Fedora Unix, this problem doesn't exists, it works perfectly.
Ever Windows has problems!!! grunch!

bye

At the very least, it shouldn't take much development time to make n
wxSplitterWindows (each with 200 panels) and place them in a wxNotebook
to select which group of 200 is currently visible. That's probably one
of the simpler methods of dealing with the problem.

I will echo the sentiments of others and say that whatever it is that
you're doing, displaying this much information at once really doesn't
sound like a good idea for users.

Tim

Mariano Di Felice wrote:
yes, I think that this is a good idea, but for my restricted
developer time, it's impossible for me! :-(
The concept that I don't understand is why for wxPython for Unix set
the position in log type, but in windows not.
I would like ovveride SetPosition and GetPosition method, but I've
seen that they are stored in a dll ( in unix in a .so file ), and for
code doesn't work.

Fedora Unix, this problem doesn't exists, it works perfectly.
Ever Windows has problems!!! grunch!

bye

Mariano Di Felice wrote:

32767 is the integer limit. Why GetPosition() returns this value? and
why on Unix Platform this problem was not found?

Because Windows grew up on a 16-bit toy operating system and so when
somebody was designing the data structure that holds the screen size it
was natural for them to use a 16-bit value for it because it saves a
couple bytes and who would ever (in that engineer's lifetime anyway)
have a screen with dimensions larger than 32k pixels? The X-Windows
designers were more forward thinking (or more lazy depending on your
point of view) and used 32-bit values for everything.

I must use positions over 32767 because I have an wxScrolledWindow,
which contains <nobjects.
Each item has size: width=300, height=120.
If I insert in the scrolledWindow 300 elements, the Paint event will
draw only the first 273 objects, because the others 274 to 300 will be
designed in the same y position: 32767.
And it's wrong.

However there is a big difference between max screen size and max
virtual size of a window. Unless you are still using a 16-bit version
of Windows the scrollbars (and therefore wx.ScrolledWindow) will be able
to handle size/positions 32k with no problems. See the attached
sample which both draws things on the DC and also positions child
windows over a range of 100k.

Robin Dunn ha scritto:
Mariano Di Felice wrote:
>
>32767 is the integer limit. Why GetPosition() returns this value?
>and why on Unix Platform this problem was not found?
>
Because Windows grew up on a 16-bit toy operating system and so when
somebody was designing the data structure that holds the screen size
it was natural for them to use a 16-bit value for it because it saves
a couple bytes and who would ever (in that engineer's lifetime anyway)
have a screen with dimensions larger than 32k pixels? The X-Windows
designers were more forward thinking (or more lazy depending on your
point of view) and used 32-bit values for everything.
--

>I must use positions over 32767 because I have an wxScrolledWindow,
>which contains <nobjects.
>Each item has size: width=300, height=120.
>If I insert in the scrolledWindow 300 elements, the Paint event
>will draw only the first 273 objects, because the others 274 to 300
>will be designed in the same y position: 32767.
>And it's wrong.
>
However there is a big difference between max screen size and max
virtual size of a window. Unless you are still using a 16-bit version
of Windows the scrollbars (and therefore wx.ScrolledWindow) will be
able to handle size/positions 32k with no problems. See the
attached sample which both draws things on the DC and also positions
child windows over a range of 100k.

import wx
print wx.VERSIN
--
class BigScrolledWindow(wx.ScrolledWindow):
def __init__(self, parent):
wx.ScrolledWindowinit__(self, parent)
self.Bind(wx.EVT_PAINT, Paint)

self.SetVirtualSize((500, 100 * 1024))
self.SetScrollRate(25,25)

for y in xrange(250, self.GetVirtualSize().height, 500):
pos = (25, y)
pnl = wx.Panel(self, -1, pos, (150, 50), style=wx.SIMPLE_BRDER)
wx.StaticText(pnl, -1, str(y), (5,5))
assert pnl.GetPosition() == pos

def Paint(self, evt):
dc = wx.PaintDC(self)
self.PrepareDC(dc)

for y in xrange(0, self.GetVirtualSize().height, 500):
dc.DrawText(str(y), 10, y)

app = wx.App(False)
frm = wx.Frame(None, title="big virtual size")
bsw = BigScrolledWindow(frm)
frm.Show()
app.MainLoop()

To unsubscribe, e-mail: wxPython-users-unsubscribe (AT) lists (DOT) wxwidgets.org
For additional commands, e-mail: wxPython-users-help (AT) lists (DOT) wxwidgets.org
Well, thx very much Robin! :-D
I've seen your example and works!!! HARRY UP!!
Now I adjust your code for my application, and I will write here the result!

bye

Robin Dunn ha scritto:
Mariano Di Felice wrote:
>
>32767 is the integer limit. Why GetPosition() returns this value?
>and why on Unix Platform this problem was not found?
>
Because Windows grew up on a 16-bit toy operating system and so when
somebody was designing the data structure that holds the screen size
it was natural for them to use a 16-bit value for it because it saves
a couple bytes and who would ever (in that engineer's lifetime anyway)
have a screen with dimensions larger than 32k pixels? The X-Windows
designers were more forward thinking (or more lazy depending on your
point of view) and used 32-bit values for everything.
--

>I must use positions over 32767 because I have an wxScrolledWindow,
>which contains <nobjects.
>Each item has size: width=300, height=120.
>If I insert in the scrolledWindow 300 elements, the Paint event
>will draw only the first 273 objects, because the others 274 to 300
>will be designed in the same y position: 32767.
>And it's wrong.
>
However there is a big difference between max screen size and max
virtual size of a window. Unless you are still using a 16-bit version
of Windows the scrollbars (and therefore wx.ScrolledWindow) will be
able to handle size/positions 32k with no problems. See the
attached sample which both draws things on the DC and also positions
child windows over a range of 100k.

import wx
print wx.VERSIN
--
class BigScrolledWindow(wx.ScrolledWindow):
def __init__(self, parent):
wx.ScrolledWindowinit__(self, parent)
self.Bind(wx.EVT_PAINT, Paint)

self.SetVirtualSize((500, 100 * 1024))
self.SetScrollRate(25,25)

for y in xrange(250, self.GetVirtualSize().height, 500):
pos = (25, y)
pnl = wx.Panel(self, -1, pos, (150, 50), style=wx.SIMPLE_BRDER)
wx.StaticText(pnl, -1, str(y), (5,5))
assert pnl.GetPosition() == pos

def Paint(self, evt):
dc = wx.PaintDC(self)
self.PrepareDC(dc)

for y in xrange(0, self.GetVirtualSize().height, 500):
dc.DrawText(str(y), 10, y)

app = wx.App(False)
frm = wx.Frame(None, title="big virtual size")
bsw = BigScrolledWindow(frm)
frm.Show()
app.MainLoop()

To unsubscribe, e-mail: wxPython-users-unsubscribe (AT) lists (DOT) wxwidgets.org
For additional commands, e-mail: wxPython-users-help (AT) lists (DOT) wxwidgets.org
Hi,
The size problem was solved ( it's seems ), but now the Paint
Event don't work well: only some elements are visualized.
If I comment the code SetVirtualSize(), the wxPaintDC draw well, but
only until 32767 y.

Robin Dunn ha scritto:
Mariano Di Felice wrote:
>
>32767 is the integer limit. Why GetPosition() returns this value?
>and why on Unix Platform this problem was not found?
>
Because Windows grew up on a 16-bit toy operating system and so when
somebody was designing the data structure that holds the screen size
it was natural for them to use a 16-bit value for it because it saves
a couple bytes and who would ever (in that engineer's lifetime anyway)
have a screen with dimensions larger than 32k pixels? The X-Windows
designers were more forward thinking (or more lazy depending on your
point of view) and used 32-bit values for everything.
--

>I must use positions over 32767 because I have an wxScrolledWindow,
>which contains <nobjects.
>Each item has size: width=300, height=120.
>If I insert in the scrolledWindow 300 elements, the Paint event
>will draw only the first 273 objects, because the others 274 to 300
>will be designed in the same y position: 32767.
>And it's wrong.
>
However there is a big difference between max screen size and max
virtual size of a window. Unless you are still using a 16-bit version
of Windows the scrollbars (and therefore wx.ScrolledWindow) will be
able to handle size/positions 32k with no problems. See the
attached sample which both draws things on the DC and also positions
child windows over a range of 100k.

import wx
print wx.VERSIN
--
class BigScrolledWindow(wx.ScrolledWindow):
def __init__(self, parent):
wx.ScrolledWindowinit__(self, parent)
self.Bind(wx.EVT_PAINT, Paint)

self.SetVirtualSize((500, 100 * 1024))
self.SetScrollRate(25,25)

for y in xrange(250, self.GetVirtualSize().height, 500):
pos = (25, y)
pnl = wx.Panel(self, -1, pos, (150, 50), style=wx.SIMPLE_BRDER)
wx.StaticText(pnl, -1, str(y), (5,5))
assert pnl.GetPosition() == pos

def Paint(self, evt):
dc = wx.PaintDC(self)
self.PrepareDC(dc)

for y in xrange(0, self.GetVirtualSize().height, 500):
dc.DrawText(str(y), 10, y)

app = wx.App(False)
frm = wx.Frame(None, title="big virtual size")
bsw = BigScrolledWindow(frm)
frm.Show()
app.MainLoop()

To unsubscribe, e-mail: wxPython-users-unsubscribe (AT) lists (DOT) wxwidgets.org
For additional commands, e-mail: wxPython-users-help (AT) lists (DOT) wxwidgets.org
Ah! I have forgotten that the wxPaintDC problem that doesn't work with
SetVirtualSize(), it doesn't works on Windows.
But on Unix it's all K!

BH!

bye

Robin Dunn ha scritto:
Mariano Di Felice wrote:
>
>32767 is the integer limit. Why GetPosition() returns this value?
>and why on Unix Platform this problem was not found?
>
Because Windows grew up on a 16-bit toy operating system and so when
somebody was designing the data structure that holds the screen size
it was natural for them to use a 16-bit value for it because it saves
a couple bytes and who would ever (in that engineer's lifetime anyway)
have a screen with dimensions larger than 32k pixels? The X-Windows
designers were more forward thinking (or more lazy depending on your
point of view) and used 32-bit values for everything.
--

>I must use positions over 32767 because I have an wxScrolledWindow,
>which contains <nobjects.
>Each item has size: width=300, height=120.
>If I insert in the scrolledWindow 300 elements, the Paint event
>will draw only the first 273 objects, because the others 274 to 300
>will be designed in the same y position: 32767.
>And it's wrong.
>
However there is a big difference between max screen size and max
virtual size of a window. Unless you are still using a 16-bit version
of Windows the scrollbars (and therefore wx.ScrolledWindow) will be
able to handle size/positions 32k with no problems. See the
attached sample which both draws things on the DC and also positions
child windows over a range of 100k.

import wx
print wx.VERSIN
--
class BigScrolledWindow(wx.ScrolledWindow):
def __init__(self, parent):
wx.ScrolledWindowinit__(self, parent)
self.Bind(wx.EVT_PAINT, Paint)

self.SetVirtualSize((500, 100 * 1024))
self.SetScrollRate(25,25)

for y in xrange(250, self.GetVirtualSize().height, 500):
pos = (25, y)
pnl = wx.Panel(self, -1, pos, (150, 50), style=wx.SIMPLE_BRDER)
wx.StaticText(pnl, -1, str(y), (5,5))
assert pnl.GetPosition() == pos

def Paint(self, evt):
dc = wx.PaintDC(self)
self.PrepareDC(dc)

for y in xrange(0, self.GetVirtualSize().height, 500):
dc.DrawText(str(y), 10, y)

app = wx.App(False)
frm = wx.Frame(None, title="big virtual size")
bsw = BigScrolledWindow(frm)
frm.Show()
app.MainLoop()

To unsubscribe, e-mail: wxPython-users-unsubscribe (AT) lists (DOT) wxwidgets.org
For additional commands, e-mail: wxPython-users-help (AT) lists (DOT) wxwidgets.org
NADA guys!
It doesn't works!
If I add 300 Items, it will display only 273 items :(
It don't works!!! N

Another question: it's possible with wx.PaintDC draw an existing object
already designed with wxPaintDC?

bye

Mariano Di Felice wrote:

Ah! I have forgotten that the wxPaintDC problem that doesn't work with
SetVirtualSize(), it doesn't works on Windows.
But on Unix it's all K!

It works on XP for me. Which version of Windows are you using? Which
version of wxPython? Does my sample app work for you or not? (The last
panel displayed is at position 102250.) If it does work then you are
doing something wrong in your app.

Mariano Di Felice wrote:

[BTW, there is no reason to quote the entire message you are replying to
when only a small part of it will give context to your message.]

NADA guys!
It doesn't works!
If I add 300 Items, it will display only 273 items :(
It don't works!!! N

Is your virtual size large enough to show all 300 items?

Another question: it's possible with wx.PaintDC draw an existing object
already designed with wxPaintDC?

If your "existing object" is designed to be able to draw itself on any
DC then yes. If it expects to be drawn on its own window then probably not.

Robin Dunn ha scritto:
Mariano Di Felice wrote:
>
>Ah! I have forgotten that the wxPaintDC problem that doesn't work
>with SetVirtualSize(), it doesn't works on Windows.
>But on Unix it's all K!
>
It works on XP for me. Which version of Windows are you using? Which
version of wxPython? Does my sample app work for you or not? (The
last panel displayed is at position 102250.) If it does work then you
are doing something wrong in your app.
--
Yes, your example work very well.
I use Windows XP, wxPython 2.6.1.0 unicode and Python 2.3.5

Robin Dunn ha scritto:
Mariano Di Felice wrote:
>
>Ah! I have forgotten that the wxPaintDC problem that doesn't work
>with SetVirtualSize(), it doesn't works on Windows.
>But on Unix it's all K!
>
It works on XP for me. Which version of Windows are you using? Which
version of wxPython? Does my sample app work for you or not? (The
last panel displayed is at position 102250.) If it does work then you
are doing something wrong in your app.
--
Yes, your example work very well.
I use Windows XP, wxPython 2.6.1.0 unicode and Python 2.3.5

Robin Dunn ha scritto:
Mariano Di Felice wrote:

[BTW, there is no reason to quote the entire message you are replying
to when only a small part of it will give context to your message.]
>
>NADA guys!
>It doesn't works!
>If I add 300 Items, it will display only 273 items :(
>It don't works!!! N
>
Is your virtual size large enough to show all 300 items?
Yes. I ve set virtual size to 650, 120(item's height) * 500(number of items)
>
>
>>
>Another question: it's possible with wx.PaintDC draw an existing
>object already designed with wxPaintDC?

Hi Robin,
your example work because your class draw directly with its Paint
event.

In my app:

class Item(wx.PyControl):
def __init__(self, parent):

wx.EVT_PAINT(Paint)

def Paint(self, event):
dc = wx.PaintDC(self):
dc.BeginDrawing()

dc.EndDrawing()

class List(wx.ScrolledWindow):
def __init__(self, parent):

wx.EVT_SIZE(self, Size)

def Size(self, event):
self.layout()
event.Skip()

def layout(self):
width = self.GetClientSize()[0]
pageh = 120l
self.SetVirtualSize( (width, (pageh*len(self.items))) )
hgap, vgap = 0, 0
pagew = width
textGap = 0
class Pos:
def __init__(self):
self.x = 0l
self.y = 0l
pos = Pos()
rows = 1
for item in self.items:
if ( item is not None ):

item.SetVirtualSize( (pagew, (120*len(self.items))) )
item.SetSize((pagew, pageh))
item.SetPosition((pos.x+hgap, pos.y+vgap))
rows +=1
pos.x = 0

pos.y = pos.y + pageh

else:

pos.x = pos.x + pagew + hgap
if pos.x >= pagew:
pos.x = 0
pos.y = pos.y + pageh + vgap

self.Refresh()
self.SetScrollbars(0, 120, 1, int(round( (pageh*rows)/120 ) ) )

Mariano Di Felice wrote:
Robin Dunn ha scritto:
>Mariano Di Felice wrote:
>>
Ah! I have forgotten that the wxPaintDC problem that doesn't work
with SetVirtualSize(), it doesn't works on Windows.
But on Unix it's all K!
>>
>It works on XP for me. Which version of Windows are you using? Which
>version of wxPython? Does my sample app work for you or not? (The
>last panel displayed is at position 102250.) If it does work then you
>are doing something wrong in your app.
>>
>>
Yes, your example work very well.
I use Windows XP, wxPython 2.6.1.0 unicode and Python 2.3.5

Please try 2.6.3.3 to make sure that this isn't a bug that's already
been fixed.

Mariano Di Felice wrote:
Hi Robin,
your example work because your class draw directly with its Paint
event.

It also creates wxPanels that are children of the wx.ScrolledWindow.
(Those are the items with rectangles around them.)

In my app:

class Item(wx.PyControl):
def __init__(self, parent):

wx.EVT_PAINT(Paint)

def Paint(self, event):
dc = wx.PaintDC(self):
dc.BeginDrawing()

dc.EndDrawing()

class List(wx.ScrolledWindow):
def __init__(self, parent):

wx.EVT_SIZE(self, Size)

def Size(self, event):
self.layout()
event.Skip()

def layout(self):
width = self.GetClientSize()[0]
pageh = 120l
self.SetVirtualSize( (width, (pageh*len(self.items))) )
hgap, vgap = 0, 0
pagew = width
textGap = 0
class Pos:
def __init__(self):
self.x = 0l
self.y = 0l
pos = Pos()

No need for a new class here, wx.Point does exactly what you need here,
plus a lot more.

rows = 1
for item in self.items:
if ( item is not None ):
item.SetVirtualSize( (pagew,
(120*len(self.items))) )

Don't set each item's virtual size (unless they are also scrolled
windows and are really that big.)

item.SetSize((pagew, pageh))
item.SetPosition((pos.x+hgap, pos.y+vgap))
rows +=1
pos.x = 0
pos.y = pos.y + pageh
else:
pos.x = pos.x + pagew + hgap
if pos.x >= pagew:
pos.x = 0
pos.y = pos.y + pageh + vgap
self.Refresh()
self.SetScrollbars(0, 120, 1, int(round( (pageh*rows)/120 ) ) )

Don't use SetScrollbars with SetVirtualSize. SetScrollbars is the "old
way" to set the virtual size and scroll rate. Use SetScrollRate instead.

Robin Dunn ha scritto:
Mariano Di Felice wrote:
>Hi Robin,
>your example work because your class draw directly with its
>Paint event.
>
It also creates wxPanels that are children of the wx.ScrolledWindow.
(Those are the items with rectangles around them.)
No! your example is different: in your code, wx.ScrolledWindow has the
Paint Event and method, but in my code, Item have Paint Event
and method, not List
I've set modification you suggest me, but draw finish every time at Y
pos 32767.
And the update to version wx.Python 2.6.3.3 was no effect, the same result!

I sent you in attached file .py my example of source code for comprise
better.

thx bye

Robin Dunn ha scritto:
Mariano Di Felice wrote:
>Hi Robin,
>your example work because your class draw directly with its
>Paint event.
>
It also creates wxPanels that are children of the wx.ScrolledWindow.
(Those are the items with rectangles around them.)
>
>>
>In my app:
>>
>class Item(wx.PyControl):
>def __init__(self, parent):
>
>
>wx.EVT_PAINT(Paint)
>>
>def Paint(self, event):
>dc = wx.PaintDC(self):
>dc.BeginDrawing()
>
>
>dc.EndDrawing()
>>
>class List(wx.ScrolledWindow):
>def __init__(self, parent):
>
>
>wx.EVT_SIZE(self, Size)
>>
>def Size(self, event):
>self.layout()
>event.Skip()
>>
>def layout(self):
>width = self.GetClientSize()[0]
>pageh = 120l
>self.SetVirtualSize( (width, (pageh*len(self.items))) )
>hgap, vgap = 0, 0
>pagew = width
>textGap = 0
>class Pos:
>def __init__(self):
>self.x = 0l
>self.y = 0l
>pos = Pos()
>
No need for a new class here, wx.Point does exactly what you need
here, plus a lot more.
>
>rows = 1
>for item in self.items:
>if ( item is not None ):
>item.SetVirtualSize( (pagew,
>(120*len(self.items))) )
>
Don't set each item's virtual size (unless they are also scrolled
windows and are really that big.)
>
>
>item.SetSize((pagew, pageh))
>item.SetPosition((pos.x+hgap, pos.y+vgap))
>rows +=1
>pos.x = 0
>pos.y = pos.y + pageh
>else:
>pos.x = pos.x + pagew + hgap
>if pos.x >= pagew:
>pos.x = 0
>pos.y = pos.y + pageh + vgap
>self.Refresh()
>self.SetScrollbars(0, 120, 1, int(round( (pageh*rows)/120 ) ) )
>
Don't use SetScrollbars with SetVirtualSize. SetScrollbars is the
"old way" to set the virtual size and scroll rate. Use SetScrollRate
instead.

Well, perhaps i've found a solution:
The object Item::wx.Window now it's changed in
Item::wx.PyControl, and it's seems work well.
But :-( there is now a new problem:

The size of Item::wx.PyControl is now too small for all object
designed in.
If I do in the constructor

self.SetBestSize( (300, 120) )

it doesn't work! It stop at postion 32767.

It seems that if I specify the best size, Item::wx.PyControl
"tranform" in a wx.Window object
I know that this is an absurd supposition, but I don't know

Any Idea?

thx

The post is:

But it looks like my email client broke the thread on my end; its still
threaded according to the list archive, or maybe the list software
handles threading based on subjects.

- Josiah

Mariano Di Felice <mariano.difelice (AT) gmail (DOT) comwrote:
Josiah Carlson ha scritto:
Mariano Di Felice <mariano.difelice (AT) gmail (DOT) comwrote:

>Any Idea?
>
>
Yeah, the sizer + Hide() and Show() method that I described about a
dozen posts ago in a non-buried thread.

- Josiah
--

? Sorry, I've not understood!
You want setBestSize, hide object and Show()?
Where is the thread you mean?

Mariano Di Felice wrote:
Robin Dunn ha scritto:
>Mariano Di Felice wrote:
Hi Robin,
your example work because your class draw directly with its
Paint event.
>>
>It also creates wxPanels that are children of the wx.ScrolledWindow.
>(Those are the items with rectangles around them.)
No! your example is different: in your code, wx.ScrolledWindow has the
Paint Event and method,

And it also positions child windows on the scrolled window. When I
wrote the sample it wasn't clear if you were drawing on the scrolled
window or positioning child windows, so I did both. Here is the
relevant part of my sample:

for y in xrange(250, self.GetVirtualSize().height, 500):
pos = (25, y)
pnl = wx.Panel(self, -1, pos, (150, 50),
style=wx.SIMPLE_BRDER)
wx.StaticText(pnl, -1, str(y), (5,5))
assert pnl.GetPosition() == pos

but in my code, Item have Paint Event
and method, not List
I've set modification you suggest me, but draw finish every time at Y
pos 32767.
And the update to version wx.Python 2.6.3.3 was no effect, the same result!

I sent you in attached file .py my example of source code for comprise
better.

I found the difference between your code and mine that exposes the bug.
I set the position and size at the same time that the subwindow is
created, you do it later in your layout() method. I changed your sample
so the size/pos is only set at item creation and then the scrolling to
the bottom works fine. If I then try to adjust the position of the last
item in the list then it jumps back to a position of 32767.

I'll see if I can spot where the bug might be happening in the C++ code
(but it's just as likely to be in a Windows API) but as Josiah and
others have mentioned this probably isn't the best UI you could be
designing.