Inconsistencies with menu creation

[Nicholas Eggleston]

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

[Semen Matusovski]

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.

------------------

[Eric Pearson]

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>

[Eric Pearson]

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>

[Chris Boss]

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.



------------------

[jcfuller]

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

James


------------------

[Knuth Konrad]

Nicholas,

have a look at http://www.iarchitect.com/tabs.htm 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.

Knuth

------------------

[Nicholas Eggleston]

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
approach.

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

Nick

------------------