XYplorer Beta Club

graham wrote:Playing around with a few scripts and I keep finding the need for the msg command to allow an escape as well as OK

Or another command to do this ?

reason - if a script is started I usually head it with a msg showing the script title and if by mistake I started the wrong script it would be good at this stage to escape from the script. Not this applies when not running in step mode.

Or a command to branch to a label in the script - that offers a massive power step to combine script options.

I added that msg with Ok/Cancel.

Branch to label will come wth scripting 2.0.

graham wrote:Can I ask if the toolbar button for scripting be change colour from blue to red when not stepping as a visual warning. The dpressed button icon is not that easily seen.

Okay, I added it. Was fairly easy to do. Only I inverted the colors because I want to keep the normal state less marked:
Normal mode = blue
Step mode = red

Looks quite nice. Good addition!

admin wrote:

I added that msg with Ok/Cancel.


Thanks for that, I really am liking this scripting. I was a fan of User Commands but now they seem mundane.

Scripting is the new programming language.

Whilst here, I am not a fan of the present window that pops up for multi scripts - it seems to get lost visually and I think could do with a little more prominence no that it changes functionality.

graham wrote:Whilst here, I am not a fan of the present window that pops up for multi scripts - it seems to get lost visually and I think could do with a little more prominence no that it changes functionality.

You mean the menu? Yes, I've been thinking about an alternative, too. Maybe a small dialog with a list -- would be more visible.

yes exactly - just so it looks as though it matters and was not a quick fix window.

Another minor thing - the new blue/red button for stepping, the context should read no stepping when red - not essential if makes coding a problem

graham wrote:yes exactly - just so it looks as though it matters and was not a quick fix window.

Another minor thing - the new blue/red button for stepping, the context should read no stepping when red - not essential if makes coding a problem

context ? you mean the tooltip?

admin wrote:

graham wrote:Whilst here, I am not a fan of the present window that pops up for multi scripts - it seems to get lost visually and I think could do with a little more prominence no that it changes functionality.

You mean the menu? Yes, I've been thinking about an alternative, too. Maybe a small dialog with a list -- would be more visible.

Well, I've thought about this as well and I do beleive it would be nice some occasion yes to have a more specific window, and top have it centered and not at mouse position too.

That said, I've got quite a few occasions where a menu is actually just perfect, and something else woudl probably not be such a good idea here, so I don't really know.
I almost feel like this should be defined within either the script file, or just the calling command, so a new parameter for load to decide whether to show a menu or a window.

And on a slightly related note, I guess, for scripting 2.0 it'd be nice if there was a way, within a script file, for a script to have a menu shown but defining which items/scripts to include, using their ids/label for example.

So that you could have a scrip file that, when loaded, shows a menu with a dozen items/scripts, or when execuitng one contained script of that file it only shows about 4 of them, and another script could show some others, ....

re admin question re my last

sorry, I meant tooltip text

graham wrote:re admin question re my last

sorry, I meant tooltip text

I have done this (give an alternate tooltip to pressed state) only in 2 cases, although many more could use it:
Suspend/Reactivate Auto-Refresh
Lock/Unlock Tab

So this is inconsistent. However, I'd rather remove even those 2. It should be clear that the tooltip describes what happens when the button is pressed, and the opposite happens when it is unpressed.

admin wrote:So this is inconsistent. However, I'd rather remove even those 2. It should be clear that the tooltip describes what happens when the button is pressed, and the opposite happens when it is unpressed.

Agreed. Better keep one single tooltip that describes what the option does, when enabled.

jacky wrote:

admin wrote:So this is inconsistent. However, I'd rather remove even those 2. It should be clear that the tooltip describes what happens when the button is pressed, and the opposite happens when it is unpressed.

Agreed. Better keep one single tooltip that describes what the option does, when enabled.

As long as it can be real clear as to which is which! For someone new to XY, having the tip change and match what it will do at that moment is something to be considered from a ease of use and clarity viewpoint...on these type options, it may not be immediately obvious what state is what, so not sure how best to solve that.

Even as a XY veteran, I find the dual tooltips handy, as some of these options are ones that I only change on occasion.

j_c_hallgren wrote:As long as it can be real clear as to which is which! For someone new to XY, having the tip change and match what it will do at that moment is something to be considered from a ease of use and clarity viewpoint...on these type options, it may not be immediately obvious what state is what, so not sure how best to solve that.

Yeah but i don't think there's any problem here : if it reads "Suspend Auto-Refresh" then when enabled/pressed, auto-refresh is suspended. It's as simple as that, and really in the end it's no different that an option (checkbox) or a menu that may or may not be checked, and that reads the same.

jacky, I now agree with you...so maybe what I was hung up on was the actual text of these tooltips...maybe if it was "Toggle Auto-Refresh" or similar?

j_c_hallgren wrote:jacky, I now agree with you...so maybe what I was hung up on was the actual text of these tooltips...maybe if it was "Toggle Auto-Refresh" or similar?

Well, actually I think this could be more confusing, because one could assume that it would toggle AR, so that if AR was not enabled it could temporarily enable it, which is not actually the case.

Using "Suspend Auto-Refresh" seems good to me, since it is exactly what it does when enabled/pressed (as well as the actual menu caption under View).

Ok...I should have just kept quiet on this one...you're right again!