Menus

[Budgie]

I have a requirement for a menu that contains a variable number of menuitems, depending on the data being displayed in the form. To me there would seem to be a couple of different ways of doing this:

• When you know how many items you need, reuse any existing ones, use ⎕WC for any new ones, and ⎕EX for any excess ones no longer required. The trouble is, ⎕DQ refuses to work with anything not already defined when ⎕DQ was executed, i.e. this idea won't work.
• So you predefine a maximum number of menuitems, and set them all as ('Visible' 0). This won't work, because you can't set Visible on a menuitem.

This leaves me in a bit of a quandary. I went back to the help page for MenuBar, and I noticed that I can have as many menubars as I like in a form as long as only one is visible at a time. So if I set up a different MenuBar for when this particular menu has 0 menuitems, 1, 2, ..., a lot, I can get my GUI to work the way I want. The problem, as I see it, is that this is messy, and it only needs three or more menus with varying numbers of menuitems to get completely out of hand.

Surely there must be a better way of doing this?

[StefanoLanzavecchia]

Good morning! It seems to me you might benefit from attaching a callback to the "DropDown" event of the "Menu" object. http://help.dyalog.com/13.0/html/dropdo ... revent.htm
The event fires before the menu is shown to the user and can be used to do just about anything you want to its items, including addition or removal, as far as I remember.
Or have I badly misunderstood your requirements?

[Budgie]

I don't think this will work, because the new menuitems were not defined before the call to ⎕DQ.

Maybe I need to loop (yes, I know, £5 in the swear box) around that call to ⎕DQ. I shall do some more testing.

[paulmansour]

I assume the form is question is modal? If the form is not modal, there should be no problem deleting and adding menu items dynamically. If the form is modal, I would question the design. Generally, modal forms should not have menus.

[Budgie]

No, it's not modal.

[Budgie]

The problem seems to be that the form and the new menu items are in different threads. The state indicator looks like this:

Code: Select all

      )si
·   ·   #.Repunits.BrowserPopulateFactors[13]*
·   ·   #.Repunits.BrowserPopulate[31]
·   ·   ⍎
·   ·   #.CB_NumClient[11]
·   &101 (system thread:1028)
·   #.DRC.Wait[7]
·   [#.[Client]] #.[Client].Wait[6]
&1
·   ⎕DQ
·   #.Repunits.BrowserScreen[60]
·   #.Repunits.Browser[2]
&100

from which you can see that the ⎕DQ is in thread 100, and the new menu items were created in thread 101.

The work-around I had with multiple menubars seemed to work well, but I now need to add yet another menu of varying length, and I don't want to set up 400 or more menubars for one form.

I am mystified as to how to solve this.

[paulmansour]

Ah yes, GUI items created across multiple threads will do that. I suppose you have already considered and rejected the idea of refactoring to avoid having the DQ and the code creating the menus work in different threads, which would be my first choice, not knowing all the other issues.

[Budgie]

Well . . .

I suddenly thought that that might be my problem, so I tried adding a user-defined event to a list object on the screen, and used the callback from that to create the menus. So after all the data has been updated in one thread, I use 0 ⎕NQ with that user-defined event so it creates the new menu items in the same thread as the ⎕DQ, and all of a sudden it works exactly how I wanted it to.

I'm a lot happier now.