Author Topic: Title : SEV12 RC1 : _menu{} works well with large cardinality menus (~ 500 subme  (Read 2258 times)

PurdueEEGrad

  • Senior Community Member
  • Posts: 115
  • Hero Points: -17
To the SlickEdit development team:

I just wanted to report on a fixed bug that has been outstanding since 2014 in Slickedit.

I just tested SEV21 - RC1 - and this version of SE worked 'for the first time' loading
a large menu definition in slickedit (that did not work in Se 2014, SE 2015).

Previously, I had tried to load large custom defined floating menus in SE.

This is the first time (2016.09.13) - that I was able to code a single floating
menu of large size - and have it load as a SE module - without breaking SE.

I use a grep based methodology a lot - and using large menus (see attached screen shot)
saves me from the alternative - which is many, many toolbars and toolbar buttons (where
each button can execute a grep search command for some specific 'tag' like '_str' for
a string.

I have attached a screen shot of the floating menu - to show how complex some
of my needs are.

The SE module source file metrics - for this menu (see attached screenshot) are;

[1] Size = 275 KB
[2] Line count = 4135
[3] SE submenu count = 445

Its good to see Slickedit handle floating menus of this size with no problem :-)

I can finally do some R&D work with software patterns - that require a lexicon
of 'grep tags' - to increase code visibility of well know artifacts in software code.

I can not thank the SlickEdit team enough - for such a great product!!!!

Dan

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2899
  • Hero Points: 153
Would a dialog that had multiple dynamic tree controls be easier?  Sort of how the open dialog works on the mac. 

The reason I ask is that you can save and restore those results, so subsequent uses of the same item can be easily performed, where the menu method requires you to navigate each menu every time.

PurdueEEGrad

  • Senior Community Member
  • Posts: 115
  • Hero Points: -17
Actually that's an excellent idea - to compliment my current use of large size menus.

There are two use cases. One for my current use - and one to answer your suggestion.

My current use case - of large scale menus - is two fold. (A) To navigate a complex pattern
lexicon based on a '_tag' methodology. The other (B) is to quickly do a grep for some _tag
in the lexicon - that is outside the current code domain I am focused on. Thus if I am coding
some GUI code - and need to grep a tag in networks (socket, port, server target address) - I
can use the large scale menu (which is basically a lexicon dictionary) - to quickly find the grep
tag I need - and then grep in file, project or workspace scope.

Your excellent suggestion can compliment that use case with another use case of code _tag
lexicons. The use case is a (2) _tag lexicon reference window. My use, in this case, would require a dockable
tabbed window (see attached screenshot) - rather than a dialog box. The tabs are variable and hold dynamic
tree controls filled out via XML files - that hold subsets of the overall _tag lexicon. Thus one tab could be GUI,
while another tab could be State (state space lexicon).

The attached screen shot - shows the 'Project window' - that has tabs for Projects, Defs, Class, Symbols and Open.
A similar GUI construct - containing an expandable, collapsible tree in each tab - would work for me. I would need
to be able to 'Name' each tab (such as State, GUI, Event, Network, etc) - and then edit each tree manually - in addition
to import/export of the tree using a XML based file storage/persistance paradigm.

The second use case could be used for 'grep actions' - at the nodes of the dynamic tree leaves. But other
action types could be programmed (using SE Macros) - to execute other types of actions - or even a set of
actions.

This excellent suggestion of yours - would, in my mind (for the (2) use case above) require a somewhat complex
GUI construct. That construct would be the multi-tabbed window (see atttached screen shot) where each tab
window - contains a separate dynamic tree (ie; expandable and collapsible hierarchy - based on an XML file
to be loaded in each tab window).

Because of the implementation complexity (a tabbed window construct -VS- a simple dialog with a dynamic tree) - I
would consider writing my own plug for SE in C++ (which I have never done before).

In summation : An alternate third use case (3) - could use a single persistent dialog - that would allow a user to
have the dialog box (with a single big dynamic tree). In this use case the tree leaves are 'actions' programmed by
the user. My current use would be simple single shot grep actions on _tag targets in (A) file, (B) project and (C) workspace
scope.

In use case (3) : It would be nice if the dialog box dynamic tree could be expressed in the current _menu() paradigm
of the SE macro language. That way my current code could port easily to the new feature. On the other hand - I could
morph my current _menu() based code - to other code artifact type for a structurally similar SE module (to express the
dynamic tree structure). Note in this design context we use SE macros as the basis of the custom tree design expression,
followed by the XML storage/persitence paradigm. I prefer the SE macro paradigm as the primary design expression
medium - since all the stuff I do revolves around the SE Macro language. The ability to export, import to other SE
users in my local user group (academic environment - students in the K12U pipeline) - via the XML construct - allows a
senior software engineer to genesis the lexicon - via the SE Macro paradigm - and then mentor the junior members
of the software engineering culture - via the XML import/export paradigm.

Good feature recommendation, and yes : I could see an open dialog (that allows me to use the main SE GUI - and go
back and forth between dialog and main GUI) - as being a perfect solution - to single shot grep actions - outside the
current code domain of interest.

Note, as a parting note : The current code domain of interest (in my use of SE) - always has 2 or more toolbars (sometimes
6) - with 'grep action buttons' - to view code artifacts and then navigate to them (via the _tag lexicon). So the dialog with
a dynamic tree - would be a really neat way to have some visibility and navigation - for any _tag in the lexicon.