Hi Conal, On 07/12/06, Conal Elliott <[EMAIL PROTECTED]> wrote: > I submitted this bug report at the sourceforge project. Is this a known > problem? Any work-arounds? > > > Running two 'start'ed actions kills the process under ghc and ghci. > Example: > > > > import Graphics.UI.WX > > main = io >> io where io = start (frame [] >> return ())
I'm not sure whether anyone has tried this before, but I would fully expect it not to work for several reasons: * I'm pretty sure that wxHaskell only expects to see a single instance of a wxWidgets wxApp (which is what start boils down to creating, among other things). * In fact, I think the whole point about wxApp is that it encapsulates a process with an event loop for handling GUI events, so the limitation is probably with wxWidgets itself (as it happens, I'm sceptical that what you are trying would work on any common GUI framework, for much the same reason) Work-around will depend on what you are trying to do. You can certainly have multiple top level frames, but they will share the same event loop. This is, by some margin, the easiest approach. If you genuinely want two communicating processes, you most likely need to create two separate executables - let's call them A and B. As part of start-up of A, it spawns B as a forked process, and A abd B communicate via pipes, IP sockets or some other appropriate mechanism. Another wrinkle to watch out for (again, common to most GUIs) is that only one thread should perform all event handling (in practice, this usually ends up being simplest by running all GUI activities in a single thread). Windows is expecially strict about this - X is slightly more permissive, but you are much better off following the 'one GUI thread' rule. Assuming that you have a multi-threaded application, typical design is for GUI to signal other 'worker' threads (which signal back). Again, details are likely to be very application dependent. One final, somewhat unrelated issue: if you are planning to use wxWidgets with GHCi, it is worth knowing that you can actually only issue one start command in a given GHCi session. This is an underlying wxWidgets issue (use of static destructors in C++ code, I believe) which means that wxWidgets can only be restarted by unloading and reloading the wxWidgets DLL. Since GHCi isn't capable of doing this, you basically need to quit and restart a new session. There *is* a workaround for this: use wxWidgets 2.4.2 or earlier, which have a different allocation/deallocation strategy. This is why we continue to support wxWidgets 2.4.2. Regards Jeremy ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
