Enter Script...

[admin]

Wish to self: Give me a menu item called "Enter Script..." that pops the "::try" dialog. I want to enter a multi-line script directly without the need to write and execute a "try" command beforehand.

Okay, but where to put it??? Hmmmm, File menu? Tools menu?

[j_c_hallgren]

Personally, I expect to look for this at bottom of "User" menu where the "Run Script" and "Load Script" are...

Nice idea, BTW...it's more along lines of what I had thought of about a week ago...

[jacky]

Wish to self: Give me a menu item called "Enter Script..." that pops the "::try" dialog. I want to enter a multi-line script directly without the need to write and execute a "try" command beforehand.

Okay, but where to put it??? Hmmmm, File menu? Tools menu?

Under User|Run Script. You can even assign a KS like Ctrl+Alt+G to it if you want (And I actually called it "Debug Script...")


Seriously though, I can't really see it anywhere else but under "Tools", that's the only place it makes sense to me. For exampe:
Customize File Associations...
-
Enter Script...
-
List Management

Edit: Just saw jc's reply. I would disagree here, because the "User" menu (to me) is my own, err, user menu. As in, it's only filled if I want to fill it, and with what I put there.

Oh and, it's for UDC first, not scripts. Scripts don't have a "real" GUI (since they're available from pretty much everywhere), and as such I think such a menu belong under Tools.

[j_c_hallgren]

Edit: Just saw jc's reply. I would disagree here, because the "User" menu (to me) is my own, err, user menu. As in, it's only filled if I want to fill it, and with what I put there.

Oh and, it's for UDC first, not scripts. Scripts don't have a "real" GUI (since they're available from pretty much everywhere), and as such I think such a menu belong under Tools.

Well, the sub-menus to "User" are customized, but the main menu itself is common, right?
And what this is replacing is the need to have (in one solution) a one command script (Try) that is linked/tied to the "Run Script" item anyway, so having this at bottom would be more logical to me...I just don't see it connected to Tools...ok, so User may not be the ultimately ideal place, but keeping Script related functions in one common area offsets that, IMO.

[Pagat]

Like jc, i'd expect it side by side with "Run Script" and "Load Script".

[graham]

On the basis that scripts will be enhanced over the coming months and new features evolve I think there is a case to be made for a new dedicated menu for scripts which only shows if the user has configured the use of scripts. I agree that Tools is an obvious place but I do hate menus with long lists.

[jacky]

And what this is replacing is the need to have (in one solution) a one command script (Try) that is linked/tied to the "Run Script" item anyway

That's one way to look at it. Its purpose is to test scripts, those can be used on UDC yes, or other places, like in Catalog, other scripts, ...

UDC is only one interface for scripts, and that's not all it is. In my mind the menu User is linked to UDC, not Scripts. Should either one of those feature evolve in a way we haven't think of yet, the separation between UDC and Script could become even more important, and render this even more obvious (and then, more confusing).

When descripting the menu to a newbie, I'd say menu User is the place for your UDC, then if he had to go somewhere to look to test scripts, I'd think he'll probably think of Tools (since that's what scripts are) before UDC, because a script isn't necessary associated with a UDC...

My 2cents.

[j_c_hallgren]

jacky, you and I may disagree on some parts of this but that's ok...

You say that the "User" menu is for UDC's and not scripts...ok, so then why are there two built in menu items within it that are used strictly for/by/with scripts? And that is the only place (AFAIK) that scripts are specifically mentioned on a pull-down menu now...so having a third item there that is simply a shortcut form of what one would do via creation of a script seems a lot more logical than putting it on an unrelated menu, like Tools.

If there was a seperate menu bar item called Scripts, then these three would logically go there, but as there isn't, having them grouped together within User is next best.

To me, a script IS truely a UDC in a way...it's a set of commands like a macro and thus it's actually more of what I think of as a UDC than the others on that menu..for example, the "open" is not really 100% used defined, but just the parameters or values associated with it, so it's kinda a UDCP instead, while a script is totally defined by the user.

BTW, you've contradicted youself in parts of your reply, as have I, so we're even on that one!

Addendum: I can foresee more use for scripts than the other UDC's so I'd even suggest having these 3 script menu items be just under the "Manage" at top to make it quicker to access.

[admin]

On the basis that scripts will be enhanced over the coming months and new features evolve I think there is a case to be made for a new dedicated menu for scripts which only shows if the user has configured the use of scripts. I agree that Tools is an obvious place but I do hate menus with long lists.

Yes, in a later stage a new top menu "Scripting" might make sense. But it would look funny with only one item... but wait a minute...

Scripting (between User and Tools)
Enable Scripting [toggle]
Step through Scripts [toggle]
-
Enter Script...

Why not?! Of course, it would have to be shown even when "Enable Scripting" is off. But I'm rethinking this anyway: Actually it should be "Enable executing locations prefixed with :: as scripts" (or so ). So this is okay. Another advantage: one could have a keyboard shortcut for toggling Step mode (for which now you have to invest a UDC). Yet another advantage: "Scripting" would be visible in sceenshots.

(BTW, concerning the UDC menu I'm with jacky. These things have to be kept apart.)

[j_c_hallgren]

Since there is plenty of room to the right to expand the menu bar, adding a "Scripting" item would be fine and would solve this issue...and if added, as you may have seen, I'd certainly expect "Run Script" and "Load Script" to be within that menu and not User...

And what things have to be kept apart? If done as above, yes, but let's not leave some Scripting items in one menu and some in another, cause I'd find that very confusing! Even with my knowledge of the product!

[admin]

Since there is plenty of room to the right to expand the menu bar, adding a "Scripting" item would be fine and would solve this issue...and if added, as you may have seen, I'd certainly expect "Run Script" and "Load Script" to be within that menu and not User...

And what things have to be kept apart? If done as above, yes, but let's not leave some Scripting items in one menu and some in another, cause I'd find that very confusing! Even with my knowledge of the product!

So UDC Goto should move to the Go menu?

[j_c_hallgren]

So UDC Goto should move to the Go menu?

No...obviously not...because it and similar ones are cross-over types but are definitely within the UDC scope given that they have UDC values to function...which, admitedly, the Run/Load Scripts are also cross-over type items, but because they are closer to a Script than a UDC, that's why I feel they belong over there.

[admin]

Why not?! Of course, it would have to be shown even when "Enable Scripting" is off. But I'm rethinking this anyway: Actually it should be "Enable executing locations prefixed with :: as scripts" (or so ).

Currently there's a little mess:
"Enable Scripting" controls:
- msgbox when running a "::script" through a location interface (e.g. Address Bar)
- scripting support in CKS and UDC dialogs (command ID button, context menu items)
- However, it does NOT control running scripts via UDC.

I think we might need two settings:
(1) Enable Scripting:
- msgbox ("Scripting is OFF, run it anyway?) when running any script in
any possible way
- scripting support in CKS and UDC dialogs
- show the new "Scripting" menu
(2) Enable Extended Scripting:
- allow running "::script" through a location interface (e.g. Address Bar)
- show script icons in Catalog only when ON

Now, "Enable Extended Scripting" is a stupid label. Hmmm, any better ideas anybody?

[admin]

So UDC Goto should move to the Go menu?

No...obviously not...because it and similar ones are cross-over types but are definitely within the UDC scope given that they have UDC values to function...which, admitedly, the Run/Load Scripts are also cross-over type items, but because they are closer to a Script than a UDC, that's why I feel they belong over there.

Well, I feel differently, and the source code feels very strongly differently. The UDC implementation of course has its internal logic and consistence. You cannot just take stuff out of there and place it somewhere else.

[j_c_hallgren]

Hey, I'm not trying to argue just to be disagreable, but because the initial issue was where to put a built-in variant of a simple "Run Script - ::try" command, and if you have to do this command when done manually from "User" menu, then you would have to do the built-in one from the same place for that same reason that "you cannot just take stuff out of there and put it somewhere else", ok?