The last testcase (V_06) shows that the two failing testcases have no bugs in syntax (V_05_A, B). In V_06 - I commented out a previous submenu section (submenu "Base Action High Level") - to make room for the submenu items in V_05_A, B - to prove the syntax is OK.

Thus : The two failing testcases - appear to fail - due to a size limitation of custom menus in SE (and not a SE code syntax problem).

In summary:

The SE custom menu in testcase V_04 loads OK - and actually works (when the macros are loaded).

NOTE : I did not attach the SE Macro module - that has the commands used by the menus. The macros work just fine. Its the menu size problem that is the issue (herein).

Near as I can tell....

The SE custom menu in testcase V_05_A - Fails the load process - due to a menu size limitation.

The SE custom menu in testcase V_05_B - Fails the load process - due to a menu size limitation.

I have found some other issues with custom menus - but this post is focused on what appears to be a size limitation. The failing testcases (attached) - appear to be one submenu item too many (right on the cusp of the failure point).

Is there a size limitation? - and can this be fixed - so that SE can perform like any other Windows application (ie; Large scale menus are no problem).

When any SE custom menus get around this size - a massive failure canoccur in the SE GUI - which I will post in another topic (under SE V19RC2 beta testing).

The total number of low level SE menu items - at the bottom - level 4 - is 388.

This would be a nominal cardinality - between 100->1000 menu items.

Note : A full menu for the complete tag lexicon I am using - is around 530 items (at present).

Note : The SE menu modules (such as that attached) - allow less SE toolbar modules to be needed (for various code domains) - as well as provide a handy reference - to the software artifact tag lexicon (ie; the dictionary of tags I am using for some corporate/government enterprize level clients).

We use different tools than Slickedit - to maintain tags and generate code - using automated code generators - for different environments.

... in this context ....

The attached SE menu size testcase module (..V_07..) - and some screen shots - can help replicate some of the SE module load/unload issues we are seeing with the SE V19 application.

Some of the harder to replicate errors I am seeing - in the SE V19 beta - seem to be related to nominal cardinality issues - rather than specificSE menu load issues (ie; They occur in other SE code domains - such as macros or toolbars - not just menu items).

Trivial cardinality being 1->10, 10->100 : and nominal being 100->100code artifacts - in various code domains.

If the fixed SE menu limit could be increased - in the final V19 release : The attached SE Module (in my SE Module library set) - is an example use case of why.

NOTE : What ever the fixed SE menu limit is : When hit - the SE macro loading process - could post a message box - indicating that the module loaded OK - but the menu was truncated due to SE menu cardinality limits.

I have attached a screen shot of the truncated module - to show the difference between - the (a) attached SE menu module - and (b) what actually gets created in the SE environment (for SE V19 RC4).

As can be seen in the screen shot - the following menu sections arenot created - even though the SE module defines them.

CCV_BitCCV_OOPCCV_State

If the SE menu item limit - could be increased to 512 items (100->1000 range of cardinality) - that would go a long way in having formal grep tags in a working lexicon (available) - without taking up the screen real estate in Toolbars.

A final SE V19 Release of 1000 items - would go a long way in helping SE users (such as myself) - in pushing the limits of - code tag lexicon based - code visibility tool features (such as herein - for the SE application).

Attachment [4] - is an example of a large SE custom menu - with 189 submenuitems - and 384 menu items (at the bottom level - where grep macros are called).So Attachment [4] contains 384 grep operations - most of which use the lexiconmentioned above.

Screenshot [1,2] - show the SE RC5 error - whereby : SE loads the attachedmodule with no error message - but exhibits an error when the MDI Menu item -tries to display the menu.

------------ Test replication -----------------------------

Load the attached SE module (attached item [4]) - and use;

SE MDI Menu -> Macro -> Menus : _mdi_menu (Open)

To create a "Code Map" SE MDI Menu item - and execute the;

ccv_pop_SEM_01_Base_srh_mnu()

.. macro - defined in the attached SE Module (item [4] above).

When you execute the MDI Menu item "Code Map" - you should get thesame error message as the screenshot [2] (attached).

------------ Bad Behavior ---------------------------------

After the error message comes up - you can look for the largemenu item via;

SE MDI Menu -> Macro -> Menus : [look for _ccv_SEM_01_Base_srh_mnu]

As it turns out, the large SE custom menu was never really loaded -during the SE module load process - of the attached SE module (item [4]).

THEN:(4) SE should display a 'Menu Exceeds Maximum Size' error message - AND(5) The module should be rejected for loading - AND(6) The module should have no residue in the SE State space - AND(7) The module should NOT show up in the module list

Note that (7) above - is a problem with the attached screenshot [1] - wherethe module DOES show up

------------ Alternate Desired Behavior -------------------

[1] The module shows up in the SE user module list - but its colored red.[2] The SE module is presented in a buffer[3] The cursor is at the line - where the last VALID menu item is.[4] The first menu item (text line) to exceed the size limit - is colored in red.

------------ Summary --------------------------------------

Slickedit is the world's greatest programming tool - because software engineers can use it to push the envelope of programming productivity (excuse the soap box approach). In screenshot [3] (attached) - an example of some pragmatic experimentation - with Slickedit and language independent code visibility of software patterns (from low, high to holistic system designs) - is attached to show why someone would want to use large custom menus in Slickedit.

.... in this experimental - pushing the envelope context ....

The Alternate Desired Behavior would be the best solution.

The key point - is that any menu size limit - should be detected by Slickedit - and flagged right away.