wxInitAllImageHandlers called more than once

wxPython Users
1

Hi all,

My comments

1) On my win platform, - win98, Py 2.3.3, wxPy 2.4.2.4- I can call
wxInitAllImageHandlers() several times without any problems;
the several wxInitAllImageHandlers() being in the same module or
spread in different modules. However, I do not know what happens
behind the scene (memory?, ....)

2) I find the remark from Chris Barker very pertinent.
The question in not only relevant for the demo.
If wxInitAllImageHandlers() causes problems when called
several times, what do happen if an application uses a third-party
Python module, that already contains a wxInitAllImageHandlers()
statement? A user is not supposed -fortunately- to inspect all
the modules she/he is using.

I do not completely agree with Jeff Grimmet
... The official line is, it is up to the end developer to make that
call...
Indeed, the user can make the call himself, but, again, how does
she/he know if one another py module creator have already done it?

3) Point 1) tested with the latest wxPy25, no problems.

Jean-Michel Fauth, Switzerland

2

1) On my win platform, - win98, Py 2.3.3, wxPy 2.4.2.4- I can call
wxInitAllImageHandlers() several times without any problems;
the several wxInitAllImageHandlers() being in the same module or
spread in different modules. However, I do not know what happens
behind the scene (memory?, ....)

--- snip ---
I think where this changes is in V2.5. Pertinent is the first section of
the migration docs:

Module Initialization
The import-startup-bootstrap process employed by wxPython was changed such
that wxWindows and the underlying gui toolkit are not initialized until the
wx.App object is created (but before wx.App.OnInit is called.) This was
required because of some changes that were made to the C++ wxApp class.

There are both benefits and potential problems with this change. The
benefits are that you can import wxPython without requiring access to a GUI
(for checking version numbers, etc.) and that in a multi-threaded
environment the thread that creates the app object will now be the GUI
thread instead of the one that imports wxPython. Some potential problems are
that the C++ side of the "stock-objects" (wx.BLUE_PEN, wx.TheColourDatabase,
etc.) are not initialized until the wx.App object is created, so you should
not use them until after you have created your wx.App object. If you do then
an exception will be raised telling you that the C++ object has not bene
initialized yet.

Also, you will probably not be able to do any kind of GUI or bitmap
operation unless you first have created an app object, (even on Windows
where most anything was possible before.)
--- /snip ---

So, in essence, the end-developer is the one creating the wx.App, not the
library, and wx.InitAllImageHandlers() is, while not an actual bitmap
operation, closely tied to the use of bitmaps and images, I think we can
agree.

This probably needs to be explicitly stated in the migration guide,
somewhere.

2) I find the remark from Chris Barker very pertinent.
The question in not only relevant for the demo.
If wxInitAllImageHandlers() causes problems when called
several times, what do happen if an application uses a third-party
Python module, that already contains a wxInitAllImageHandlers()
statement? A user is not supposed -fortunately- to inspect all
the modules she/he is using.

This is where good documentation is going to be important. I *can* assure
you that all of the contributed wx.lib modules will have this taken into
account (either Robin or I have already attended to this).

3

Jean-Michel Fauth wrote:

Hi all,

My comments

1) On my win platform, - win98, Py 2.3.3, wxPy 2.4.2.4- I can call
wxInitAllImageHandlers() several times without any problems;
the several wxInitAllImageHandlers() being in the same module or
spread in different modules. However, I do not know what happens
behind the scene (memory?, ....)

Yes, a new instance of an image handler class is created for each supported image type and added to a list.

2) I find the remark from Chris Barker very pertinent.
The question in not only relevant for the demo.
If wxInitAllImageHandlers() causes problems when called
several times,

No real problems, just annoying warning messages that are logged.

what do happen if an application uses a third-party
Python module, that already contains a wxInitAllImageHandlers()
statement? A user is not supposed -fortunately- to inspect all the modules she/he is using.

I do not completely agree with Jeff Grimmet
... The official line is, it is up to the end developer to make that call...
Indeed, the user can make the call himself, but, again, how does she/he know if one another py module creator have already done it?

What jeff was trying to say is that my preference is that wxInitAllImageHandlers is called by the app, and not a library module. If a module needs more than the default image handlers then it should document that the app should call wxInitAllImageHandlers.

Another possibility is that the lib can try to create a wxImage and if it fails then call wxInitAllImageHandlers.

···

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

4

Jeff Grimmett wrote:

Also, you will probably not be able to do any kind of GUI or bitmap
operation unless you first have created an app object, (even on Windows
where most anything was possible before.)
--- /snip ---

So, in essence, the end-developer is the one creating the wx.App, not the
library, and wx.InitAllImageHandlers() is, while not an actual bitmap
operation, closely tied to the use of bitmaps and images, I think we can
agree.

But creating instances of the handler classes does not need to create a bitmap, so it still won't hurt to call it early...

···

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

5

What jeff was trying to say is that my preference is that
wxInitAllImageHandlers is called by the app, and not a library module.

I guess what Jeff really needs to be saying is that *whatever* image
handlers are required should be ... yadda yadda yadda.

6

But creating instances of the handler classes does not need to create a
bitmap, so it still won't hurt to call it early...

That was what I was fishing for, thanks :slight_smile: