Обсуждение: Gdk BadMatch with menus
I got a serious problem with GTK, and I have no clue how to handle it. The problem is about menus. When changing the nodes in the tree, the context menu and the Edit menu will be changed; the New menu entry will reflect the current node's abilities. My first implementation destroyed the "New Object" menu item including its submenu, and appended it freshly according to the node. This lead this message on every node change: tk-WARNING **: gtk_menu_attach_to_widget(): menu already attached to GtkMenuItem Gtk-CRITICAL **: file gtkwidget.c: line 1388 (gtk_widget_destroy): assertion `GTK_IS_WIDGET (widget)' failed. Then I changed the coding. Now, I only delete all menu items from the "New Object" submenu, and append new items as appropriate. The mentioned debug messages disappeared. Still, the application will end with the message Gdk-ERROR **: BadMatch (invalid parameter attributes) serial 12530 error_code 8 request_code 59 minor_code 0 Program exited with code 01 when using the context menu (normal menu seems ok). To reproduce this, select "New Object -> Index" on a table. Unfortunately, the app simply exits, so the debugger is useless. I didn't get useful hints from internet search on the topid "BadMatch". Any clues? GTK gurus around? Regards, Andreas
It's rumoured that Andreas Pflug once said: > I got a serious problem with GTK, and I have no clue how to handle it. > The problem is about menus. > > When changing the nodes in the tree, the context menu and the Edit menu > will be changed; the New menu entry will reflect the current node's > abilities. My first implementation destroyed the "New Object" menu item > including its submenu, and appended it freshly according to the node. > This lead this message on every node change: > tk-WARNING **: gtk_menu_attach_to_widget(): menu already attached to > GtkMenuItem > Gtk-CRITICAL **: file gtkwidget.c: line 1388 (gtk_widget_destroy): > assertion `GTK_IS_WIDGET (widget)' failed. > > Then I changed the coding. Now, I only delete all menu items from the > "New Object" submenu, and append new items as appropriate. The > mentioned debug messages disappeared. > Still, the application will end with the message Hi Andreas, Not sure about the error itself, but rather than altering menus dynamically, please enable/disable options. It makes the program much easier for people to learn because they will see where options are whether or not they can actually use them at that point, rather than seeing an ever-changing menu which can leave people thinking 'I know I saw that option, but darned if I can find it now'. Regards, Dave.
Dave Page wrote: >It's rumoured that Andreas Pflug once said: >Hi Andreas, > >Not sure about the error itself, but rather than altering menus >dynamically, please enable/disable options. It makes the program much >easier for people to learn because they will see where options are whether >or not they can actually use them at that point, rather than seeing an >ever-changing menu which can leave people thinking 'I know I saw that >option, but darned if I can find it now'. >Regards, Dave. > > Hi Dave, in general, I agree that options should be enabled/disabled rather than inserted/removed from the menu. In this case, I think it is reasonable to deviate from this rule. The menu item "New Object" will always be there, only the contents of it will change. The reason for this is quite obvious: not possible to create it in this context. The number of object types (well should we call it classes :-) is quite big (total 26 at the moment), leaving only few submenu items selectable. Maybe the menu should be changed to "New Object unter this", because creating a similar object is already performed by "Create". I don't like that nonselectable submenu in pgadmin2. It gets the user to believe that there is possibly a moment where those objects could be created under e.g. "Databases", though this will never happen. In the meantime, I was able to narrow the problem, still leaving me clueless. The problem has nothing to do with the menu modification; I verified this by creating a brand new menu on right click. There seems to be a GTK problem with submenus in popup menus. If the "New Object" item is touched with mouse over, the app will exit as soon as another item that is not in the submenu (refresh, drop, ...) is touched. Regards, Andreas
> -----Original Message----- > From: Andreas Pflug [mailto:Andreas.Pflug@web.de] > Sent: 26 May 2003 09:59 > To: Dave Page; pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] Gdk BadMatch with menus > > > Hi Dave, > > in general, I agree that options should be enabled/disabled > rather than > inserted/removed from the menu. In this case, I think it is > reasonable > to deviate from this rule. The menu item "New Object" will always be > there, only the contents of it will change. The reason for > this is quite > obvious: not possible to create it in this context. > The number of object types (well should we call it classes > :-) is quite > big (total 26 at the moment), leaving only few submenu items > selectable. Maybe the menu should be changed to "New Object > unter this", because > creating a similar object is already performed by "Create". I > don't like > that nonselectable submenu in pgadmin2. It gets the user to > believe that > there is possibly a moment where those objects could be created under > e.g. "Databases", though this will never happen. Not sure I agree with that last statement, but I agree that maybe this one menu should be context-sensitive (it is a context menu after all). > In the meantime, I was able to narrow the problem, still leaving me > clueless. > The problem has nothing to do with the menu modification; I verified > this by creating a brand new menu on right click. There seems to be a > GTK problem with submenus in popup menus. If the "New Object" item is > touched with mouse over, the app will exit as soon as another > item that > is not in the submenu (refresh, drop, ...) is touched. Hmm, perhaps a post to the wx mailing list? I don't know how friendly they are there though... Regards, Dave.