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 */
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));
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;
eev = NULL;
}
+ popup_up_p++;
+
/* Default is to put the menu at the point (10, 10) in frame */
if (eev)
{
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);
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 */