[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Olivier Andrieu <oandrieu@n...> |
| Subject: | Re: [Caml-list] LablGTK2: problem w/ GMain.Io |
Hi, > I have a GUI application (the Bantam file manager) that I originally > wrote in LablTk, and have just ported to LablGTK2. I wrote most of the > code on a Slackware 10.1 box using GODI with OCaml 3.08.4 and LablGTK2 > 20040716. The GTK2 version is 2.6.1. After implementing all current > features in GTK and eliminating most of the known serious bugs, I built > and installed the package on my other Linux box, which runs Arch Linux > 0.7.1, with Ocaml-3.09.2, GTK2-2.8.17, and LablGTK2-2.6.0. > > Since I found startup to be a bit slow with GTK, I implemented a 'daemon > mode' for the application. When you start it in daemon mode, the GUI is > initialized, but remains hidden until it receives a '%show' command via > a named pipe. Also, when you 'quit' the application via a keystroke > command or the window manager, it actually only hides the main window. > To actually quit the application in daemon mode, you send a '%quit' > command via the above-mentioned pipe. > > Here's the problem: on the development (Slackware) box, I had the app > running in both normal (GUI shows on startup & is destroyed by quitting) > and daemon modes with no apparent problems. On the second box, normal > mode works fine; the app will also run in daemon mode. But when I > attempt to send a command to the app in daemon mode, I get the following > error message: > > ** (bantam.bin:13244): CRITICAL **: GIOChannel watch: callback raised \ > an exception That's because your callback raised an exception (!). LablGTK traps uncaught exceptions from callbacks instead of re-raising them and exiting the main loop. For signals, there is a user-overridable handler that simply prints the exception name to stderr ; for other types of callbacks (IO watches, timeouts, etc.) you simply get this error message. In your code you should wrap your "watcher" function in a try...with block and print the exception using Printexc.to_string to see what's going wrong. -- Olivier