Re: [gnome-db] libgda/libgnome questions
- From: Rodrigo Moya <rodrigo gnome-db org>
- To: lorenb starchamber ca
- Cc: gnome-db <gnome-db-list gnome org>
- Subject: Re: [gnome-db] libgda/libgnome questions
- Date: Tue, 12 Aug 2003 14:04:08 +0200
On Tue, 2003-08-12 at 04:19, Loren Bandiera wrote:
> On Mon, 2003-08-11 at 20:19, Rodrigo Moya wrote:
> > GnomeDbConnectionSelector is a subclass of GtkOptionMenu, so you can
> > attach to the "changed" signal on it.
>
> Interesting. From what I know of GtkOptionMenu when you query it from a
> "changed" signal you get back an index number of what the user
> selected.
>
> How do I use that to find out the connection name, user, pass?
>
use:
const gchar *gnome_db_option_menu_get_selection (GtkOptionMenu
*option_menu);
defined in gnome-db-util.h
> > > 2) How do you run a GnomeDbDsnConfigDruid? I can put it into a window
> > > and show it all but then what? How does it get into a loop waiting for
> > > the user? How do I know when it's finished and I can call
> > > gnome_db_dsn_config_druid_get_dsn()
> > >
> > connect to the "finished" signal on it.
>
> I tried to make this work. What I did was make a dialog in Glade and
> put the GnomeDbDsnConfigDruid inside of that. I connected a callback to
> the "finished" signal and call gtk_dialog_run.
>
> In my callback I call gnome_db_dsn_config_druid_get_dsn() and get
> the info. I found I must call gda_config_save_data_source() to save
> it. It would be easier if I could just pass GdaDataSourceInfo *
> to gda_config_save_data_source() instead of passing everything
> individually.
>
yes, we could add a new function to the lib,
gda_config_save_data_source_info, or something.
> Anyway if I try and call gtk_widget_destroy on the dialog at that point
> it crashes my program. I loaded it into GDB and it says:
>
> Starting program: /home/lorenb/Projects/sussen/src/sussen
> [New Thread 16384 (LWP 18207)]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 16384 (LWP 18207)]
> 0x40b639a0 in _int_free () from /lib/libc.so.6
> (gdb) bt
> #0 0x40b639a0 in _int_free () from /lib/libc.so.6
> #1 0x40b627fc in free () from /lib/libc.so.6
> #2 0x40aaa953 in g_free () from /usr/lib/libglib-2.0.so.0
>
> So close and yet so far ;)
>
> I think the problem was partly caused when I called
> gda_config_free_data_source_info on the GdaDataSourceInfo * I
> got back from the DSN config druid.
>
you don't have to free it, since the druid itself frees it after calling
your callback. So it seems that's the problem, a double g_free.
> I commented out and it stopped crashed but the program would just hang
> after the gtk_widget_destroy() call.
>
hmm, no backtrace for that hang?
> > > Is this the correct way to use the widget?
> > >
> > no, it shouldb't be needed. Could you please gdb your program, and
> > obtain a backtrace when it hangs (bt command in (gdb) prompt).
>
> I tried to get a backtrace on that but all I got was
> Cannot find thread 16384: generic error
>
is it compiled with -g?
cheers
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]