No announcement yet.

Inconsistencies with menu creation

  • Filter
  • Time
  • Show
Clear All
new posts

  • Inconsistencies with menu creation

    I've been writing an application using PBDLL6.0 that creates a
    menu with approximately 3200 menu options. A bit over the top I
    know but it is to replace our DOS based Ms Basic menu.

    Now the trouble that I'm experiencing is the display of the menu.
    With no other applications running the program works fine, but if
    I run other applications such as executing the program from
    within the PB/DLL editor the number of menu options that are
    displayed is considerably less. And for those menu options that
    do get created, the functionality behind the menu option does
    not run properly. In the majority of cases the menu option will
    shell to our existing DOS applications.

    Has anyone out there experienced problems with large menus and
    in particular when running concurrently with other applications
    such as Lotus Notes and MS Word.

    I'm developing on WinNT 4.0 (SP4).

    Many thanks

    Nicholas Eggleston

  • #2
    Nicholas -
    can I ask you, how many apps did you saw with such big menu ?
    It's simply not comfortable for users.
    There are many methods to decrease numbers of items.
    Look, for example, at MS Word. Tools - Options.



    • #3
      Off the top of my head it sounds like you're running low on resources. Are you checking for errors as the menus are created?

      Perfect Sync: Perfect Sync Development Tools
      Email: mailto:[email protected][email protected]</A>

      "Not my circus, not my monkeys."


      • #4
        Another thought... If it is a resource problem, you might want to check out the WM_INITMENUPOPUP message. Windows sends that message to your program whenever a submenu is about to be displayed, so you might be able to create a system where the pulldowns are created "dynamically". In other words, most of the time only the top-level menu bar would really exist. When the user selects an item from the top-level menu your program could detect WM_INITMENUPOPUP and quickly create the necessary pulldown. Then if a menu below that is selected, create that, and so on.

        You could also keep track of what has been created, and destroy submenus when they are no longer needed. For example, if the user selects the File submenu and your program creates it, and then the user selects the Edit submenu, you could destroy the File submenu. If you create a nice "tight" routine there would be virtually no limit to the size of the menu system that you could create, unless a huge submenu had a huge submenu which had a huge submenu, etc.

        -- Eric

        Perfect Sync: Perfect Sync Development Tools
        Email: mailto:[email protected][email protected]</A>

        "Not my circus, not my monkeys."


        • #5
          Definitely sounds like you are pushing Windows beyond its limits, since most apps would never even come close to that many menu items.

          Instead you may want to use Button controls as the top level of your Menu system and then create your own Popup menus as needed and then destroy them when they are not used.

          Chris Boss
          Computer Workshop
          Developer of "EZGUI"


          • #6

            For that many menu items I suggest using a Treeview control.




            • #7

              have a look at and search for the MultiEdit example. There they provide an interesting approach to solve the problem of displaying tons of categorized options to a user.




              • #8
                Thanks for the replies. I appreciate the effort that each
                person has made. It appears that after a quick test, I am indeed
                running out of resources. So I'm going to have to re-think my

                I realise that the app is a bit over the top with that many menu
                items but I had to create the program with a similar concept
                to that of our pre-existing menu.

                Best regards