Author Topic: Latest FARR v2.00.140 ALPHA PREVIEW Release - Aug 15, 2007 (Read 634353 times)

mouser · « **Reply #525 on:** April 30, 2007, 06:13 AM »

great idea gottadoit - this would be a nice idea for a plugin.

rjbull · « **Reply #526 on:** April 30, 2007, 06:17 AM »

i'd like to hear feedback regarding whether the large icon display mode should be default.
-mouser (April 27, 2007, 05:59 AM)

I'd rather have "small icon" mode. But as long as you can switch it, OK...

ecaradec · « **Reply #527 on:** April 30, 2007, 07:28 AM »

It would be good if we could (optionally) have FARR add in program entries for things directly executed by explorer
Explorer makes this relatively easy by default by storing a record of programs that have been executed in some registry keys
-gottadoit (April 30, 2007, 05:45 AM)

I'm not sure if this is exactly what you want : Windows maintains a 'recent document' folder with shortcuts to recent files opened with Explorer. You can add it to the search directory of FARR. It is located into "C:\document and settings\%USERNAME%\My recent documents"
You can also tune the numbers of items Explorer should keep but I forget how. Probably a registry key.

mouser · « **Reply #528 on:** April 30, 2007, 07:34 AM »

oh yeah i forgot i already added that recent docs to default search paths

heheh, ok no need for that then, just the recent programs launched then.

Kosinus · « **Reply #529 on:** May 01, 2007, 11:01 AM »

I just received this display, beware the differing path display in the status line and item line. FARR version is 2.00.82.

mouser · « **Reply #530 on:** May 01, 2007, 11:06 AM »

thanks Kosinus, looks like a bug for sure.

gcharron · « **Reply #531 on:** May 01, 2007, 02:58 PM »

Great App!!

a few observations (Find+Run Robot v2.00.82):

1. Once an application has been launched from FARR and later closed- the parent folder can not be delete until FARR is closed.
2. Unable to locate where to configure the command line to appear at the bottom of the FARR window instead of the top

Thanks Again!!!
Gilles

mouser · « **Reply #532 on:** May 01, 2007, 11:17 PM »

gcharron, i'll look into #1 that sounds annoying and i can't think of why it should happen.
as for #2, i removed the option as it became painfully hard to get that display to look right with the edit box at the bottom.. i may try to bring it back eventually if people really want it, but only after i finish the code that let's user customize font for editbox..

ps.
i agree with everyone about getting farr v2 into release candidate and public testing, i just want to make sure i have the fundamental stuff updated so people can create plugins and share aliases without having to worry about painful upgrading.

i've spent the last week completely reworking the way aliases are saved. they are now saved in multiple xml files, so that it will be super easy for people to create and share and update various alias files, while also maintaining their own custom aliases, and not worrying about them being overwritten, etc.

cnewtonne · « **Reply #533 on:** May 02, 2007, 08:33 AM »

Mouser,
great news for great work.
I would like to ask that you take a look at performance too. Alias searches are becoming more and more slow as I add them. Sometimes it takes 2-5 secs for results to display. I know you have plenty on your plate, just take a look when you get the chance.

jdmarch · « **Reply #534 on:** May 02, 2007, 09:20 AM »

Mouser, this may not be an issue for new users, perhaps just for folks converting up from previous versions, but I encountered a small issue with the sizing of the Edit Group/Alias dialog. Presumably its size on my system had been remembered (from a previous FARR version with fewer fields in the dialog) as shorter than is now permitted. As a result, the dialog was shown at the current minimum height, but the Results field contents were completely invisible, and completely unscrollable. The only indicator that there was anything in the Results field was that I could do Select All / Copy, then paste to an editor to view the field contents. When I resized the dialog up and then back down to minimum height, the problem did not recur.

Several thoughts:
* seems like there is some subtle size dependency failure when the dialog height is memorized as being smaller than the current minimum height.
* Perhaps it would help if the dialog minimum height were a little taller than now so that the Results field was always at least 2 lines high. (This might also help with clarity, emphasizing to the user that this is a multi-line field, and unless you are planning a cell phone version, shouldn't be a problem with anyone's screen size.)
* It would help with clarity if there were an explicit resizing grip at the lower right corner.

Thanks!

mouser · « **Reply #535 on:** May 02, 2007, 09:31 AM »

cnewtone, there is no way it should take that long, some bug must be slowing farr down (like when it somehow gets delayed checking for the existence of a network file). can you email me your FindAndRunRobot.ini file? or actually you might want to wait until i release the next version which completely changes the way aliases are stored before you do.

jdmarch thanks for pointing that out, i will improve it.

jdmarch · « **Reply #536 on:** May 03, 2007, 06:30 AM »

Hmmm, am I doing this wrong or is this an issue? I just entered a search word. Most of the results were in D:\WINNT\TEMP, which I did not want. D:\WINNT\ is on my search path, but I didn't want its TEMP subfolder to be. So I added D:\WINNT\TEMP\ to Search Folders with a score of -9999. Made no difference whatsoever, whether I put it before or after the D:\WINNT\ entry.

mouser · « **Reply #537 on:** May 03, 2007, 08:05 AM »

jdmarch, add D:\WINNT\TEMP\ with score of -9999 to your "Pattern Scooring" list, not your Search Folders list.

jdmarch · « **Reply #538 on:** May 03, 2007, 09:26 AM »

Thanks, mouser. Actually shouldn't it be d:\winnt\temp\* ?

But it isn't only that I didn't want those results to show up - I don't even want FARR to waste time searching the temp folder and its subfolders. Or is it smart enough to do that when it sees the above pattern exclusion?

mouser · « **Reply #539 on:** May 03, 2007, 09:41 AM »

Or is it smart enough to do that when it sees the above pattern exclusion?

right exactly. it wont go into that directory at all -- BUT!!! -->
don't do "d:\winnt\temp\*" or "d:\winnt\temp\*.*"

as that WILL confuse it into looking into the subdirectory before eliminating.

jdmarch · « **Reply #540 on:** May 03, 2007, 11:04 AM »

Doesn't seem to work. If I don't include the wildcard, it doesn't exclude the files.

But wouldn't it be more consistent to have directory exclusions on the same page as directory inclusions, rather than on the page with pattern scoring?

mouser · « **Reply #541 on:** May 03, 2007, 11:33 AM »

But wouldn't it be more consistent to have directory exclusions on the same page as directory inclusions, rather than on the page with pattern scoring?

yes, i will think about doing this. it would make it more efficient too. in this thinking, each directory listed would also have:
1) checkbox for saying whether to search recursive, and perhaps a recursion depth limit.
2) list of sub directories to exclude

jdmarch · « **Reply #542 on:** May 03, 2007, 11:38 AM »

Sounds like a good plan. A recursion depth limit would not usually be needed, but I can think of some places where it would be useful.

cnewtonne · « **Reply #543 on:** May 04, 2007, 10:45 AM »

Mouser,
I was playing with FARR and accidently changed the skin I was using 'slenderfarr'. Soon I did that, the issue described earlier is gone. Alias searches are no longer slow and I'm happy with it now. However, I hit a new strange issue that I was able to duplicate on my existing install as well as a fresh one i.e. renaming my existing ini file. I have a search folder for 'my documents' with a modifier listed as 'md'. When I search using '+md budget', for instances, FARR hangs and turns blanco for about 5-7 seconds and eventually search results display. If I search using 'budget +md' it works fine with no delays. I have several modifiers and it looks like it only happens with the +md one if you start with the modifier first.

Can you confirm this behavior please.

jballi · « **Reply #544 on:** May 04, 2007, 07:30 PM »

v2.00.83 (and previous)

This a wacky but seriously irritating (at least to me!) bug that I haven't reported earlier because it is somewhat difficult to duplicate and I don't know exactly what triggers it. I've discovered some additional information so I decided to report it hoping that someone else besides myself has experienced it.

Every once in while, I start FARR and I'm not able to type anything at all. For me, the computer just beeps every time I type a character. The only way to get out of "input barrier" loop is to hit the Escape key or click on the Close button and restart FARR. I don't actually restart the program. The FARR window is closed and then reactivated when I enter the FARR hotkey (Ctrl+Alt+Break for me).

Stay with me...

I recently discovered that when I type certain characters (while this bug is occurring), the computer doesn't beep. For example, when I type the letters "A" or "C" the computer doesn't beep. This gave me a clue that the program was attempting to receive a keyboard shortcut. Out of curiosity I typed the letter "O" -- the "Options" dialog popped up!

Long story not so long. When this bug is occurring, it is the equivalent of the ALT key being pressed down while you're typing. Only keyboard shortcuts (or other ALT-based hotkeys) are active.

Like I said, this bug is difficult to duplicate. I would estimate that this bug shows it's ugly head 1 out of 15 to 20 runs. I think that something from a previous run triggers it but so far, I haven't been able figure out what.

Thank you for your consideration.

mouser · « **Reply #545 on:** May 04, 2007, 07:33 PM »

is it possible that what's happening is farr is coming up but is not focused?
do you see the cursor blinking it its edit box? if you put the cursor in the box and click does it work?

jballi · « **Reply #546 on:** May 04, 2007, 07:50 PM »

is it possible that what's happening is farr is coming up but is not focused?
do you see the cursor blinking it its edit box? if you put the cursor in the box and click does it work?
-mouser (May 04, 2007, 07:33 PM)

It's very possible that wrong object is in focus when the window is initiated but putting the edit box into focus doesn't fix the problem while this "bug" is occurring. Yes, I see the cursor blinking in the edit box. I don't remember for sure if I've put the mouse cursor in the box and clicked on it but I'm fairly certain that I have.

Thanks.

mouser · « **Reply #547 on:** May 04, 2007, 08:02 PM »

well if the cursor is blinking in the edit box then it has focus and that's not the problem.

QuickBrownFox · « **Reply #548 on:** May 05, 2007, 05:00 AM »

Long story not so long. When this bug is occurring, it is the equivalent of the ALT key being pressed down while you're typing. Only keyboard shortcuts (or other ALT-based hotkeys) are active.

The mysterious holding down of ALT is a classic problem that I used to get a lot in windows before XP. Now it just happens to me every year or something. I notice that your FARR shortcut has an ALT in it so pressing that could start and stop the odd behaviour.

-Does the problem disappear when you press the ALT key?
-When this problem occurs, go to another application (NOT by alt-tab) and press a key. Does the behaviour persist?

Just thought I'd point out that it's not necessarily FARR's fault and it could be windows or even the keyboard.

None of this explains the beeping of course so I may be totally wrong but try it out anyway. =]

QuickBrownFox · « **Reply #549 on:** May 05, 2007, 05:25 AM »

I don't think this bug has been posted before:

Typing parts of aliases breaks non-contiguous matching

This is some strange and unpredictable behaviour that I found in v2 that I'm not sure if you'll be able to reproduce but here goes:

1. Type the first part of some alias for example: "wi", which is part of the wiki alias.
2. Type a space.
3. Now type another letter that should bring a result on your system but is not "k" or "i". Putting an "n" should suffice for most people.

Results should show every that contains "win" (at least) but there are no results and the status bar says "Searching partial aliases..." and doesn't change if left for a long time. This behaviour doesn't occur if the aliases are disabled which is what I've done for now.

I've just noticed that while in this state, FARR uses >90% of cpu power on my system. I never thought to check this before because it still feels perfectly responsive to the keyboard and mouse.

Also, I just thought I'd mention that many of the statusbar tips in the options are wrong and the "Check full path for search words..." option in the General tab doesn't appear to change anything or I can't figure out what it does. I know it's still beta and you've probably just not got round to the polishing but I just wanted to make sure you're aware.