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

<< < (110/173) > >>

mouser:
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:
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)
--- End quote ---
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:
well if the cursor is blinking in the edit box then it has focus and that's not the problem.

QuickBrownFox:
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.
--- End quote ---

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:
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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version