[wxPython] interim release 2.3.2.1

I have been using the interim release 2.3.2.1 for a while now - but have
just found problem with wximage.Rescale:

W=wxEmptyImage(2,2)
W.SetData("\00"*2*2*3)
W.Rescale(4,4)

crashes with n invalid heap address when releasing the data pointer set in
W.SetData

This does not occur with 2.3.2 prebuilt.

I dont know if this is just my compiler version of 2.3.2.1 to blame or if it
is a genuine bug.

Cheers,
Andrew

···

_____________________________________________________________________
This e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. No communication sent by e-mail to or from Eutechnyx is intended to give rise to contractual or other legal liability, apart from liability which cannot be excluded under English law.

This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Control Centre.

www.eutechnyx.com Eutechnyx Limited. Registered in England No: 2172322

I had some trouble rescaling images in 2.3.2.1. But not crashes, just the image dissapearing!

It only happened with quite big images (scaled from 800x600 up to 7000x5000 pixels). I got around it by using the canvases (which still have the same prob if not used correctly) to only scale the visible rectangle of the image.

Although even this has the image dissapearing when I come to scale up to a 3,000,000 x 2,000,000 pixel image.

I haven’t tried it with 2.3.2. However Delphi’s (our previous tool) can handle 10,000,000 x 10,000,000 pixel scaled images.

Our wxPython app seems to refresh quicker than the delphi app the larger the image is scaled. Ie. scaling of 1000% is very fast in the wxPython app because it seems to be only zooming the rect that is bieng Blit(ed).

Here’s our code for zoom the visible rect:

        # Get the visible rect
        canvas = pnlShape.GetCanvas()
        sw, sh = tuple(pnlShape.GetBoundingBoxMin()) # Shape width, shape height
        cw, ch = canvas.GetClientSize() # Canvas/dc width, canvas/dc height
        size = min(sw, cw), min(sh, ch)
        # Set the scale
        w1, h1 = self.bitmap.GetWidth(), self.bitmap.GetHeight()
        w2, h2 = sw, sh
        scaleX, scaleY = float(w1)/float(w2), float(h1)/float(h2)
        bmpDc = self.bmpDc # This is a wxMemoryDC
        bmpDc.SetUserScale(scaleX, scaleY)
        # Get the position (The top left of the viewing window in the scrolled area)
        t, l = canvas.scale.wPx2px(0,0) # Window pixels to pixels
        # Blit the bitmap to the canvas (DC)
        dc.Blit(t, l, size[0], size[1], bmpDc, t, l)

Have fun and may God Bless You :slight_smile:

Matthew Sherborne

I have been using the interim release 2.3.2.1 for a while now - but have
just found problem with wximage.Rescale:

W=wxEmptyImage(2,2)
W.SetData("\00"*2*2*3)
W.Rescale(4,4)

crashes with n invalid heap address when releasing the data pointer set

in

W.SetData

This does not occur with 2.3.2 prebuilt.

I dont know if this is just my compiler version of 2.3.2.1 to blame or if

it

is a genuine bug.

It doesn't happen here...

···

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

Matthew Sherborne wrote:

I had some trouble rescaling images in 2.3.2.1. But not
crashes, just the image dissapearing! It only happened
with quite big images (scaled from 800x600 up to 7000x5000
pixels). I got around it by using the canvases (which
still have the same prob if not used correctly) to only
scale the visible rectangle of the image. Although even
this has the image dissapearing when I come to scale up to
a 3,000,000 x 2,000,000 pixel image. I haven't tried it
with 2.3.2. However Delphi's (our previous tool) can
handle 10,000,000 x 10,000,000 pixel scaled images.

You're surprised that wxPython isn't able to handle approx.
30 terabytes of image data?!? I'm surprised that Delphi
even pretended to handle it...

I also wonder what you're intending to do with these huge
images. Obviously, if you're upscaling them from something
normal, you're not getting much resolution. (At 10mil x
10mil, each source pixel would be stretched to approx
1250x1250 pixels, larger than the entire source image!)

Jeff Shannon
Technician/programmer
Credit International

It's for Adobe Illustrator work alike that edit's humungous touch sesitive
posters. :slight_smile:

Actually, it doesn't handle that much data because the low res image is only
like 800x600 and we try to only zoom the visible rectangle.

Since my last email I've managed to get wxPython up to 10,000,000 percent
zoom with an 800x400 pixel photo,
but it start's getting iratic after 1,000,000 percent.
Probably my own code though :wink:

At 10,000,000 percent a pixel is wider than the screen! :slight_smile:

wxPython's cool :slight_smile:

GBU
Matthew Sherborne

I understand wxGrid implements scrolling on it's
own, and I can't seem to get the hang of how to
change it.

I'd like to disable horizontal scrolling in classes
derived from wxGrid. How do I do that?

I'm also thinking of hiding both scrollbars.
Possible?

Another possibility for me would be to change
the width of one column so that the grid fits
exactly in the space it has. (The grids live in
a wxFlexGridSizer.)

···

--
Magnus Lyckå, Thinkware AB
Älvans väg 99, SE-907 50 UMEÅ
tel: 070-582 80 65, fax: 070-612 80 65
http://www.thinkware.se/ mailto:magnus@thinkware.se

I understand wxGrid implements scrolling on it's
own, and I can't seem to get the hang of how to
change it.

I'd like to disable horizontal scrolling in classes
derived from wxGrid. How do I do that?

Other than ensure that the window is always wide enough to hold the grid?
There probably isn't a way to do it without mucking around in the C++.

I'm also thinking of hiding both scrollbars.
Possible?

Since wxGrid derives from wxSCrolledWindow the scrollbars will always show
up if the virtual size needed is larger than the physical size of the
window.

···

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

Hm... wouldn't want to do that. :wink: I'm sooo happy to have left C++. :slight_smile:

I've solved my REAL problem, that the grid started scrolling horizontally
when I tabbed into column 2, with this:

     def OnSize(self, event):
         margin = 1
         self.SetColSize(2, event.GetSize()[0] - margin -
                            COL_0_SIZE - COL_1_SIZE)
         self.Refresh()
         event.Skip()

To get rid of the scroll bar I need to increase "margin" to 51!!!
That looks fairly silly.... :frowning: Not a huge problem, but less than
perfect. (This is with 2.3.2(.1?) and Win2k)

But those scroll bars take up some screen estate. Also, I have six
grids, and I would really only need three scroll bars, since one
grid should never scroll, three should only scroll vertically, and
the reamining two are "slaves", sychronized with the three vertically
scrolling grids. (Vertical scroll in two grids cause horizontal scroll
in the two "slaves".) If I could get rid of those nine scroll bars I
don't need I would use my screen estate much better. A typical usage
pattern is to have up to four of these windows visible at the same
time. That's 36 redundant scroll bars.

Yea, yea, I know what you will say: Muck around in the C++...

It won't be a top prio for me, but how much work would it be to allow
scroll bars to be disabled in wxGrid, and would there be an interest
in changing the behaviour in wxWindows? (I prefer not to maintain my
own set of patches...)

And why the silly 50 pixel margin? (You can see this behaviour
in the demos as well.) At least it seems that it should be possible
to lower that margin. I guess the thought is to make the scroll bar
easier to use when the grid is just barely too large, but that ought
to be solved without such a silly side effect. As soon as there is
room for the grid, the scroll bars should disappear, don't you think?

···

At 08:07 2002-03-27 -0800, Robin wrote:

> I'd like to disable horizontal scrolling in classes
> derived from wxGrid. How do I do that?

Other than ensure that the window is always wide enough to hold the grid?
There probably isn't a way to do it without mucking around in the C++.

--
Magnus Lyckå, Thinkware AB
Älvans väg 99, SE-907 50 UMEÅ
tel: 070-582 80 65, fax: 070-612 80 65
http://www.thinkware.se/ mailto:magnus@thinkware.se

And why the silly 50 pixel margin? (You can see this behaviour
in the demos as well.) At least it seems that it should be possible
to lower that margin. I guess the thought is to make the scroll bar
easier to use when the grid is just barely too large, but that ought
to be solved without such a silly side effect. As soon as there is
room for the grid, the scroll bars should disappear, don't you think?

There is the SetMargins method to let you change that. I think the default
margins in 2.3.3 has already been changed to 0.

···

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

Great! Thanks! And it was even in the docs, so I should
be ashamed I even asked... (But with almost 200 methods +
all the inerited ones from wxGrid alone, maybe it's not
so strange that I missed it...slight information overload.)

···

At 10:44 2002-03-27 -0800, you wrote:

> And why the silly 50 pixel margin? (You can see this behaviour
> in the demos as well.) At least it seems that it should be possible
> to lower that margin. I guess the thought is to make the scroll bar
> easier to use when the grid is just barely too large, but that ought
> to be solved without such a silly side effect. As soon as there is
> room for the grid, the scroll bars should disappear, don't you think?

There is the SetMargins method to let you change that. I think the default
margins in 2.3.3 has already been changed to 0.

--
Magnus Lyckå, Thinkware AB
Älvans väg 99, SE-907 50 UMEÅ
tel: 070-582 80 65, fax: 070-612 80 65
http://www.thinkware.se/ mailto:magnus@thinkware.se

There is the SetMargins method to let you change that. I think the default
margins in 2.3.3 has already been changed to 0.

My client got in trouble when I did that (and set column width
in OnSize). He uses 2.3.2b7. The grids looked as pretty as they
should, but when he tried to edit a cell, he got:

txtctrl.SetSelection(0,txtctrl.GetLastPosition())
AttributeError: 'None' object has no attribute 'SetSelection'

The lines up to this say:
                 self.EnableCellEditControl()
                 edtr = self.GetCellEditor(row, col)
                 txtctrl = edtr.GetControl()
                 txtctrl.SetSelection(0,txtctrl.GetLastPosition())
and that always worked before...

Is this a bug in 2.3.2b7? It worked on my computers running 2.3.2.

···

--
Magnus Lyckå, Thinkware AB
Älvans väg 99, SE-907 50 UMEÅ
tel: 070-582 80 65, fax: 070-612 80 65
http://www.thinkware.se/ mailto:magnus@thinkware.se

txtctrl.SetSelection(0,txtctrl.GetLastPosition())
AttributeError: 'None' object has no attribute 'SetSelection'

...

Is this a bug in 2.3.2b7? It worked on my computers running 2.3.2.

Could be, I don't remember. But since 2.3.2b7 was a *beta* it shouldn't be
hard to convince your user to upgrade.

···

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