Mike Mills said:
you might try listpics by Kevin Solway.
This is a dos app which works like lightning, but is
restricted to the 8.3 filenames of course.
The version of ListPics that I have, it's a graphical 32-bit prog (v2,
1998). I don't spot problems with LFNs in that one.
First, it handles long names for the image files fine.
Second, where it writes source directory of target into the title tags,
it uses the LFN ... in most scenarios. That is, it's fine when it is
launched directly, pointing to the target directory as second step.
Also fine when it is launched from an explorer context command. The
case where it had trouble, and wrote SFN to title, that was when invoking
it by directing a folder at an .lnk file for it (eg by sendto).
I use it a lot, but have tried pich in its place as a test.
I've used ListPics in the past. But Pich is 40 times better for my needs.
Pich is tiny and instantaneous, with no GUI coming up to distract me. And
it has far superior output, in my view.
Same directory processed:
Pich:
http://www.redshift.com/~omega/clips/pich/sample1/pictmp.htm
ListPics:
http://www.redshift.com/~omega/clips/pich/sample1/PICLIST.HTM
Differences....
Pich writes the TOC to the pictures at the top. This is a great feature.
Provides both the instant overview of contents, as well as very useful
navigational aid.
Pich also makes the filenames dominant, headings above each picture. For
my screenshot situation, I much need this. I use the filename when I take
screenshot as my note on what it is I am observing.
In contrast to the other, when I look at the output file for ListPics, I
am pretty much lost, as far as what I was supposed to be noting to myself
about the program whose screenshots I took.
Now, if my use was to index something like a collection of scenery jpgs
in a directory, and maybe those having some kind of meaningless sequential
filenames, then there I would not have the strong interest in the way Pich
does emphasize the names. As is, though, my primary use really is the other.
The single and only item, in my observations, where ListPics does better.
It writes the image file dimensions within the src tags. I should think
this would not matter for local HDD use. However, for a situation as I
occasionally engage in, of putting up a few screenshots to my webspace
to illustrate some program(s) under discussion in ACF, then it would be
handy if I could have Pich take care of the whole matter in short step,
including doing image dimensions pre-filled, for that faster render.
The most striking difference in output. It is that serious space taken
at the top of the output page with ListPics product name stuff. ListPics
seizes premium space all for its vanity, using quite a number of lines,
plus large font sizing and hyperlinking. On a small laptop screen
especially, the effect is that its vanity stuff gets all the visual
impact, dominating the forefront, with the actual pics in the file
coming across as a lower afterthought.
Then there's the way all its output files bleat: "THE THINKING MAN'S
MINEFIELD." That's all well and cute at the programmer's own website.
Makes me think of young teen trying to work through his identity, find
pride in himself or something. However, to have that blasted all over
my disk, that would quickly become very distracting and irritating.
Sure, one could configure an SR utility to fairly automatically scan
the disk and delete the offending t4ext from its html output files.
However, the ideal program here should have reasonably acceptable
output generated on first go. Not require cleanup post-processing
in order to make it minimally endurable to view.
To me, the ListPics output files, with "THE THINKING MAN'S MINEFIELD"
and the related product headers, using up serious space at the top --
they are not minimally endurable to view, if left unedited. So this
prog loses major points in that another prog would have to be run each
time as followup step, to clean up.
pich often hangs for me, ending it with Ctrl-c gets out
and the files are saved with no problems.
The problem may have to do with a mixed collection of .jpg
and .gif files in a dir.
Sometimes it works properly and even exits, and sometimes it
does not.
That is sometimes I get the gifs listed, and sometimes not.
I've used this for a week or so, and now some dozens of times.
Including files with mixed image types. As well, after your posting,
I made sure to point it at a couple of directories containing a large
number of image files (300+ is my idea of a large number in this context).
In all cases, it processed things instantly and flawlessly.
Did these directories you were dealing with have some huge number of
files, possibly? I am also wondering if any chance this could be a case
where setting the command processing environment space (in 9x, using
config.sys entries like command.com /e:2048 etc) could have any relevance?
</Wild guesses dept>
Aside from the one thought that it could have involved directories with
huge number of files -- I come up pretty empty, for theory while you would
have had the experience of Pich failing the way you described. Since it
is not reading into the image files, only reading their filenames, that
would rule out all guesses along the line of it stumbling over a corrupted
file. Maybe you or someone else might develop an idea on what's up...
Oh, late though.... I'd sort of automatically ruled out that it would be
the type of program that would need much hardware power. Yet, then again,
I can't say for sure. I'm a "doorstop" user, and it performed fine on my
p500/192mb machinery. What did you run it on (and if anyone else has used
it on older hw, perhaps they'd report success/fail)?
