run external program with parameters

[jcmn]

Didn't find a quick way to run an external program with parameters. Can the address bar be used to this?

I know that there are the user commands but this is an occasional run and I don't need to create such user command.

[zer0]

Didn't find a quick way to run an external program with parameters. Can the address bar be used to this?

No, address bar in XY cannot be used to run executables. On the other hand, AB in Windows Explorer (Vista) can do so.

EDIT: You can run files from within XY's AB, but you have to prefix your EXE's location with "file:///". No need for any prefix with WE.

[jacky]

Didn't find a quick way to run an external program with parameters. Can the address bar be used to this?

No, address bar in XY cannot be used to run executables. On the other hand, AB in Windows Explorer (Vista) can do so.

Actually it can, since you can do scripting from there. For example, using script command run one can do this:

Code: Select all

::run "notepad ""<curitem>""";

[zer0]

Actually it can, since you can do scripting from there.

I have already made the correction (see EDIT of my previous post). Still, running EXEs in XY's AB isn't as easy as it is in WE's AB.

[admin]

Actually it can, since you can do scripting from there.

I have already made the correction (see EDIT of my previous post). Still, running EXEs in XY's AB isn't as easy as it is in WE's AB.

That's because XY will jump to the EXE instead of running it. Just a different choice and IMO the better one.

[zer0]

That's because XY will jump to the EXE instead of running it. Just a different choice and IMO the better one.

I beg to differ that it's a better choice. I have several reasons why. First of all, it's a different behaviour to that of AB in WE, so someone coming over from that side of the tracks will have to adapt to it. It will also make him/her question what's the benefit of the current way, just like it did with me.

Let's take one example: "C:\Program Files\CCleaner\CCleaner.exe" Inserting that into WE's AB will lauch CCleaner. Inserting that into XY's AB will essentially do this: "C:\Program Files\CCleaner\" with an added bonus of having the EXE selected. Now I'm going to go out on the limb here and say that most people are likely to sort their lists either by name or by type. This means that finding the right file isn't difficult, which reduces the usefulness of it being auto-selected by AB.

Also, why would one have a file selected? To run it, to edit it, to print it, to view it. All of those actions require that a file is open aka default behaviour of WE's AB.

Furthermore, I don't see it as feasible that people would put "file:///" in front of the path just to open it. If it's auto-selected without copying/pasting the above prefix then it's quicker just to hit Enter or double-click it.

Having a file auto-selected is a bonus. Being able to run applications and open files in AB simply by typing/pasting their locations into it and pressing Enter is a real advantage in terms of functionality.

P.S. It would be useful to have a Go (->) button in AB when manually typing ala ABs in WE, IE and Firefox. It will be an accessibility benefit for those who prefer to use their mouse as much as possible.

[TheQwerty]

First of all, it's a different behaviour to that of AB in WE, so someone coming over from that side of the tracks will have to adapt to it. It will also make him/her question what's the benefit of the current way, just like it did with me.

It's not that big of a change. I question how many people actually launch programs in that manner in the first place. I'd think more people use Win+R for that type of quick launching.

Now I'm going to go out on the limb here and say that most people are likely to sort their lists either by name or by type. This means that finding the right file isn't difficult, which reduces the usefulness of it being auto-selected by AB.

The usefulness of it being auto-selected has nothing to do with how quickly it can be found and everything to do with how quickly I can proceed to do whatever I like with the item.

Also, why would one have a file selected? To run it, to edit it, to print it, to view it. All of those actions require that a file is open aka default behaviour of WE's AB.

To rename, move, copy, backup, launch other actions on the item, most of which don't tend to work well when the item is open.

Furthermore, I don't see it as feasible that people would put "file:///" in front of the path just to open it. If it's auto-selected without copying/pasting the above prefix then it's quicker just to hit Enter or double-click it.

Having a file auto-selected is a bonus. Being able to run applications and open files in AB simply by typing/pasting their locations into it and pressing Enter is a real advantage in terms of functionality.

If it's auto-selected it's an extra enter for you to launch it (followed by a Back if you really needed to remain in the previous location). "%windir%\notepad.exe" <Enter> selects notepad.exe, <Enter> again launches it. Auto-executing it removes all functionality of making it easy to do other tasks, as I now have to do more than just hit enter (and back) to get to that item.

I agree with Don that the current approach is better, as it allows for more to be done on the item by default. Perhaps if there were a shortcut for "file:///" or a syntactical pattern that could easily allow launching program, that would be an even better compromise.

[zer0]

It's not that big of a change. I question how many people actually launch programs in that manner in the first place. I'd think more people use Win+R for that type of quick launching.

It's a change nevertheless. There must have been a serious case for including functionality that is currently present in WE. Combining AB with functionality of Win+R is an ingenious way to pack more features into a program.

The usefulness of it being auto-selected has nothing to do with how quickly it can be found and everything to do with how quickly I can proceed to do whatever I like with the item.

Search results would give you just as much functionality of doing what you want with an item. In my example, I used the address of an application's EXE. I don't want to do anything else with it other than run that program. If I was to use a link to a text document I'd expect it to open. If I wanted to do something else with it then I'd not use its full link in the AB.

To rename, move, copy, backup, launch other actions on the item, most of which don't tend to work well when the item is open.

The purpose of the address bar when a direct link to an item is given should not be to locate it, but to use it as per defined settings. It's what happens in WE and the same happens in Internet browsers. I don't know how XY's competitors compare in this but if browsers used by millions do this then it's must be for a good reason.

If it's auto-selected it's an extra enter for you to launch it (followed by a Back if you really needed to remain in the previous location). "%windir%\notepad.exe" <Enter> selects notepad.exe, <Enter> again launches it. Auto-executing it removes all functionality of making it easy to do other tasks, as I now have to do more than just hit enter (and back) to get to that item.

Auto-executing makes launching it easy. It doesn't even take me to the item's location (great if it's buried deep in the tree that you'd then have to collapse). I can still go there though by removing the executable part from the address

I agree with Don that the current approach is better, as it allows for more to be done on the item by default. Perhaps if there were a shortcut for "file:///" or a syntactical pattern that could easily allow launching program, that would be an even better compromise.

I don't agree that the current approach is better. It doesn't make launching from AB as easy as it could be. Perhaps a tweak could be added to support default Windows Explorer behaviour. It will keep those used to the XY's way happy but also satisfy those who are used to WE's behaviour, now that's a compromise.

[j_c_hallgren]

Perhaps a tweak could be added to support default Windows Explorer behaviour. It will keep those used to the XY's way happy but also satisfy those who are used to WE's behaviour, now that's a compromise.

What a lot of words on both sides here...and while I almost never use the AB in this way, I can see that the final conclusion by zer0 seems to be the ideal way to solve this conflict whereby user can "have it your way" and thus nobody is prevented from having it work as they wish.

[TheQwerty]

Actually... I'll flip-flop, because I think we need to quit pressuring Don to add tweaks and options (not that I actually will stop. )

With some recent changes we have a decent groundwork to achieve a better system, which allows easy access to both and eliminates the need for an option (assuming we can break current habits, though there could still be an OnExactMatch tweak)...

Essentially, the address bar will take the form:
'[Location[\Item]][Executor[Term]]'
or
'[::]Quick Script;'

Default behavior:
If you enter a location it browses to that location.
If you enter the exact address of a file, it opens that file.
If you enter '::...' or have the recognize scripts without '::' tweak enabled, it tries to perform the script.

Then we have the following special executor patterns:
'location>term' = Quick Spot
'location<term' = Quick Select
'location|term' = Quick Filter
'location?term' = Quick Find

In each of these cases the term may contain multiple parts separated by ';' or '|', and the location may contain the '*' wildcard.

Now the executor patterns cannot be combined into a single call (you can't quick find and quick filter all at once), but if the location is omitted (so the AB value starts with the executor) they will be added to the current state.


I know this breaks the new Type-ahead find in address bar/spot function but I think if the change was made now it would be acceptable. And while I'd prefer '>' was for Quick Select it was pre-established for Spot so no point in changing it.


Thus if you enter:
"C:\windows\" = Browse location "C:\windows."
"C:\windows\notepad.exe" = Open "notepad.exe."
"C:\windows>notepad.exe" = Browse location "C:\windows" and Spot "notepad.exe"
"C:\windows<notepad.exe" = Browse location "C:\windows" and Select items matching "notepad.exe"
"C:\windows|notepad.exe" = Browse location "C:\windows" and apply VF to show items matching "notepad.exe."
"C:\windows?notepad.exe" = Search location "C:\windows" for "notepad.exe."

Or you could enter in sequence:
"C:\windows?note*pad"
"|*.exe"
">notepad"
"<notepad01.exe"

Which would:
1) Search "C:\windows" for anything matching "note*pad".
2) Apply a visual filter to the results so that only items ending with ".exe" are shown.
3) Spot (highlight) all items containing "notepad".
4) Select items matching "notepad01.exe".


Yep.. I think that would rock.

[admin]

'location>term' = Quick Spot
'location<term' = Quick Select
'location|term' = Quick Filter
'location?term' = Quick Find

...

Yep.. I think that would rock.

Yep, not bad. Not bad at all! Especially the Quick Select is brilliant.

However I (still) don't like the part: "C:\windows\notepad.exe" = Open "notepad.exe." I would run apps thru the AB only if the user actively allows it by a new option "blah"... so, yeah, with an additional little checkbox I'm with you, WE compatibility priests!

Bump me later...

[zer0]

Actually... I'll flip-flop, because I think we need to quit pressuring Don to add tweaks and options (not that I actually will stop. )

However, I fear that the more people move over to XY from WE the more likely people will ask for features of WE to be present. How often have we read "...I can do...in Windows Explorer, but in XY...". We're creatures of habit, plain and simple. Adding tweaks and options is the best way to take care of "WE compatibility priests", doing so means that only the asked-for features are integrated instead of blindly cloning the whole lot -> less waste and XY bloat.

[TheQwerty]

Actually... I'll flip-flop, because I think we need to quit pressuring Don to add tweaks and options (not that I actually will stop. )

However, I fear that the more people move over to XY from WE the more likely people will ask for features of WE to be present. How often have we read "...I can do...in Windows Explorer, but in XY...". We're creatures of habit, plain and simple. Adding tweaks and options is the best way to take care of "WE compatibility priests", doing so means that only the asked-for features are integrated instead of blindly cloning the whole lot -> less waste and XY bloat.

Did you read the rest of my post? I outlined a very good compromise that would eliminate any need for a tweak or option. The difference between executing and selecting the item would be all of 1 character, which Don already said he'd want to make configurable anyway (though I disagree that any option is needed here).

Adding more and more configuration options is not the optimal solution.
1) It makes an overly complicated GUI/setup for the user.
2) It typically makes more of a mess for the dev.
3) It wastes huge amounts of time when tracking down bugs and offering support.

It is far better to implement WEs features in a way that is smarter and can be better extended than to have hundreds of settings that define (and typically lock you into) certain behaviors.

[j_c_hallgren]

The difference between executing and selecting the item would be all of 1 character, which Don already said he'd want to make configurable anyway (though I disagree that any option is needed here).

I think your solution is just dandy, especially with Don's option which would make those who only want WE style happy...you know that some users don't like chg even if it is to make it more flexible so allowing them to do their old thing certainly helps, even if it requires use of a tweak since it's likely quite a rare case.

[TheQwerty]

The difference between executing and selecting the item would be all of 1 character, which Don already said he'd want to make configurable anyway (though I disagree that any option is needed here).

I think your solution is just dandy, especially with Don's option which would make those who only want WE style happy...you know that some users don't like chg even if it is to make it more flexible so allowing them to do their old thing certainly helps, even if it requires use of a tweak since it's likely quite a rare case.

To be fair I did comment that it would likely still need an option to appease everyone that prefers the current behavior, but I really do believe that it's not actually needed. Without it, current users will do some groaning about changing their habits, but they'll have lost zero functionality.