avatar image

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

Login with username, password and session length
  • November 15, 2019, 12:19 PM
  • Proudly celebrating 13 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 - herojoker [ switch to compact view ]

Pages: prev1 [2] 3 4 5next
Find And Run Robot / Re: Please Help! Alias disappears
« on: August 13, 2008, 06:33 PM »
As I said, please try experimenting with "Stop search on regex alias match"; this might be the cause here.

Find And Run Robot / Re: Please Help! Alias disappears
« on: August 13, 2008, 06:49 AM »
Please look into the alias definition. Perhaps there is a regular expression, matching to "wet" but not "wett".
Furthermore you should experiment with the options "Stop search on exact alias match", "Stop search on regex alias match" and "Score non-contiguous matches".

Find And Run Robot / Re: Search and Alias history
« on: August 11, 2008, 05:04 AM »
The history is already persistent among restarts. Just booted my machine, all entries are still there.
Some options regarding the history is available at "Search Behavior" (just in the case you didn't see it yet).

Find And Run Robot / Re: Alias/command to search a set path
« on: August 09, 2008, 04:04 PM »
If you don't want to enter the modifier each time, you can create a new alias which uses dosearch or restartsearch (see help file for more information).

@d4ni: It is an option, called "Score non-contiguous matches" on the "Search Behavior" page.

Another plugin idea: Searching for songs via meta data.
For example MP3 files may have so called ID3 tags which contain information like Album Title, Track Number etc.
I have no idea whether it takes much performance to search for a given text in many MP3s but perhaps it's possible. Creating an index is possible too (many music players do that, then called Library or something similar).

I don't think so...

Find And Run Robot / Umlauts in file browsing...
« on: July 24, 2008, 01:51 PM »
I tried to browse into some of my folders but the program fails when it comes to umlauts!
See the attached screenshot.

Another example:
Entering "aufge" returns the folder "_Aufgenommenes": "I:\Öffentlich\Musik\_Aufgenommenes\" and pressing enter opens the folder.
BUT if press the Right arrow key after selecting the entry FARR goes [as desired] into file browsing mode but NOW [see screeny 2] pressing Enter doesn't do anything.

FARR Plugins and Aliases / Re: Screenshot aliases using MiniCap
« on: July 24, 2008, 01:13 PM »
Ah :D
To have a clean installation I moved the directory to the proposed directory (surprise: it still works  ;) )

FARR Plugins and Aliases / Re: Screenshot aliases using MiniCap
« on: July 24, 2008, 01:08 PM »
Mmh, I just put it in plugins and it works!

Find And Run Robot / Re: Hotkeys & FarrQuickView
« on: July 24, 2008, 07:05 AM »
"Global" hotkeys are already there. The currently selected text is available via %cliptext% and "Copy selected text" (see Preferences > Lists > Hotkeys).
You can find an example in the screenshot which is appended.

FARR Plugins and Aliases / Re: Locate32 Plugin for FARR by Okke
« on: July 23, 2008, 07:16 PM »
I think that's not the problem sosimple wanted to point out.
It shouldn't be possible to run into such a loop!

Hehe, more than one time I caught myself trying to reopen FARR by pressing CTRL+Space (that's my "bring FARR up" combination) with the aim to enter "robot"... d'oh!

Ah, ... I wrote non-sense :D
I meant: If the desired option is there one could avoid writing +external / +internal by creating a new alias using dosearch. (Ok, that's obvious...)
Forget it  :-[  :'(

BTW: Isn't Google blocking people who start too many searches in a short period of time?

I think you can already do this with the "dosearch" command and additional aliases.

Find And Run Robot / Re: Updates: Patches?
« on: July 21, 2008, 10:23 PM »
Aah, you just mentioned the obvious third possibility:
Complete files are downloaded if they are new, but only new ones (I had only direct (binary) patching of the files in my mind before).
This process can be simplified if the patches I mentioned before are replaced by simple text files containing the files changed or added.
For example:


These files could then be downloaded from a certain directory on the server.

Of course there are again many ways to build the whole system:
1. Patch files only from one version to the next one
2. Patch files created on demand from arbitrary versions to others (only one time for each patch)

If the first way is used the updater should first collect every patch file from the current version up to the desired target version (cumulative; skipping doubles) and then do the work. This way a patching cascade is avoided and also the server load is not so high. Only a bit space is needed for all the different versions. If mouser installs a versioning system even this is not a problem anymore (because internally only diffs are stored).

Perhaps a mix of the download-whole-updated-files approach and the download-binary-patches approach may be useful, because I guess it is the FindAndRunRobot.exe which is updated most oftenly and this file is quite big (currently 3.81MB), a binary patch will be probably much smaller.

Find And Run Robot / Re: Updates: Patches?
« on: July 21, 2008, 11:13 AM »
@jgpaiva: That's why I mentioned automatic patch generation... Person A has an old version for which no patch exists yet, so it's just created on the fly with help of the repository. It should just be a binary patch! You don't even need automatic building[compiling] here!
I now see that there isn't even a (classical) repository needed (like SVN or CVS) but only all previous FARR versions. One could also limit the number of previous versions to, let's say, 20 or so. All older versions cannot be patched and a complete download is needed.
Additionaly all old patches might be deleted, so there are only 20 patches online.

To sum up the scenario:
First possibility: The server contains all FARR versions, if a patch request comes in, the desired patch is (if not already there) created (automatically; a binary diff?), the url to the patch is returned.
Second possibility: The server contains only a certain amount of FARR versions and all patches from older version to the newest (or to some major/security/... builds) are stored (created offline, then uploaded by mouser?), if a patch request comes in, the url to the patch is returned.

Of course mouser could freely change the parameters I used in the second possibility (and there may be many more ways to do it).
I think the latter way is not so difficult to do but the first one is quite flexible  ;)

@mouser: Oh, ... yes. It would definitely need some changes :) But it could also simplify your whole work process.
I have automatic patch generation (in the 2nd case) and uploading, and an automatic post in the update thread (based on the changelog) in my mind... Writing a program which does this could be used for all your apps!

The first case would reduce the work you have to do because patches are created on the server side (don't know your infrastructure).

Find And Run Robot / Re: some suggestions about FARR
« on: July 21, 2008, 11:00 AM »
Yep! It works for me, but it might not do so for others (in the desired way) because you ignore the options "Always launch first result on hitting Enter" and "If there is only one result, launch it when hitting Enter".

Find And Run Robot / Updates: Patches?
« on: July 21, 2008, 10:43 AM »
To reduce server load creating patches (instead of having to download the whole package again) might be quite useful!
I assume you use a versioning system, so creating patches (even on the fly, at the first request) should be easy.

This leads to the following request:
Allow aliases to have place holders to be filled by other alias' or commands results.
This means: Instead of $$2 or something you could write ${restartsearch new input} which would cause a new (virtual) instance of FARR to appear with input "new input". Somehow also certain plugin functions could be used this way.


my_alias: Hey, that's it | run ${restartsearch $$1 +somefolders}/bar.exe

which would do the following (I hope so):

1. I enter "my_alias foo" and press enter
2. The input is replaced by "foo +somefolders"
3. I see a list of results (assuming that +somefolders is a modifier which causes only music folders to be displayed)
4. I choose a certain folder, e.g. "C:/this_is_so_foo"
5. Technically the search returns to the alias, which would add "/bar.exe" and then run it:
6. run C:/this_is_so_foo/bar.exe is executed

If there were more ${...} parts these would have been opened before executing the command.

I guess the implentation of this might be much easier if the command stack I mentioned in some suggestions about FARR would be implemented first.

I see that problems with recursion might occur here. Perhaps there should be a depth limit (the user himself could set it).

Find And Run Robot / Re: some suggestions about FARR
« on: July 21, 2008, 07:29 AM »
Notice my updated answer...

Find And Run Robot / Re: some suggestions about FARR
« on: July 21, 2008, 07:06 AM »
Hmm, it would be ok but using the option "Always launch first result on hitting Enter" seems to be more appropriate.
IMHO FARR should behave exactly as the user had manually entered the text and pressed enter. From a coder's point of view: The actual launching process shouldn't be different! For example the way how FARR is started causes FARR to add/replace some text to a $variable (IIRC there is an option to automatically insert the last used command; this should use the same mechanism! It's your work to determine the priorities).
Then the contents of $variable until the first \n (or if not present the end of $variable) are inserted into the input (which automatically causes the search) and if a \n was present the Enter key should be simulated.
Perhaps you could realize this with a kind of command stack on which you store the actions to do (if you use object oriented programming you can use objects containing commands to execute).
Split $variable into certain tokens, then process these tokens one after another: Normal text adds TextInput to the stack, \n causes cancelling the token processing and adds WaitUntilReady and LaunchResult to the stack.
Then run all command objects stored on the stack...

Find And Run Robot / Re: some suggestions about FARR
« on: July 21, 2008, 06:43 AM »
Mmh, this seems to work only when the used alias group has only one entry.
Example: I have groups called "maps" and "transl", the first contains only Google Maps currently, the second contains several translation services.

I created a hotkey with text "maps %cliptext%\n" and "transl %cliptext%\n".
The first one immediately opens google maps with the selected text, the second one remains on the alias group list; I have to press enter to get a result.

In my opinion the first result should be launched automatically if the corresponding option is set (the first one of the following).

"Always launch first result on hitting Enter", "If there is only one result, launch it when hitting Enter" [ok, the latter doesn't change the behaviour here], "Stop search on exact regex match" are on, "Stop search on exact alias match" is off (no combination of the last two options changes the behaviour).

Pages: prev1 [2] 3 4 5next