topbanner_forum
  *

avatar image

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

Login with username, password and session length
  • Thursday March 28, 2024, 6:48 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

Author Topic: FARR Fscript question: Possible to use autocomplete with fscript results?  (Read 7773 times)

dreftymac

  • Supporting Member
  • Joined in 2008
  • **
  • Posts: 17
    • View Profile
    • Donate to Member
BACKGROUND:
Find+Run Robot
v2.30.01 by DonationCoder
working with custom-made fscript javascript plugin

QUESTION:
How can you apply the tab-autocomplete feature to fscript-generated
FARR results?

DETAILS:
I am custom generating a list of output results from a javascript plugin
using the really great plugin system. I would like to be able to autocomplete
and let the user press tab to make the completed suggestion appear in the
launcher input box. The steps below describe what I am trying to do.

STEPS:
- user enters the alias to trigger the plugin

    fooscript       <-- FARR user input box
   
- the fooscript plugin returns a long list of results
- the user types some text to narrow down the results

    fooscript base  <-- FARR user input box
   
- the result list now shows only those entries that have:

    1) the word "base" in the launch list; or
    2) the word "base" in the path string down in the FARR statusbar
    (both of these are generated by the fscript)
   
    For example:
   
    fooscript base  <-- FARR user input box
   
    play.baseball   <-- result list
    clean.basement
    base64.encode
    base64.decode
    insert.basename

- NEEDED: what i would like to do is allow the user to arrow down
    to one of the items in the filtered result list, and then press
    TAB. In the previous example, the user presses arrow down
    three times and then TAB to get this:
   
    fooscript base64.encode  <-- FARR user input box
   
RATIONALE:
The reason why I would like to do this is because the user
should be allowed to enter additional arguments before triggering
the command:
   
    fooscript base64.encode "hello world" <-- FARR user input box
   
    *The user would now press ENTER and the fscript will take the
     result and run the appropriate action*
   
ALTERNATIVE:
I notice that you can always right-click an item in the result
list and choose "copy path" ... the problem with this is it copies
the status bar text at the bottom, and I would like it to copy the
text from the result list instead. This way the user could copy
and just paste into the FARR user input box.

Does anyone know how to get autocomplete working this way?

TIA

phitsc

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 1,198
    • View Profile
    • Donate to Member
Pressing TAB will actually copy the selected item's path into the FARR search input box, i.e. what you suggest you could do by right clicking, selecting 'copy path' path and pasting. What keeps you from using 'fooscript base64.encode' etc. as your items' paths?

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
as phitsc points out, hitting tab puts the items "Path" in the search box -- so one solution would be to use the label as the path value for each item.

however the general thing you are asking for, has been asked for in a different form by others -- which is to let a plugin catch when certain keys or hotkeys or context menu choices are chosen for a particular result.  and i think the thing for me to do is implement this feature.  this would give plugins the ability to react to keypresses targetting a specific result and let them decide what to do about it.

dreftymac

  • Supporting Member
  • Joined in 2008
  • **
  • Posts: 17
    • View Profile
    • Donate to Member
Thanks guys,

phitsc, your suggestion makes sense, and it is an alternative approach that I did actually try, but abandoned.

The only real drawback (if you can call it a drawback, FARR really does an outstanding job as-is) is that
I am actually using the "path" as a command description with complete details, so the user sees something
like this:


'fooscript base64.encode'  <<<--- FARR launch input box

fooscript base64.encode ;; category: codec ;; this will encode the currently-selected text using base64 encoding <<<--- FARR status bar


That is, the status bar description (aka path) has a long-winded complete description of what the command will do before the user chooses it. This looks great when its down there in the status bar and only showing one-at-a-time when the specific command is highlighted, but it looks not-so-great (aka upside-down awful) when you populate the FARR results window with a bunch of these long-winded descriptions, and you put the short-winded text down in the status bar. The results become very hard to read and poorly aligned.

Incidentally, this option *would* be a great choice if I could get FARR to "clean up" the results window by putting the long-winded descriptions in a *grid* ... where the cells could be aligned and auto-determined by a user-configurable delimiter. (such as pipe or double-semicolon or whatever). That way, the FARR results window would still look clean and easy to use no matter how verbose the individual commands got.

Anyway, I know that the "grid" thing is also a feature that has been already talked about and slated for inclusion in FARR at some point (if time permits). 

Another great option would be the ability to copy-paste the the "short winded" text instead of the "long winded" text.

Nonetheless, I'm not complaining, FARR enables so much with what it has, these are really very minor limitations.

Hats off and thanks for the suggestions.

phitsc

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 1,198
    • View Profile
    • Donate to Member
You could try one of these two alternatives, see how you like them:

1. put the long-winded text, i.e. the full description in the FARR item group name field. This is the smaller text underneath the main caption. In FARR's display option it's the column called 'Location'. I could imagine you already tried that.

2. Do what you already tried, i.e. use this as the item's path:

fooscript base64.encode ;; category: codec ;; this will encode the currently-selected text using base64 encoding <<<--- FARR status bar

then, when the user hits TAB on one of the items the complete path with your description will be copied into the FARR search box and onSearchBegin will be called again. In onSearchBegin parse for one of your delimiters and if you find one, start a new search with setStrValue("setsearch", yourPathWithoutDescription). It might be a bit annoying that the whole description appears before it is cleared by your new search. Not sure if it will actually work, you'll have to try.

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
This is another example of where farr can help plugin writers with a simple new feature --
i'm going to add a call to plugins to let them know when user has HIGHLIGHTED a result item.  With this you could have your plugin manually set the statusbar however you want when the user highlights an item.

dreftymac

  • Supporting Member
  • Joined in 2008
  • **
  • Posts: 17
    • View Profile
    • Donate to Member
There's one thing I forgot to mention, another reason why the suggestions don't seem to work for me, it's the behavior of the TAB key.

Even though I have "tab autocompletes" turned on in FARR options, the TAB key doesn't behave for me the way you seem to be suggesting it should. What I get is the following (assuming the same example from before):

1) If the user has "fooscript base" in the input box, and the FARR command input box has focus, TAB causes the focus to change to the first result item with the first result item being highlighted. The text of the input box does not change, and remains "fooscript base" even if the user repeatedly presses TAB or the arrow up/down keys;

2) If the user has "fooscript base" in the input box, and the FARR results window has focus, TAB causes highlight to toggle on and off on whichever specific result item last had focus. The text of the input box does not change.

The alternate behavior that you mentioned (TAB causing the input text to change to the path) *does* work when FARR is generating windows file paths on its own, but this behavior does not carry over to the situation where an Fscript plugin is emitting the results.

Not sure if that's usual, or if something can be changed in the fscript to change the TAB key behavior, but there's that.

phitsc

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 1,198
    • View Profile
    • Donate to Member
On this line in your fscript.js file:

// type
UNKNOWN=0; FILE=1; FOLDER=2; ALIAS=3; URL=4; PLUGIN=5; CLIP=5;


add this:

ALIASFILE=7;

Then use ALIASFILE as the 5th argument in your emitResult calls (where you probably have FILE now).


As for my suggestion number 1 above: you can't currently do that with the WSH SDK. emitResult doesn't allow setting the item group field, fscript.dll has it hardcoded to empty string.