#kd_freq.library
26 messages in this thread
I've got another request for your file requester.
I hate either playing "Chase the File" in the file requester, or having to
watch the hard drive light or wait for the indicator to stop counting to
know that all the filenames have been loaded – I've got a fast enough hard
drive, that I'd prefer it just went and got the filenames as fast as
possible, and didn't show them to me until it had them all in memory.
If you were to do this, you could use the new 2.0 DOS function to read the
directory faster than the Examine() and ExNext() calls…
(by playing "chase the file" above, I mean clicking on a file while it's
reading the directory, but just as I'm about to click on it, the contents
of the window change, so I've got to go hunt it down again.)
…Steve
Steve, you mean ExAll()? My gripe with it is that it requires me to
pre-define the buffer size for reading the directory. As I have do idea
how big the directory will be, it is a tough call….. i.e. do I use a
large buffer and lose memory or use a small buffer and limit the number of
files I can read?? (sigh)
I don't know how much faster ExAll() would be, I do process those entries
pretty quickly.. unless ExNext() is slow.
Khalid.
Khalid, I prefer that you didn't use the ExAll() call since you do have to
specify the buffer size. You might think that someone will never need more
than 300 entries, and then someone comes along with a CD-Rom drive that has
500 in a directory. Keep it as is, it seems fast enough to me.
John – K7KB (via Whap!)
John, I have a test directory on my hard disk with 4500 entries, simply to
test the FR on such a situation. (grin)
In most cases, the overhead is in the device itself, and not the FR,
although after about 2000 entries the sort code does start to slow down a
bit. 🙂
Khalid.
Khalid,
I hate to tell you this but it seems that if I use fr_bypass with AssignX
the system crashes. Perhaps it is a problem with AssignX?
I have had AssignX crash on my consistantly when I try to start Dpaint III
from a picture icon.
Just thought you might want to know.
-mark=
– via Whap!
Mark, I've been using AssignX since the beginning (Thanks Steve, an
incredibly useful tool) and, of course, I've been using FR_Bypass for a
couple of years. No problems at all on my system.
-sja
Could this be a stack problem?
AssignX uses about 150 bytes of stack over the normal call to the AmigaDOS
requester – and the AmigaDOS requester uses an alternate stack, I believe,
so it won't run into problems.
I'll try the DPaint icon thing.
…Steve
Hey Steve, AssignX locks up AmigaVision if AV can't find a flow's assign.
Are you using a large stack or a 4K one?
That's the only place where I could see a problem… if that's not it, I'll
have to go hunting.
Steve,
I'm using a 10240-byte stack.
I finally got so sick of programs blowing up with stack problems, I set my
stack up to 50K. 🙂
Steve
I never really have understood this stack problem. Why would you ever run
out of stack space? What is the stack used for? And is the stacks
behavior documented in the Rom Kernal Manuals?
I too set a high stack as default to avoid problems with it, but I would
love a good tech explanation as to why this is a problem.
-mark=
– via Whap!
Well Khalid, I won't flame you too much if the FR slows down at 2000
entry's 8^)
John – K7KB (via Whap!)
I think you misunderstand the way ExAll() works. You do have to specify a
buffer size, but the buffer size isn't the maximum number of entries you
can read.
It works something like this:
while (TRUE)
{
ExAll();
if (NoFilesThere) break;
ProcessTheFiles();
};
(C pseudocode?) – If your buffer is bug enough, you might get all the files
in your first call to ExAll(), but if not, the subsequent calls will. And
it does read the directory quicker than Examine()/ExNext().
…Steve
OK Steve, thanks for explaining ExAll(). I'm just a beginner at using the
AmigaDos routines so still have plenty to learn.
John – K7KB (via Whap!)
It's not all that bad – with ExAll, your buffer can be the size of one
entry, if you like, and it will still handle it properly, since if there
were more files than would fit in the buffer, it tells you and lets you
resume from there.
According to somebody at CBM (can't remember who), it's a few less task
switches per file – it's not a matter of how fast you call Examine() and
ExNext(), it's just that the method was slower than ExAll() inherently.
(One of the first things I wrote for my 2.0 library was a
ReadDirectoryIntoList() function that uses ExAll – I should upload it. I
should upload the whole library… it's got a lot of routines that make
calling 2.0 functions easier).
…Steve
Steve, I'll look into ExAll, then, if it is faster. (probably some time
next week)
Khalid.
Something I just noticed about your file requester – your string gadgets
don't support Undo (Amiga-Q). I tend to use this a lot… is this an
oversight or do you not want to support that?
…Steve
Steve, it's a bit tricky… since I do a lot of manipulation of the string
gadget myself. I just enabled the normal Intuition handling of it for
now.. it works ok, but it gets confused sometimes since it tends to
remember what the string was when I asked it to activate the gadget. I'll
keep it like this for now. (grin)
Khalid.
Steve:
I thought the undo was Amiga-X ? (to clear out a string gadget). What does
Amiga-Q do?
-Mike Schiller
In sunny Fort Lauderdale
Mike,
You're right that the Amiga-X clears the string gadget. However, this
is not "undo" – "undo" does what you would expect in that it undoes any
editing that you've done since activating the gadget. In other words, it
restores the string to what it contained when the gadget was activated. It
is triggered by the Amiga-Q key. Note that this has been a standard
"feature" for a long time, but not _all_ string gadgets support it. The
programmer has to request that it be supported (and provide a data area to
hold the "undo" information).
Hope this helps….
BobR
Khalid:
as long as the FR's gonna have a config file, can you/are you going to go
over to the ExAll() and allow the user to specify number of files in the
config file? (me, I'd have to set it at or above 500, as I have lots of
little files, and some big ones too)
-Mike Schiller
In sunny Fort Lauderdale
Mike, maybe… but not for the next version. When I've got some free
programming time maybe. (grin)
Khalid.
Didn't realize you were starting a religious war, I bet. 🙂
The first thing I would do to a FR that waited until all files were read
in, would be to apply the DELETE command to it.
On the other hand, I agree about the 'chase the file' thing, and prefer the
way Colin Fox's FR does it… it fills the window, then leaves it alone
while more names are being brought in. If yo click on something in the FR
window, that's what gets selected. If you click on the scrollbar, it sorts
what is already in the list, and positions the list as per the scrollbar.
Moving the scrollbar while it loads makes it constantly update, but when
you let go of the scrollbar, the display freezes again.
-larry
I agree, of the FRs to date, I prefer the way Colin's handles the sorting
(I also prefer the 2 column display for getting at the device list).
Keith
I rather like the two-column method as well. Makes for easy movement.
-larry