avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Wednesday October 5, 2022, 10:50 pm
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - jballi [ switch to compact view ]

Pages: [1]
Find And Run Robot / FARR window slowly increases height
« on: November 30, 2007, 11:59 AM »
FARR v2.00.145

I use FARR in the upper left corner of screen (fixed size).  I try to size the window so that it fits the maximum number of search values (9 for me).  I noticed that the FARR window get increasingly taller (not wider) the more I use the program.  The size changes are not immediate but after a bunch of runs the window will increase ever so slightly.  For me it takes 3 or 4 days of use before I say "Doh!" and resize the window back to the desired size.

Not a serious bug but I thought I would report it.

BTW, I use the LE4-Default skin just in case it matters.

Thanks for your attention.

sounds reasonable -- i'll add back the option to use tab as normal, and alt+tab for autocomplete.

taichi has earned himself several feature requests, so anyone who can get taichi to support their request will find it on the todo list :)

Thanks.  I think you'll make a lot of keyboard freaks like me a bit happier. :)

But and however, I'm fairly certain that you don't want to use Alt+Tab as an alternative to autocomplete since Alt+Tab already has a built-in system function. :o

Them be my thoughts...

yes, jbali this was a recent change.
my reasoning was that the down arrow key can be used in edit box to switch to results view, and escape from results brings you back up to edit box, so i thought we could use tab for autocomplete.

Thanks for the quick reply.

Any chance of adding an option to return the tab functionally back to way it worked before?  ...and/or allowing to user to determine which keys (or key combinations) will be used for what function.   For example: Ctrl+Tab for autocomplete.

I only make a fuss because I'm a big keyboard user and for a form of this type (Edit field followed by a List field), the natural way to navigate from the Edit field to the List field (at least for me) is the tab key.

Thank you for your consideration.


Please please please tell me, when did we stop using the tab key for navigation and started using it only for entering parameters!  I spent 20 minutes looking for a configuration parameter to return this function back to how it worked before but couldn't find anything.  It worked fine on the last version I tested (v2.00.083).

Hep me.  Everyone needs hep every once in while.


Edit:  Just for clarification...  For me the tab key would normally take to the first item in the list.  I would then use the up/down key for additional navigation.

Find And Run Robot / Re: Odd startup bug
« on: May 17, 2007, 09:12 PM »
Re: Odd startup bug.  Original post: https://www.donation...24.msg60160#msg60160

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.

Thank you for your interest.  I've delayed replying to your post because I wanted the bug to occur again several times so I could do some additional testing...

-Does the problem disappear when you press the ALT key?

No.  When in the middle of this "bug" (for lack of a better word), almost all input is blocked.  Like a stated earlier, the program acts as though the ALT key is being pressed down.  Pressing the ALT key doesn't change anything.

-When this problem occurs, go to another application (NOT by alt-tab) and press a key. Does the behaviour persist?
To be honest, I never thought to try to run other applications while FARR is running.  After all, there is no reason to have the FARR window active unless you want it to do stuff.

In a effort to track down this problem, I did have an opportunity to give this a try and... When I clicked to other windows and did stuff (no input block problems) and returned back to the FARR window, the input block was gone.

Just thought I'd point out that it's not necessarily FARR's fault and it could be windows or even the keyboard.
At this point there is no definitive proof that this is a FARR bug/problem.  However, since this idiosyncrasy only occurs while the FARR window is active (no problems with any other windows, ever), I have to conclude that this is probably a FARR bug.  Of course, if no one else experiences the problem and/or the bug cannot be reproduced, there is not much that can be done.

Thank you for your consideration.

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


Find And Run Robot / Re: Odd startup bug
« 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.


This is in reference to the bug I reported with FARR v1.13.02.  Here's the post:

    Odd bug after using Numpad key to launch shortcut

Anywho, back in January, you sent me a message to try the new release of FARR to see if the bug was still there.  Although I check the forum every once in a while, I just now noticed the tiny "You have 1 message" link.  Sorry, I didn't know to look for it but now I do.

I just downloaded the lasted alpha release and gave it try/see.  Unfortunately, the problem persists.  With v2.x, the problem occurs when a shortcut or folder is selected.

Thank you for your consideration.  Please let me know if you need any additional information.


I have selected and use "Numpad keys launch results from search window" option/feature.  Under most circumstance this feature works without a problem.  However, every once in a while the number I selected from the results list is automatically preloaded in the search box the next time FARR is started.  For example, if I hit the Numpad 7 key to launch an application/URL, the next time FARR is started, the number 7 is preloaded in the search box.  Freaks me out every time it happens.

It took me a while but I was able to consistently duplicate the problem although I don't know if anyone else will be able to.  I don't know if it is in the name or the type of shortcut/URL that is being launched.  The one URL shortcut that I use to duplicate the problem is named "Internet Speed Test" and it points to the following URL: http://www.auditmypc...ernet-speed-test.asp.  This is just one of several shortcut/URLs that produce the problem.

Thank you for your consideration.

Find And Run Robot / Re: Alias sharing
« on: March 25, 2006, 02:53 PM »
By request of jgpaiva

Discovered these by trial and error.  Artist search included by default with recent versions of FARR.

Artist Search:

Album Search:

Song Search

Style Search:

Label Search:

P.S.  The correct search parameter delimiter for this command "appears" to be the OR symbol: "|"  So, if searching for Billy Ray Cyrus (I'm not sure why you would), you would enter (sans quotes) "Billy|Ray|Cyrus" as your search parameter.  I found this by trial and error.  If anyone has more correct information, please post!

Never mind.  Figured it out.

Album Search:

Song Search

Style Search:

Label Search:

Recent versions of FARR include an alias for searching  The exact alias definition is:

  AMG - Artist $$1 | http://www.allmusic....g.dll?P=amg&sql=$$1&x=0&y=0&opt1=1&sourceid=mozilla-search

This command will do an artist search.

Question: Does anyone know the syntax for an Album and/or Song search?

Thanks in advance for your feedback.

Find And Run Robot / Re: version 1.07.10 is now up
« on: September 16, 2005, 11:09 PM »
I concur.  Good stuff!   :)

I just wanted to add my 2 cents to this topic.

I too, have been struggling with this issue.  Ok, "struggling" may be too strong of a word.  Instead of multiple users, my issue is multiple computers -- in effect, making the software more portable.

Would it make sense to somehow, someway, allow the use of standard environment variables when defining Search folders?  Instead of defining the following search folders...

    C:\Documents and Settings\Ricky\Desktop
    C:\Documents and Settings\Ricky\Start Menu\Programs
    C:\Documents and Settings\All Users\Start Menu\Programs
    C:\Documents and Settings\Ricky\Favorites
    C:\Documents and Settings\Ricky\Data

you might define the following:

    %userprofile%\Start Menu\Programs
    %allusersprofile%\Start Menu\Programs

If you log in as Ricky, you'll get Ricky's stuff.  If you log in as Lucy, you'll get Lucy's stuff.

This will work with multiple users and for the most part, multiple computers.

Them be my thoughts.

Interesting link.  I think I now know more than I should.

I tried the new version on a few good and bad (I edited them) URL shortcuts.  They all went to the correct address.

Thanks for your help.

Just installed 1.07.07 although this may have been an issue before this version.  I searched through the forum and couldn't find a thread on this issue.

I have a URL shortcut in my Favorites to the Portable Freeware Collection web site (several DonationCoder programs listed on this site).  The URL is:

When I launch the shortcut manually, everything is honky-dory.  Do people still say "honky-dory?"  However, when I launch the shortcut using F&R, it takes me to the following location:

This confused me to no end until I edited the shortcut with a text editor.  This is what the shortcut contained (minor editing):

-- Snip --

I went through a few dozen of my web shortcuts and found several where the BaseURL did not match the URL.

I have no idea what the BaseURL is used for but shouldn't F&R use the URL instead of BaseURL to launch to a web site?

Thanks in advance for your assistance.

Files sent.  Let me know if you need any additional information.

Thanks for your assistance.

Found this thread after I experienced this problem again.  I hate to admit it (since I like the program a lot) but I experience this problem a lot more often than I would like.

For me, the EAccessViolation error is an indication of a corrupted configuration file.  I detest doing it but I make a copy of a valid configuration file so that I can quickly recover from this error.  I've found that the more often the configuration is updated, the more likely it will become corrupted.  For this reason, I've stopped adding launched files to the launch history, don't maintain a launch history, don't use aliases, and any time I make major changes to the configuration, I make a copy.  Since I've changes, the configuration file becomes corrupted much less frequently.

Currently using v1.05.21.   I also experienced the problem with an earlier version, I forget which one.

One thing that I do that others may not...  I launch F&R from a hotkey (AutoHotkey script).  I don't use the F&R System Tray Trigger.

Just installed v1.09.01.

The program works well with standard executables (.exe) but for some reason, the program no longer likes double quotes around parameters when executing batch files.

For example, when I run this test:

C:\Program Files\bin\Test.bat %F1 "%2"

I get the following error message:

The filename, directory name, or volume label syntax is incorrect.

This is the most common error that occurs.

I get a similar error message when I run this (just an example):

C:\Program Files\bin\LAME.bat --decode "%N" "%NO.wav"

...returns this error message:

'C:\PROGRA~1\bin\LAME.bat" --decode "Test.mp3" "Test.wav' is not recognized as an internal or external command, operable program or batch file.

When I remove the double quotes from the parameters, these errors go away but of course, the programs don't work if the path or file name has spaces.

Thanks in advance for your assistance.  Let me know if you need any additional information.

Drag&Drop Robot / Re: any drag&drop users?
« on: August 14, 2005, 04:31 PM »
Thanks for the reply.  It looks like exactly what I was looking for.  I'll give it a try/see.  Thanks.

Drag&Drop Robot / Re: any drag&drop users?
« on: August 14, 2005, 12:33 AM »
Thanks for the reply.  I'll look forward to what you decide to do about return codes.  The only thing that I wanted was is for D&D to display a message in the Output Window when an error is found (good).  That way I can go back through the output to find the problem.  In addition to the error message, you might consider adding an option to stop processing (and beep maybe) when an error is found (better).  That way I can deal with the problem when it occurs.

I have tried and do use RazorLame fairly regularly.  It's a little out of date (hasn't been updated for several years) but as long as you know how to get around the outdated stuff, it works great.  Also, it does support drag & drop.

Let me apologize in advance for the verbose nature this section.  Sorry 'bout that.

In response to your question, I apologize for the way I worded the situation.  I could have been clearer.  I'll give it another try...

The issue doesn't really relate to basic encoding -- converting a WAV file to an MP3, it relates to converting or re-encoding an MP3.  Say you have an MP3 encoded at 320 kbps and you want to load it to your portable MP3 player.  Relatively speaking, an MP3 encoded at 320 kbps is huge!  To save space, the best thing to do is convert the MP3 to a more reasonable bit rate.

Because you are converting or re-encoding an MP3, the target file name is the same as the source.  If you are lucky, LAME or RazorLame will catch it and stop you from overwriting the original file.  I say lucky because under certain conditions (wacky target folder definition), LAME does not realize that the source is the same as the target and will overwrite the source file while it is processing it.  Needless to say, the source file is destroyed.

Of course there are work-arounds.  The most obvious work-around is to define a different target folder.  My issue with that is that I've got an infinite number of source folders.  What came from where?  What if I want to put the converted file back in the original folder?  Which one was it?  Another work-around is to convert to an MP3 with a static name, delete the original, and rename the converted MP3 to the original.  My issue is that I want to keep both the original and the converted file.

My solution is to add a static tag to the 1st node (everything before the first . (dot)) of the file.  For example, an MP3 with the file name of "Heart - Magic Man.mp3" would be converted to file with the name "Heart - Magic Man (128).mp3"

With D&D, I can add a static string to the fully qualified file name (not worth much in this case) or to the end (changes .mp3 to something else) but I can't prefix or append anything to the just the file name.  This issue is not just with LAME or other MP3 encoders, it's any program that converts a file type to the same file type and you want to do it in the same folder as the source.

If you think it makes sense, you might want to consider adding a %3, %4, and %5 options to represent the unqualified file name (full file name without the qualified path), the file name only, and the extension only.  I'm sure that others will find these options valuable.

Thank you for your consideration.  Once again, I apologize for the verbose nature of this post.

Drag&Drop Robot / Re: any drag&drop users? - Error codes
« on: August 13, 2005, 07:32 PM »
I finally found a use for D&D (DDR or D&DR?) - LAME encoding.  Unfortunately, I had to write my own batch script to do most of the work since there are way too many options and D&D doesn't offer the option to just manipulate the 1st node of the file so that source and target files are different when converting MP3 to MP3.

Anywho, so far it's working well.  It saves me some time when converting a lot of stuff in many different folders.

One thing I noticed is that D&D doesn't identify (or care) about return codes from batch files.  Is this by design or am I doing something wrong?

Thanks in advance for your feedback.

Pages: [1]