topbanner_forum
  *

avatar image

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

Login with username, password and session length
  • Friday March 29, 2024, 5:35 am
  • 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 v2 plugin issue - locking behavior when plugins delay results  (Read 4453 times)

ecaradec

  • Honorary Member
  • Joined in 2006
  • **
  • Posts: 410
    • View Profile
    • Blog & Projects
    • Read more about this member.
    • Donate to Member
I'm not sure if there is a thread for plugin maker to ask questions :
I have the impression that calling ExecuteCallback_SearchStateChanged does not cause farr to update results if the plugin does not change state simultaneously. Does calling ExecuteCallback_SearchStateChanged is the right way to have farr to update its results list ?
On my delicious plugin, the results appear much faster when the current state is set to stop and ExecuteCallback_SearchStateChanged is called than when ExecuteCallback_SearchStateChanged only is called.
Blog & Projects : Blog | Qatapult | SwiffOut | FScript

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
FARR v2 plugin issue - locking behavior when plugins delay results
« Reply #1 on: January 01, 2008, 01:13 PM »
ecaradec, i'll split your question off into another thread after i answer it a bit.
we should probably have sdk questions as their own threads, but titled so they can be identified as such (e.g. "SDK Question: blah blah")

ok now to your question..
i'm not 100% sure what you are asking, could you be a bit more specific?
maybe it will help if i explain a little bit about how farr works with plugins and results.
before farr does any searching of it's own it calls the plugins and tells them the search.
then it checks if any plugins have results right away, and if they want farr to stop searching immediately.
most plugins respond at this point since they can return results without delay, and normal farr searching never proceeds.
but some plugins may need an extended time to search, and may want farr itself to be able to proceed and find files on its own.  for example if you had a plugin that searched online or and index, BUT still wanted normal results displayed.  in this case a plugin can let farr continue searching while it works, and send results as ready.

but again, i'm not 100% sure what you are saying works faster than what.

ecaradec

  • Honorary Member
  • Joined in 2006
  • **
  • Posts: 410
    • View Profile
    • Blog & Projects
    • Read more about this member.
    • Donate to Member
FARR v2 plugin issue - locking behavior when plugins delay results
« Reply #2 on: January 04, 2008, 12:17 PM »
In this case a plugin can let farr continue searching while it works, and send results as ready
This is the case for the delicious plugin. I send results after reading the cache firstly and a second time when I receive the server answer if the cache was not up to date and that new results are availables. Because of this I only set the search state to stop once the server has answered.
I tell FARR that new results are available by calling ExecuteCallback_SearchStateChanged, but results are only displayed after I set the search state to stop.
How often does FARR display intermediates results ?

PS : Could you move the messages to another thread mouser ?
Blog & Projects : Blog | Qatapult | SwiffOut | FScript
« Last Edit: January 04, 2008, 12:21 PM by ecaradec »

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 you know i have a new FARR release that i have been working on, focusing on plugin writer requests and issues -- i'll put it up in the next couple of days and i will look into this before i do.