Add sub-menu support for scripts

[admin]

No, just talking about nesting.

[FluxTorpedoe]

Hi’

   I just tried popupnested, which looks promising…
   Although it’s so specific that I’m really tempted to voice a strong suggestion, if I may:

• What if ">" was used instead of indent?
    (while keeping popupnested exactly as it is already implemented)


 ☛ That way the whole XYplorer scripting syntax would remain one and logical, and compliant with existing scripting behaviors, be it for whole multiline scripts or popup* commands.

Code: Select all

> In a multi-line script all lines apart from the first line have to be indented by at least one space.
> Each non-indented line is interpreted as the first line of a separate script, and if there are more than one scripts in a loaded script resource (i.e. a multi-script) then a menu is popped where you can select the script to run.

 1. XY Scripting structure—and especially indents—would always behave the same (no need to add "except when using popup commands…"); whereas with the indent route, there are two very different logics, particularly visible with Heredoc.
So instead, for popupnested, we would have (with indents only used for readability):

Code: Select all

text popupnested("Top|>Sub|>Sub|>>Sub2|>>Sub2|Top",,,,, 2);

        $menu = <<<MENU
Top;;:paper;1
  >Sub;;;4
  >Sub
    >>Sub2;;*.ini
    >>Sub2
    >>Sub2;;;2
Top;;<xy>
MENU;
          text popupnested($menu);

 2. And more importantly, a single submenu syntax would be valid everywhere, with ">" indicating one level of submenu (even if it’s only implemented later for the rest of SC).
   Example of a multiline script (empty lines and indents before ">" also used for readability):

Code: Select all

        $menu = <<<MENU
"Top 1"
  msg 1;

"Top 2"
  >"Sub 1"
    msg 21;
  
  >"Sub 2"
    >>"SubSub 1"
      msg 221;
    >>"SubSub 2"
      msg 222;

"Top 3"
  msg 3;
MENU;
          load $menu, , "s";

Well, I don’t know if I’m sensible enough, or how much work that would mean…

Thanks anyway,
Flux

[admin]

Good idea, fine with me! But...

... there are parsing issues lurking with this approach:

Code: Select all

text popupnested("Top|>Sub<get char 0041 |>Sub|>>Sub2|>>Sub2|Top");

Caption "Sub<get char 0041 " creates a pseudo variable "<get char 0041 |>" in the string... it will be resolved to "A" before popupnested() is reached. So ">" is not a good choice for that nesting character...

[FluxTorpedoe]

Hi’
Thanks for the amazingly quick feedback!

Regarding the parsing, you lost me with the origin of this line syntax: how could the get variable not be closed before the next "|" entry (except because of a typing error)?

Conversely, I’d understand the following lines, where presumably all non-submenu ">" would be resolved beforehand (so no parsing error?)…

Code: Select all

text popupnested("Top|>Sub<get char 0041>|>Sub|>>Sub2|>>Sub2|Top");
text popupnested("Top|>Sub<selimets |>|>Sub|>>Sub2|>>Sub2|Top");

Anyway I definitely trust your knowledge in this matter…

So another character would probably be safer; well, easier said than found…
Don’t know if ^ is available on all keyboards, or \ (but might cause other problems?)…

[admin]

I meant if you would create a menu caption "Sub<get char 0041 " ... sure, it's crazy, but users are crazy...

One improvement I could add is to make this possible (that the top level does not have to be left-bound). This would increase overall readability I think:

Code: Select all

$menu = <<<MENU
          Top;;:paper;1
            Sub;;;4
            Sub
              Sub2;;*.ini
              Sub2
              Sub2;;;2
          Top;;<xy>
        MENU;
  text popupnested($menu);

[FluxTorpedoe]

I meant if you would create a menu caption "Sub<get char 0041 " ... sure, it's crazy, but users are crazy...

Wow…
Sure, that’s not utterly impossible… But that’d still be rather unlikely from someone knowing enough scripting to use submenus, no?
So a word of caution may suffice IMHO, e.g.: it’s not advised to use the "<" character in your submenu captions (unless you know what you’re doing).

One improvement I could add is to make this possible (that the top level does not have to be left-bound).

Well, why not, but the previous was quite clear too.

What bothered me with "indent" as a submenu identifier was the fact that indentation would mean two completely different things depending on the context (standard scripting or popumenunested).
Plus, another submenu identifier would still be needed for multiline scripts, hence the incentive to keep indentation as it is and use another submenu identifier.

[admin]

Well, strictly speaking it's not the indent but the leading spaces that mark the level. Only when using CRLF as item separator it comes to look like an indent.

This way, using | instead of CRLF, works as well:

Code: Select all

text popupnested("Top| Sub| Sub|  Sub2|  Sub2|Top");

[nerdweed]

The sub-menu section is amazing. May I ask you to allow registering on the parent item as well i.e; a hover will open the sub-menu and if the item is clicked; it runs the accompanying code.

Use case:
Submenus will allow registering granular details whereas the parent menu will continue to give existing functionality. Currently, this can be achieved through <get shift>. Basically, all <get shift> options now move into submenu whilst continuing to retain no shift at the top level.

It may not be a very standard behavior, but it is amazing.

[admin]

Well, not only non-standard behavior, but technically impossible (unless I emply some major hacks).

[admin]

What bothered me with "indent" as a submenu identifier was the fact that indentation would mean two completely different things depending on the context (standard scripting or popumenunested).
Plus, another submenu identifier would still be needed for multiline scripts, hence the incentive to keep indentation as it is and use another submenu identifier.

I see your point. But for now I will keep it as it is. An optional submenu identifier can always be added later as an additional parameter.

[LittleBiG]

Won't something similar be possible later in CTB script?

Code: Select all

"Top"
  "Sub1"
    "Sub11"
      text "11";
    "Sub12"
      text "12";
  "Sub2"
    text "2";
"Top2"
  text "T2";

[admin]

Yes, later.

[FluxTorpedoe]

@admin
Thanks for the feedback.

[highend]

@Don

Should a menu item that is the opener for a submenu not be greyed out like normal items
when it's state is 4? (ocf I'm using "<:>" as the separator for popupnested() here)

Code: Select all

 Mp3 Special<:><:><:>4
  Filename (Artist - Title.mp3) to ID3 Tag<:>#141;<:><:>4
  Filename (Track - Artist - Title.mp3) to ID3 Tag<:>#142;<:><:>4
  Filename (Artist - Album - Track - Title.mp3) to ID3 Tag<:>#143;<:><:>4
  Filename (Artist - Year - Album - Track - Title.mp3) to ID3 Tag<:>#158;<:><:>4

"MP3 Special" has a black color in this case, not a grey one like it's subitems

[klownboy]

Won't something similar be possible later in CTB script?

Code: Select all

"Top"
  "Sub1"
    "Sub11"
      text "11";
    "Sub12"
      text "12";
  "Sub2"
    text "2";
"Top2"
  text "T2";

The new SC popupnested is great Don, but revamping previously written large menus that use normal XY menu scripting can be quite a task. No problems when coming up with new menus. I have a few menus that I'd be better off starting from scratch (and I don't want to do that) than trying to update to use SC popupnested especially when there are long complicated run or open statements. So I'll second the motion for nested fly-out submenus in the typical XY menus that don't use SC popupmenu/popupnested.

Thanks,
Ken