ClipName / Explore for Files alternatives that doesn't install, i.e., standalone exe?

[fitwell]

Well, it's happening more and more: "Program Files" and other folders
are being blocked more and more to prevent installing; understandably,
as most people don't know what they're doing and they can and do mess
up their systems. But it makes life very hard. It's making my life
difficult in a current contract, though. I "install", as it were, 3
apps whenever I start a new job. These are vital apps that I can't do
without on any computer I'm on for any length of time:

- ClipName - which saves the full pathname of any file or folder in
LFN format,
- CopyPath - which saves the pathname to the clipboard of any file or
folder and is configurable. I use it in particular to get the DOS 8.3
complete pathname as sometimes LFNs cause problems and won't work.
when this happens, I use the CopyPath alternative, and it always
works! <g>, and
- Explore for Files from Here - which puts the EXPLORE option in the
context menu for _anything_, but esp. good for shortcut files. <g>

All these shell extensions I use all the time no matter the OS. Their
functionality should be in Windows, in my view, but they're not (not
even in XP! "Explore" is more available, but not always, so "Explore
for Files..." works well for me even in XP!)

Does anyone know of a freeware alternative for these that _don't_
install? A bat file for Windows 2000 that I associate to any
file/folder would be a perfect solution, too. Any tips appreciated.

Thanks so much, guys! Appreciate any help in advance.

 

[Sietse Fliege]

Well, it's happening more and more: "Program Files" and other folders
are being blocked more and more to prevent installing; understandably,
as most people don't know what they're doing and they can and do mess
up their systems. But it makes life very hard. It's making my life
difficult in a current contract, though. I "install", as it were, 3
apps whenever I start a new job. These are vital apps that I can't do
without on any computer I'm on for any length of time:

- ClipName - which saves the full pathname of any file or folder in
LFN format,
- CopyPath - which saves the pathname to the clipboard of any file or
folder and is configurable. I use it in particular to get the DOS 8.3
complete pathname as sometimes LFNs cause problems and won't work.
when this happens, I use the CopyPath alternative, and it always
works! <g>, and
- Explore for Files from Here - which puts the EXPLORE option in the
context menu for _anything_, but esp. good for shortcut files. <g>

All these shell extensions I use all the time no matter the OS. Their
functionality should be in Windows, in my view, but they're not (not
even in XP! "Explore" is more available, but not always, so "Explore
for Files..." works well for me even in XP!)

Does anyone know of a freeware alternative for these that _don't_
install? A bat file for Windows 2000 that I associate to any
file/folder would be a perfect solution, too. Any tips appreciated.

Thanks so much, guys! Appreciate any help in advance.

I wrote an AutoIt script for "Explore for Files" that might do, provided
you are not blocked from putting shortcuts in the Send To folder.
(Or if you're allowed to edit the registry you could also make it a
first-level right-click option if you know how to do that, which would
mean one click less.)

right-click action
----------- ------
shortcut opens a new Explorer window for the target's folder
folder/file opens a new Explorer window for the folder/file

You can download the zipped executable (and script) here:

Note: Explorer gets started in the two-pane view and not maximized.
If you prefer otherwise the script needs to be changed.

If this helps, I could also do ClipName and CopyPath scripts.
I would need to know exactly what should be copied to the clipboard and
also if it should handle multiple file selection.

 

[Sietse Fliege]

Well, it's happening more and more: "Program Files" and other folders
are being blocked more and more to prevent installing; understandably,
as most people don't know what they're doing and they can and do mess
up their systems. But it makes life very hard. It's making my life
difficult in a current contract, though. I "install", as it were, 3
apps whenever I start a new job. These are vital apps that I can't do
without on any computer I'm on for any length of time:

- ClipName - which saves the full pathname of any file or folder in
LFN format,
- CopyPath - which saves the pathname to the clipboard of any file or
folder and is configurable. I use it in particular to get the DOS 8.3
complete pathname as sometimes LFNs cause problems and won't work.
when this happens, I use the CopyPath alternative, and it always
works! <g>, and
- Explore for Files from Here - which puts the EXPLORE option in the
context menu for _anything_, but esp. good for shortcut files. <g>

All these shell extensions I use all the time no matter the OS. Their
functionality should be in Windows, in my view, but they're not (not
even in XP! "Explore" is more available, but not always, so "Explore
for Files..." works well for me even in XP!)

Does anyone know of a freeware alternative for these that _don't_
install? A bat file for Windows 2000 that I associate to any
file/folder would be a perfect solution, too. Any tips appreciated.

Thanks so much, guys! Appreciate any help in advance.

I wrote an AutoIt script for "Explore for Files" that might do, provided
you are not blocked from putting shortcuts in the Send To folder.
(Or if you're allowed to edit the registry you could also make it a
first-level right-click option if you know how to do that, which would
mean one click less.)

right-click action
----------- ------
shortcut opens a new Explorer window for the target's folder
folder/file opens a new Explorer window for the folder/file

You can download the zipped executable (and script) here:
http://s26.yousendit.com/d.aspx?id=1VOHI6PISHQNG0IOBGBSKRSNO7

Note: Explorer gets started in the two-pane view and not maximized.
If you prefer otherwise the script needs to be changed.

If this helps, I could also do ClipName and CopyPath scripts.
I would need to know exactly what should be copied to the clipboard and
also if it should handle multiple file selection.

 

[fitwell]

I wrote an AutoIt script for "Explore for Files" that might do, provided
you are not blocked from putting shortcuts in the Send To folder.
(Or if you're allowed to edit the registry you could also make it a
first-level right-click option if you know how to do that, which would
mean one click less.)

right-click action
----------- ------
shortcut opens a new Explorer window for the target's folder
folder/file opens a new Explorer window for the folder/file

You can download the zipped executable (and script) here:
http://s26.yousendit.com/d.aspx?id=1VOHI6PISHQNG0IOBGBSKRSNO7

Sietse, this sounds absolutely fabulous! I'm going to check it out.

Note: Explorer gets started in the two-pane view and not maximized.
If you prefer otherwise the script needs to be changed.

Actually, we don't have that luxury with Explore For Files From Here,
so this sounds like it would be an improvement. I prefer windows to
open up in single pane and maximized. I haven't been able to figure
out how to make AI do a single pane, but the AI command for maximizing
does work once you've manually maximized the folder the first time it

If this helps, I could also do ClipName and CopyPath scripts.
I would need to know exactly what should be copied to the clipboard and
also if it should handle multiple file selection.

Gosh, YES! That would be grand!

ClipName is just to copy the LFN of the complete pathname to the
clipboard, and my configuration of CopyPath copies the 8.3 DOS version
of the complete pathname (CopyPath has other configuration
possibilities, but that's all I personally use it for for the most
part).

i.e., I have a graphic on my D drive called "Egypt- Horus.jpg".
ClipName returns to the clipboard this LFN value of the file :
D:\STARGATE\Egyptian symbols and motifs\Egypt- Horus.jpg

whereas the 8.3 pathname that PathCopy returns is:
D:\STARGATE\EGYPTI~1\EGYPT~61.JPG

This will actually be a fantastic thing having these three scripts
availabe in AI, since I don't know how to code more advanced stuff in
AI.

More and more I'm coming across installation restrictions in the
computers I use in job contracts. We're physically blocked from
working within certain key folders (understandably, I know, but I've
never been the one to be a problem in this way <sigh>. I only ever
install these 3 apps! And they're for work purposes!!!) Yet I've been
only one week on the job and am finding it really, really tough to
work without these 3 tools! Esp. since I'm working on a _minimum_ of
3 drives over the network so far! Because of having to attach things
to emails, etc., etc., ClipName and CopyPath were always my salvation.
After this week, don't know how I worked before without them.

Also Explore From Here For Files is very handy when doing searches,
etc., and going to the folder a file is in. Granted, Win2K and XP
have a bit more functionality in this regard than my Win98SE with
"open container folder..." when doing searches, and some of the MS
apps have this, too, but even so, "Explore" _still_ isn't always
available reliably in the context menu. So these would be excellent
things to have in our freeware repertoires, a no-install version of
these 3 apps.

Thanks much! Really appreciate this. Going to check the "Explore"
alternative in AI script form that you have path to above right now.

 

[Sietse Fliege]

On Sun, 30 Jan 2005 00:37:42 +0100, "Sietse Fliege"


Actually, we don't have that luxury with Explore For Files From Here,
so this sounds like it would be an improvement. I prefer windows to
open up in single pane and maximized. I haven't been able to figure
out how to make AI do a single pane, but the AI command for maximizing
does work once you've manually maximized the folder the first time it
opens if it's not maximized for some reason <g>.

You can replace this line in the script: Run("Explorer.exe /e," & $Parm)
with : Run("Explorer.exe " & $Parm, "", @SW_MAXIMIZE)
Then it opens up in single pane and maximized.
Note: you need at least version AutoIt version 3.0.102

Or you can download the zipped executable here:
http://s5.yousendit.com/d.aspx?id=1L4509L98GIQD0QUBW0FPYTIK3

You can download these here:
http://s5.yousendit.com/d.aspx?id=02815LSIOT46N1L55U0EMESA7H

So these would be excellent things to have in our freeware
repertoires, a no-install version of these 3 apps.

I agree, they are must-haves. So I'm glad if I can help you out.
Let me know if you want something changed, though.

BTW, I don't think that these 3 small scripts are that advanced.
I never had a proper look at those parts of AutoIt and AutoHotkey that
are about GUI's though, otherwise I would have a go at the other request
you had, for the multiple apps launcher.

 

[fitwell]

You can replace this line in the script: Run("Explorer.exe /e," & $Parm)
with : Run("Explorer.exe " & $Parm, "", @SW_MAXIMIZE)
Then it opens up in single pane and maximized.
Note: you need at least version AutoIt version 3.0.102

Or you can download the zipped executable here:
http://s5.yousendit.com/d.aspx?id=1L4509L98GIQD0QUBW0FPYTIK3


You can download these here:
http://s5.yousendit.com/d.aspx?id=02815LSIOT46N1L55U0EMESA7H


I agree, they are must-haves. So I'm glad if I can help you out.
Let me know if you want something changed, though.

BTW, I don't think that these 3 small scripts are that advanced.
I never had a proper look at those parts of AutoIt and AutoHotkey that
are about GUI's though, otherwise I would have a go at the other request
you had, for the multiple apps launcher.

Sietse, EXCELLENT!!! All three work like a charm on my Win98SE! I'm
so relieved and excited to try these out tomorrow. I really have been
having a hard time this past week trying to cope with all the
files/folders/drives without my 3 trusty files! <g> I feel so
relieved now that there seems to be a workaround on installation
restrictions. I used ContextEdit to put all 3 executables in the
context for all files, now I'm going to take some screenshots of how
Windows deals with the file associations so I can do it manually on
the computer tomorrow without ContextEdit.

I can't thank you enough. I took a look at the coding in your au3
files and this non-programmer would never have figured out how to do
all that in a million years! One of these years I'd like to take some
basic programming, but RL gets in the way and many other financial
pressures come first.

Thanks once again! This are gems to the freeware world along with
RL's "Handy Little Backer Upper" also done in AI. AI is such a
_fabulous_ gem. I don't know how I lived without it before <g>,
though my uses are fairly rudimentary. <g>

 

[fitwell]

[snip]

restrictions. I used ContextEdit to put all 3 executables in the
context for all files, now I'm going to take some screenshots of how
Windows deals with the file associations so I can do it manually on
the computer tomorrow without ContextEdit.

[snip]

Oops, thank goodness ContextEdit is a standalone, something I'd
forgotten. I couldn't see in Win98SE where an entry for files of any
type is found <g>; fortunately, something so easy to do with CE! So
that is going on to my floppy along with your fabulous scripts for
work tomorrow! <phew>

 

[Sietse Fliege]

Oops, thank goodness ContextEdit is a standalone, something I'd
forgotten. I couldn't see in Win98SE where an entry for files of any
type is found <g>; fortunately, something so easy to do with CE! So
that is going on to my floppy along with your fabulous scripts for
work tomorrow! <phew>

Hopefully it's going to work out.

I just now noticed that the "Explore for Files" script does not check
whether a shortcut's target is a file or folder.
As a result, in case it is a folder an Explorer window for the parent
folder is opened.
It also doesn't check if the shortcut is perhaps an orphan (target does
no longer exist).

No biggies, but I upped a revised version:
http://s20.yousendit.com/d.aspx?id=1XGP6AVQPT5LA2WUN4FZ051FBA

 

[fitwell]

Hopefully it's going to work out.

Well, I finally had my "new" computer hooked up this afternoon so at
day's close, was finally able to try these. Got worried there for a
bit since, like d'uh, though ContextEdit doesn't install, it _does_
rewrite the registry with any changes we make. So that wasn't going
to work.

However, you genius you! <g>, you put in a message box box that popped
up something about the "SendTo" folder. That triggered a memory about
the SendTo, so I tried putting the programs in there. Phew, it
worked!! Granted, not in one mouse clic as a regedit via ContextEdit
would, but still. With 2 mouse clicks, I get the same functionality.

I just now noticed that the "Explore for Files" script does not check
whether a shortcut's target is a file or folder.
As a result, in case it is a folder an Explorer window for the parent
folder is opened.
It also doesn't check if the shortcut is perhaps an orphan (target does
no longer exist).

No biggies, but I upped a revised version:
http://s20.yousendit.com/d.aspx?id=1XGP6AVQPT5LA2WUN4FZ051FBA

Thanks so much! I'm going to try this one, too!

 

[Sietse Fliege]

Well, I finally had my "new" computer hooked up this afternoon so at
day's close, was finally able to try these. Got worried there for a
bit since, like d'uh, though ContextEdit doesn't install, it _does_
rewrite the registry with any changes we make. So that wasn't going
to work.

Bugger. :-(

However, you genius you! <g>, you put in a message box box that popped
up something about the "SendTo" folder. That triggered a memory about
the SendTo, so I tried putting the programs in there. Phew, it
worked!! Granted, not in one mouse clic as a regedit via ContextEdit
would, but still. With 2 mouse clicks, I get the same functionality.

If you use them often that is a bit of a set back but it's all you can
do and better than doing without.

Thanks so much! I'm going to try this one, too!

Glad if I helped, Fitwell. Enjoy!

 

[fitwell]

Bugger. :-(

Ah, well. The SendTo workaround works marvellously, so turns out no
worries.

If you use them often that is a bit of a set back but it's all you can
do and better than doing without.

Nah, I knew I'd get used to it very quickly; it's not a problem with
the apps or anything but a problem with the registry lock they've put
in. I think this govt dept has gone to an extreme with this. But
what I've learned through these latest exercises is that I can still
get around whatever they decide to do to make our lives more difficult
(though I understand, of course, why they have to do this. There are
many who abuse or who make big mistakes unwittingly, etc.)

So after nearly 2 days of using the 3 AI replacements, I'm back up to
speed and love them! Actually, since they're always in the same spot
in the SendTo box no matter what, it's gotten so that I go there
without thinking and I prefer that quite a bit over ExploreFF,
PathCopy and ClipName whose locations change depending on what context
menu one is pulling up. So it's a real trade. I might have the extra
mouse click, but since I don't have to hunt for them, that makes the
speed equal.

Glad if I helped, Fitwell. Enjoy!

These can go in the pricelessware arsenal, in my view! <g>

Thanks!

 

[fitwell]

Well, it's happening more and more: "Program Files" and other folders

[snip]

Sietse, the little apps work like a charm! I've been so happy with
them at the office because of the registry freeze.

Just a heads up, EXPLORE doesn't like very long LFNs, though. I was
wondering if there was any way around that? At the office, I'm often
trying to navigate to files that are nested a few folders away on the
network. I have to travel up 3 or 4 levels before EXPLORE will work.

Just a note for anyone using these that they might run into this.
Both LFN and 8.3 clipname have been working absolutely perfectly on
everything so far, so they're absolutely grand, too!

Thanks, Sietse, once again for these little AI "apps". You're the
best! <g>

 

[Sietse Fliege]

Just a heads up, EXPLORE doesn't like very long LFNs, though. I was
wondering if there was any way around that? At the office, I'm often
trying to navigate to files that are nested a few folders away on the
network. I have to travel up 3 or 4 levels before EXPLORE will work.

Hello fitwell,

Now, that is a surprise!
There is nothing in the script for Explore for Files that would explain
why it would fail for very long LFN's.
Neither is AutoIt itself limiting in that way.

On my systems I can also not replicate your findings.
For instance on my Win95 box I can only have path names up to 254 chars,
but Explore for Files has no problem opening an explorer window for such
a file or folder.

The only possible explanation I can come up with is that the system you
are using it on is limiting you in yet another way. My guess is that on
that system users with no administrative rights can only run program,
like Explorer, with parameters of limited length. So when the scripts
starts Explorer with as parameter a path that exceeds that limit, that
causes an error.

Maybe you can confirm that on your system at home Explore for Files does
work even with very long LFNs.

Could you tell what OS it is that you have problems with and also at
what path length does it begin to fail, give or take a few chars maybe?

Also, note that Explore for Files combines 2 (or 3) functions:
+ start an explorer window for a file or folder
+ start an explorer window for a shortcut's target folder
For the latter you need e.g. AutoIt, to obtain the shortcut's target.
But for the other function you could also just use a batch/.cmd file.

For instance the following one-line .cmd file would start an explorer
window for both a file or a folder on Win2k/WinXP:

explorer.exe %~dp1

If your problem system at work is Win2K you could try out a shortcut to
that cmd file in yor Send To folder.
I expect it to fail for very long LFNs for the same reason.

I suggest that if you check things out and report back, we could
hopefully work something out.

 

[fitwell]

Hello fitwell,

Now, that is a surprise!
There is nothing in the script for Explore for Files that would explain
why it would fail for very long LFN's.
Neither is AutoIt itself limiting in that way.

Well, it happened on a long network path. What can I say? It just

On my systems I can also not replicate your findings.
For instance on my Win95 box I can only have path names up to 254 chars,
but Explore for Files has no problem opening an explorer window for such
a file or folder.

The only possible explanation I can come up with is that the system you
are using it on is limiting you in yet another way. My guess is that on
that system users with no administrative rights can only run program,
like Explorer, with parameters of limited length. So when the scripts
starts Explorer with as parameter a path that exceeds that limit, that
causes an error.

? I couldn't say.

Maybe you can confirm that on your system at home Explore for Files does
work even with very long LFNs.

Well, I don't have thinked pathed so long at home, you see. But if I
do come across that, I'll let you know.

Could you tell what OS it is that you have problems with and also at
what path length does it begin to fail, give or take a few chars maybe?

It was Windows 2000 but I'm no longer there so can't tell you. I
think I was about 5 or 6 folders into a network drive when this
started to happen. Again, when I went up a folder, I seem to remember
it working alright then. (?)

Also, note that Explore for Files combines 2 (or 3) functions:
+ start an explorer window for a file or folder
+ start an explorer window for a shortcut's target folder
For the latter you need e.g. AutoIt, to obtain the shortcut's target.
But for the other function you could also just use a batch/.cmd file.

For instance the following one-line .cmd file would start an explorer
window for both a file or a folder on Win2k/WinXP:

explorer.exe %~dp1

If your problem system at work is Win2K you could try out a shortcut to
that cmd file in yor Send To folder.
I expect it to fail for very long LFNs for the same reason.

I suggest that if you check things out and report back, we could
hopefully work something out.

Oh, not to worry. Your programs are perfect just as they are! I was
in a situation where they locked the registry up tight <g>. I was
very, very happy to have no-install solutions to practically
everything. After all, they just don't want us buggering up their
comptuers, right? And no installs don't modify the registry at all,
so it worked out quite perfectly. It was just in the manner of a
heads-up, just to advise that there might be the odd thing that didn't
work out right. In those cases, I fortunately was in Win2K so could
use its "open container folder" option, something not available in my
Win98SE, for example <g>.

Cheers! And thanks for the great work on these. They made life
tolerable, otherwise, I would have been pulling my hair out every day!
<lol>

 

[MLC]

_fitwell_, sabato 02/apr/2005:

And no installs don't modify the registry at all,

Not true!
Many programs, just running the .exe the first time, write a lot of keys
into the registry.

 

[fitwell]

_fitwell_, sabato 02/apr/2005:


Not true!
Many programs, just running the .exe the first time, write a lot of keys
into the registry.

Not when the registry is completely blocked from modification and they
run anyway! <g>