update.
[chise/xemacs-chise.git.1] / src / menubar-msw.c
index 5e0625a..2cd701d 100644 (file)
@@ -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 */