Hi,
I'm trying to implement the very common behaviour of an application which clones
itself upon opening a new, let's say project. So I created a new app obkect an
run it main loop. This works, however there seem to be window name clashes
between the two instances. The gui is created from xrc and I defined quite some
xml window ids. Is there a way to avoid the name conflicts and still use xml
window ids?
Regards, Christian
Some applications will open new windows, but very few actually literally
clone themselves. If you actually want to replicate literally
everything that your app is doing, you can use any one of the process
starting mechanisms to spawn a new instance of your application (you take
command-line arguments, right?)
On Windows, you can use os.system('start "" <command line>') (be careful
with argument quoting...). On other platforms, you may be able to
os.fork(), though I've never tried it with wxPython applications. May
be an interesting experience.
- Josiah
···
Christian Kristukat <ckkart@hoc.net> wrote:
Hi,
I'm trying to implement the very common behaviour of an application which clones
itself upon opening a new, let's say project. So I created a new app obkect an
run it main loop. This works, however there seem to be window name clashes
between the two instances. The gui is created from xrc and I defined quite some
xml window ids. Is there a way to avoid the name conflicts and still use xml
window ids?
Christian Kristukat wrote:
Hi,
I'm trying to implement the very common behaviour of an application which clones
itself upon opening a new, let's say project. So I created a new app obkect an
run it main loop.
You can only have one wx.App object per process. Creating more than one concurrently or sequentially may or may not work in various situations or on various platforms, but it is not supported at all.
This works, however there seem to be window name clashes
between the two instances. The gui is created from xrc and I defined quite some
xml window ids. Is there a way to avoid the name conflicts and still use xml
window ids?
No, the name to ID mapping is held in a global list, so it will be shared by all instances. This will result in the same ID being used for the same name. What exactly are the problems you are having with this?
···
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Robin Dunn <robin <at> alldunn.com> writes:
Christian Kristukat wrote:
> Hi,
> I'm trying to implement the very common behaviour of an application
> which clones
> itself upon opening a new, let's say project. So I created a new app
> obkect an
> run it main loop.You can only have one wx.App object per process. Creating more than one
concurrently or sequentially may or may not work in various situations
or on various platforms, but it is not supported at all.
I see. On linux it seems to work quite well, though.
> This works, however there seem to be window name clashes
> between the two instances. The gui is created from xrc and I defined quite
> some
> xml window ids. Is there a way to avoid the name conflicts and still use
> xml
> window ids?No, the name to ID mapping is held in a global list, so it will be
shared by all instances. This will result in the same ID being used for
the same name. What exactly are the problems you are having with this?
The controls in the second instance send their events to the first isntance. And
there are some weird errors which I don't understand. Anyway, I will drop that
approach and try what Josiah suggested.
Christian
Josiah Carlson <jcarlson <at> uci.edu> writes:
On Windows, you can use os.system('start "" <command line>') (be careful
with argument quoting...). On other platforms, you may be able to
os.fork(), though I've never tried it with wxPython applications. May
be an interesting experience.
Thanks for your ideas. I tried with os.spawn and it works very well on linux (I
haven't yet tried on windows):
os.spawnl(os.P_NOWAIT, sys.argv[0], sys.argv[0], arg1, arg2, ...)
Christian
One trick with os.spawn* is that the process created will be a child
process of the creating process. If you close the parent process,
depending on your platform, it may close down the child processes (it
does on Windows).
On Windows, using os.system('start "" <command line>') does not create a
child process, so isn't subject to the parent closing issue.
I had suggested os.fork() on non-Windows platforms because it also
doesn't suffer the parent/child process issue.
- Josiah
···
Christian Kristukat <ckkart@hoc.net> wrote:
Josiah Carlson <jcarlson <at> uci.edu> writes:
>
> On Windows, you can use os.system('start "" <command line>') (be careful
> with argument quoting...). On other platforms, you may be able to
> os.fork(), though I've never tried it with wxPython applications. May
> be an interesting experience.Thanks for your ideas. I tried with os.spawn and it works very well on linux (I
haven't yet tried on windows):os.spawnl(os.P_NOWAIT, sys.argv[0], sys.argv[0], arg1, arg2, ...)