Since wx.FileInputStream isn't wrapped, I had to create
my own which creates a subclass of wx.InputStream and passed
it a file object.
wx.InputStream doesn't provide a method to get the size of
the object so I worked it out by seeking to the end and
using tell.
This worked fine in 2.5.2.8, but returns zero in 2.5.3.1.
It looks like it is incorrectly converting the parameters in the call to the file object's seek, (but only on Windows) so it's ending up with (0,0) instead of (0,2). I'll get it fixed.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
It looks like it is incorrectly converting the parameters in the call to the file object's seek, (but only on Windows) so it's ending up with (0,0) instead of (0,2). I'll get it fixed.
Thanks.
Can you also do a double check on the file handle usage?
In my testing, the file handle passed in to the wx.InputStream
constructor never has close called on it.
On the other hand when I make the file a member variable and
add a __del__ method and close there then all is ok.
I don't have a simple sample, but can verify this with lsof on
Unix and Process Explorer from www.sysinternals.com on Windows.
It looks like it is incorrectly converting the parameters in the call to the file object's seek, (but only on Windows) so it's ending up with (0,0) instead of (0,2). I'll get it fixed.
I am experiencing another problem. If I return a .bmp file in an
InputStream via a wx.FSFile in a wx.FileSystemHandler, then a dialog
appears saying "No handler for image type". jpeg and png work fine,
as did bmp in earlier releases.
This only happens on Windows - Linux is fine. It would seem to be
the same bug.
It looks like it is incorrectly converting the parameters in the call to the file object's seek, (but only on Windows) so it's ending up with (0,0) instead of (0,2). I'll get it fixed.
Thanks.
Can you also do a double check on the file handle usage?
In my testing, the file handle passed in to the wx.InputStream
constructor never has close called on it.
A helper class that the wx.InputStream wrapper uses internally was not getting deleted, and it was holing references to the Python file-like object's methods. It is now being destroyed, and so the file object's refcount can now reach zero and so it's __del__ will be called which should call close or whatever is needed for that particular type of object.
Thanks for reporting this.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
It looks like it is incorrectly converting the parameters in the call to the file object's seek, (but only on Windows) so it's ending up with (0,0) instead of (0,2). I'll get it fixed.
I am experiencing another problem. If I return a .bmp file in an
InputStream via a wx.FSFile in a wx.FileSystemHandler, then a dialog
appears saying "No handler for image type". jpeg and png work fine,
as did bmp in earlier releases.
This only happens on Windows - Linux is fine. It would seem to be
the same bug.
Please send me a sample of this problem so I can ensure that the recent changes have fixed it. Thanks
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
I am experiencing another problem. If I return a .bmp file in an
InputStream via a wx.FSFile in a wx.FileSystemHandler, then a dialog
appears saying "No handler for image type". jpeg and png work fine,
as did bmp in earlier releases.
This only happens on Windows - Linux is fine. It would seem to be
the same bug.
Please send me a sample of this problem so I can ensure that the recent changes have fixed it. Thanks
It is too complex to to do in a small sample. However feel free to email
me a build or put it on a website and I can verify if it is fixed. (I
can accept any sized email).