Since it works perfectly fine for GNU/Linux and Mac OSX 10.4, but not on Win32
(tested on more than 1 box), I dare say that the index in the ImageList is
working as expected.
The order in the ImageList is the same as the tab order, because each tab
inserts and remove its own image upon activation/deactivation.
Best regards,
Frank
···
On Thursday 20 September 2007 18:36:49 Robin Dunn wrote:
Frank Aune wrote:
> Could anyone theorize or think out aloud what might be making these
> rather strange effects Im experiencing on Win32, based on the provided
> info?
It sounds to me like you are using the wrong index for the image. Are
you sure that the return value of self.il.Add is the same as tabOrder?
Would it possible to add all your images to the image list at the
beginning and save their indexes for later use?
Could anyone theorize or think out aloud what might be making these
rather strange effects Im experiencing on Win32, based on the provided
info?
It sounds to me like you are using the wrong index for the image. Are
you sure that the return value of self.il.Add is the same as tabOrder?
Would it possible to add all your images to the image list at the
beginning and save their indexes for later use?
Since it works perfectly fine for GNU/Linux and Mac OSX 10.4, but not on Win32 (tested on more than 1 box), I dare say that the index in the ImageList is working as expected.
Not necessarily. On Linux and Mac the generic version of the wxImageList is used, on Windows it is a wrapper around the native ImageList. So you may just be accidentally exploiting a bug in the generic image list.
The order in the ImageList is the same as the tab order, because each tab inserts and remove its own image upon activation/deactivation.
You should try comparing the return value from ImageList.Add with with the index you are using to check for sure.
···
On Thursday 20 September 2007 18:36:49 Robin Dunn wrote:
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Frank Aune wrote:
> Since it works perfectly fine for GNU/Linux and Mac OSX 10.4, but not on
> Win32 (tested on more than 1 box), I dare say that the index in the
> ImageList is working as expected.
Not necessarily. On Linux and Mac the generic version of the
wxImageList is used, on Windows it is a wrapper around the native
ImageList. So you may just be accidentally exploiting a bug in the
generic image list.
Since wx is a cross-plattform widget toolkit, shouldnt the behaviour ideally
be the same on each plattform?
Whats the reason you think the Win32 wrapper is behaving correctly, while the
GNU/Linux and Mac OSX version is the wrong one?
> The order in the ImageList is the same as the tab order, because each tab
> inserts and remove its own image upon activation/deactivation.
You should try comparing the return value from ImageList.Add with with
the index you are using to check for sure.
Good idea, up until now I just inserted and removed the image in the ImageList
depending on the tab order, but I might just as well use the returnvalue of
Add() since its available in the class anyway.
Best regards,
Frank
···
On Friday 21 September 2007 20:46:59 Robin Dunn wrote:
Ok, I tried this but obviously I cant use the return value from Add() as an ImageList index reference, because when a tab in the middle is removed it will change the index order of the imagelist and I end up trying to remove an image outside the list.
If I have the following ImageList:
index | img
0 a
1 b
2 c
3 d
And I run Remove(2), I will remove c and d will take its place in index 2, correct? Because this is the behavior I'm experiencing on GNU/Linux and Mac OSX. But clearly something else is happening on Win32.
Can it be possible that when running Remove(2) on Win32, image d still resides in index 3? Does it matter that some of the images are exactly the same?
I'm sorry for all these questions I could test for myself, but I don't have access to a Win32 plattform, so I'm trying to understand as much as I can before I can get access to one.
Best regards,
Frank
···
Den 21. sep. 2007 kl. 21.00 skrev Frank Aune:
You should try comparing the return value from ImageList.Add with with
the index you are using to check for sure.
Good idea, up until now I just inserted and removed the image in the ImageList
depending on the tab order, but I might just as well use the returnvalue of
Add() since its available in the class anyway.
Since it works perfectly fine for GNU/Linux and Mac OSX 10.4, but not on
Win32 (tested on more than 1 box), I dare say that the index in the
ImageList is working as expected.
Not necessarily. On Linux and Mac the generic version of the
wxImageList is used, on Windows it is a wrapper around the native
ImageList. So you may just be accidentally exploiting a bug in the
generic image list.
Since wx is a cross-plattform widget toolkit, shouldnt the behaviour ideally be the same on each plattform?
Ideally, yes. But here in reality we live in a non-ideal world.
Whats the reason you think the Win32 wrapper is behaving correctly, while the GNU/Linux and Mac OSX version is the wrong one?
Because the generic one was modeled after the Win32 image list, and was intended to be compatible with it.
···
On Friday 21 September 2007 20:46:59 Robin Dunn wrote:
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
You should try comparing the return value from ImageList.Add with with
the index you are using to check for sure.
Good idea, up until now I just inserted and removed the image in the ImageList
depending on the tab order, but I might just as well use the returnvalue of
Add() since its available in the class anyway.
Ok, I tried this but obviously I cant use the return value from Add() as an ImageList index reference, because when a tab in the middle is removed it will change the index order of the imagelist and I end up trying to remove an image outside the list.
If I have the following ImageList:
index | img
0 a
1 b
2 c
3 d
And I run Remove(2), I will remove c and d will take its place in index 2, correct? Because this is the behavior I'm experiencing on GNU/Linux and Mac OSX. But clearly something else is happening on Win32.
Can it be possible that when running Remove(2) on Win32, image d still resides in index 3?
Possibly.
Does it matter that some of the images are exactly the same?
No, it won't care (other than memory use) if you have the same image in there multiple times.
I'm sorry for all these questions I could test for myself, but I don't have access to a Win32 plattform, so I'm trying to understand as much as I can before I can get access to one.
You best bet I think is to preload the images in the image list (if you know what they will be and can access them before hand) and then save and reuse the indexes as needed. If you don't know them before you need them then I would build a simple abstraction between the image list and your other code, where you can map images by some name. When you ask for an image index by name if it is already there then you return the existing index, if it is not there then you add it to the image list and return the new index.
···
Den 21. sep. 2007 kl. 21.00 skrev Frank Aune:
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
I've got concept-code demonstrating the effect I'm experiencing on Win32, but
not on GNU/Linux or Mac OSX, if someone is interested. Just send me a message
from a working email adress and I'll send it right over.
I still believe this is a bug in the implementation of wx.ImageList on Win32.
Best regards,
Frank Aune
···
On Saturday 22 September 2007 01:11:22 Robin Dunn wrote:
You best bet I think is to preload the images in the image list (if you
know what they will be and can access them before hand) and then save
and reuse the indexes as needed. If you don't know them before you need
them then I would build a simple abstraction between the image list and
your other code, where you can map images by some name. When you ask
for an image index by name if it is already there then you return the
existing index, if it is not there then you add it to the image list and
return the new index.
On Saturday 22 September 2007 01:11:22 Robin Dunn wrote:
You best bet I think is to preload the images in the image list (if you
know what they will be and can access them before hand) and then save
and reuse the indexes as needed. If you don't know them before you need
them then I would build a simple abstraction between the image list and
your other code, where you can map images by some name. When you ask
for an image index by name if it is already there then you return the
existing index, if it is not there then you add it to the image list and
return the new index.
Hi Robin and group,
I've got concept-code demonstrating the effect I'm experiencing on Win32, but not on GNU/Linux or Mac OSX, if someone is interested. Just send me a message from a working email adress and I'll send it right over.
I still believe this is a bug in the implementation of wx.ImageList on Win32.
If it's just a few K then send it to the list as message attachments, that way if I don't have time to look at it somebody else might.
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Actually I got hold of a win32 box today, and I found the reason for the
plattform difference:
On GNU/Linux and Mac OSX a notebook image follows the originally assigned
notebook tab regardless, even if you afterwards remove/add other tabs.
On win32 OTOH, if you set image X for notebook tab Y, image X will always be
assigned to the tab occupying position Y - even if you add new tabs before
the original tab in Y and thus "push" it further to the right.
To recap for win32:
A new tab inserted in position Y will automatically be assigned the image
which the previous tab in position Y had.
A tab removed from position Y, will cause the last tab in the notebook to
loose its picture. The reason is that my code remove both the tab and the
image from the ImageList for position Y, but wx insists that the last tab in
the notebook should have the originally defined image in the ImageList. But
since the ImageList now is 1 image shorter (due to the tab removal), wx does
not have a reference to the originally defined image for the last tab and
thus display no image.
Solution:
I tried remapping the images after removing a tab on win32, and then it works
exactly as it does on GNU/Linux and Mac OSX.
I still think this is a bug, but I guess its debatable if the GNU/Linux and
Mac OSX or Win32 behavior is the desired one
···
On Friday 28 September 2007 20:19:38 Robin Dunn wrote:
Frank Aune wrote:
> I still believe this is a bug in the implementation of wx.ImageList on
> Win32.
If it's just a few K then send it to the list as message attachments,
that way if I don't have time to look at it somebody else might.
I still believe this is a bug in the implementation of wx.ImageList on
Win32.
If it's just a few K then send it to the list as message attachments,
that way if I don't have time to look at it somebody else might.
Actually I got hold of a win32 box today, and I found the reason for the plattform difference:
On GNU/Linux and Mac OSX a notebook image follows the originally assigned notebook tab regardless, even if you afterwards remove/add other tabs.
On win32 OTOH, if you set image X for notebook tab Y, image X will always be assigned to the tab occupying position Y - even if you add new tabs before the original tab in Y and thus "push" it further to the right.
So even if you don't add/remove images from the image list, the notebook images don't stick with the tabs?
To recap for win32:
A new tab inserted in position Y will automatically be assigned the image which the previous tab in position Y had.
A tab removed from position Y, will cause the last tab in the notebook to loose its picture. The reason is that my code remove both the tab and the image from the ImageList for position Y, but wx insists that the last tab in the notebook should have the originally defined image in the ImageList. But since the ImageList now is 1 image shorter (due to the tab removal), wx does not have a reference to the originally defined image for the last tab and thus display no image.
Ok, this sounds a bug in wxNotebook that should be reported. Please enter a bug report at SourceForge for it, using a category of "wxMSW specific".
···
On Friday 28 September 2007 20:19:38 Robin Dunn wrote:
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
