ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE.

DonationCoder.com Software > Find And Run Robot

Latest FARR v2.00.140 ALPHA PREVIEW Release - Aug 15, 2007

<< < (150/173) > >>

justice:
Actually I think it's perfect in build 133, the delay is not in the input box but only in the result view, which means in total the app is speedier. I guess it's similar to how browsers build up webpages, some wait till the page is complete, some build them up every so often, and really old ones show all the content jumping up and down  :)

nitrix-ud:
Yes, the result display is better. But the feel of unresponsiveness is not because of the result display but because of the display of the keys as I type them (just that one line). The user should never have any doubt whether her keystrokes have been received... or worse, be in any doubt about what keystrokes she has already typed. When a keystroke is received, top priority should be to update this line.

Mind you, this is really borderline, really close to perfect, just not quite.
--- End quote ---

exactly what i wanted to say, thanks jdmarch  :Thmbsup:

jack99999:
i found the performance problem with including Desktop in the search.

i had a shortcut that went to something like:

     \\DeadComputer

i deleted the shortcut and the performance problem disappeared. everything is just super now!

jack

TucknDar:
But the feel of unresponsiveness is not because of the result display but because of the display of the keys as I type them (just that one line). The user should never have any doubt whether her keystrokes have been received... or worse, be in any doubt about what keystrokes she has already typed. When a keystroke is received, top priority should be to update this line.

Mind you, this is really borderline, really close to perfect, just not quite.
-jdmarch (July 18, 2007, 04:41 AM)
--- End quote ---
Have to agree with this. FARR is such a great app, and some excellent new and improved features, but the slight delay is a bit annoying. Could the behaviour be optional?

jdmarch:
mouser, a multi-layered problem using FARR to run "add-remove program" (ARP).

1. FARR's ARP link doesn't work for me, either from FARR or directly from explorer. When it's invoked, nothing happens.

2. FARR's other CPL links seem to work fine, which is puzzling to me since (browsing their guts) they all seem to point to C:\WINDOWS\.... which does not exist on my system (my system is in D:\WINNT\). I guess Windows is smart enough to translate C:\WINDOWS to the actual system dir.

3. I have my own shortcut to ARP (it refers to D:\WINNT\...) which works fine from explorer but does not work from FARR (FARR finds it ok but when it is invoked, nothing happens, just as with FARR's own shortcut.) I reported this 3 months ago. At the time, you informed me that FARR now provides a full set of control panel links. From my response at the time, it appears that I was then able to run ARP using the FARR shortcut, but I don't actually remember this, and I'm not sure I really believe it given the above.

I'm running Win2K SP4.

Thanks!
====
Edit: Further investigation... this does not seem to be a FARR-specific issue. I wrote a batch file which invokes my own ARP link. If I call the batch file from within a command-line window, ARP starts, but if I invoke it from explorer, it does not. So there's something very screwy on my system about within what context ARP will start or not. I will not be able to spend much time investigating this further, unfortunately.

P.S. Could somebody else who runs Win2K on drive D: please try starting ARP using FARR's CP shortcut?

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version