X-Git-Url: http://git.chise.org/gitweb/?p=chise%2Fxemacs-chise.git.1;a=blobdiff_plain;f=src%2Fmenubar-msw.c;h=2cd701d419ac14cf6296e59dc50c950989858269;hp=5e0625a7c09d47cacbbdd6f0df4f0bf8e536e3e0;hb=3f46c5336cd2a7c388b4ebba6b3e575e2b71cc86;hpb=59eec5f21669e81977b5b1fe9bf717cab49cf7fb diff --git a/src/menubar-msw.c b/src/menubar-msw.c index 5e0625a..2cd701d 100644 --- a/src/menubar-msw.c +++ b/src/menubar-msw.c @@ -678,12 +678,12 @@ prune_menubar (struct frame *f) if (menubar == NULL) return; - /* #### If a filter function has set desc to Qnil, this abort() + /* #### If a filter function has set desc to Qnil, this ABORT() triggers. To resolve, we must prevent filters explicitly from mangling with the active menu. In apply_filter probably? Is copy-tree on the whole menu too expensive? */ if (NILP (desc)) - /* abort(); */ + /* ABORT(); */ return; GCPRO1 (desc); /* just to be safe -- see above */ @@ -737,7 +737,7 @@ unsafe_handle_wm_initmenupopup_1 (HMENU menu, struct frame *f) Lisp_Object path, desc; struct gcpro gcpro1; - + /* Find which guy is going to explode */ path = Fgethash (hmenu_to_lisp_object (menu), current_hash_table, Qunbound); assert (!UNBOUNDP (path)); @@ -821,8 +821,7 @@ mswindows_handle_wm_command (struct frame *f, WORD id) breaks customize because the misc_event gets eval'ed in some circumstances. Don't change it back unless you can fix the customize problem also.*/ - enqueue_misc_user_event (frame, fn, arg); - mswindows_enqueue_magic_event (NULL, XM_BUMPQUEUE); + mswindows_enqueue_misc_user_event (frame, fn, arg); UNGCPRO; /* data */ return Qt; @@ -916,6 +915,8 @@ mswindows_popup_menu (Lisp_Object menu_desc, Lisp_Object event) eev = NULL; } + popup_up_p++; + /* Default is to put the menu at the point (10, 10) in frame */ if (eev) { @@ -931,6 +932,8 @@ mswindows_popup_menu (Lisp_Object menu_desc, Lisp_Object event) CHECK_CONS (menu_desc); CHECK_STRING (XCAR (menu_desc)); + menu_cleanup (f); + current_menudesc = menu_desc; current_hash_table = make_lisp_hash_table (10, HASH_TABLE_NON_WEAK, HASH_TABLE_EQUAL); @@ -949,7 +952,15 @@ mswindows_popup_menu (Lisp_Object menu_desc, Lisp_Object event) DestroyMenu (menu); - /* Signal a signal if caught by Track...() modal loop */ + /* A WM_COMMAND is not issued until TrackPopupMenu returns. This + makes setting popup_up_p fairly pointless since we cannot keep + the menu up and dispatch events. Furthermore, we seem to have + little control over what happens to the menu when we click. */ + popup_up_p--; + + /* Signal a signal if caught by Track...() modal loop. */ + /* I think this is pointless, the code hasn't actually put us in a + modal loop at this time -- andyp. */ mswindows_unmodalize_signal_maybe (); /* This is probably the only real reason for failure */