Why need I hit enter twice?

Well logically you have to select an option, and then you have to submit the form. I use my mouse to do this so I never press enter.

I think every autocomplete in drupal works like that to be honest.

You could probably make the form submit using javascript when a value is prefilled to take out the manual submit step. Might be able to write your own jquery to do that? I question whether users would appreciate that, as they generally like to have full control over what happens, without any automated surprises.

Jooel - good comments/questions; I noticed this also. Other autocomplete searches on web page let you hit enter once when your typed query pulls up a desired result. Glad others noticed this also. Like you, I'm not able to alter the code as one user suggested.

Can you please give me an example of the autocomplete searches you are talking about? I am looking at nodereference and the autocomplete on api.drupal.org and they work the same way as this. You must select an option to fill in the textbox first before you can do anything else.

I can write the script to do it the way you want and have it as an option in the config. I will write the script in the next few days and post it here, but I probably won't commit it for a while as I am doing a major rewrite of this module again as I've changed my mind about the whole thing.

Hello! Yep, Drupal autocomplete fields seem to like a select step and then a enter/post step. While most other implementations (ie. Google, Yahoo,...) take the selection step as being both select and enter/post. Personally I hope it change, the api site drives me nuts :)

This is a slick module though ! I'd like to dig in and help with some patches but your last comment here has me wondering if that's a good idea. Is this re-write in the works still?

Yeah it's getting too hard to add features to the code because of the way I made it, so I'm working on a rewrite but post your ideas and code samples if you like, they will help a lot.

Also another reason not to submit the form on selecting a choice is because you can combine multiple forms into one form, like this: http://watercrew.com.au/training-results
But yes I understand as an option this suggestion would be perfect for a lot of you, so I will look into making that available.

Yep, it's really just useful for single field forms.

I see you made some updates tonight. :) This module gets me about 80% to what I need for a D6 site I'm working on currently, so I'm more then happy to help out here if it fits in with your plans. There are a few bugs I was looking at to start.

The first one is easy. The page callback autocomplete_node_finder_block_form_results($delta) is printing its output directly rather then just returning it, so results pages aren't coming back in a fully theme'd page.

Basically:

-  print theme('autocomplete_node_finder_results_page', $delta, $nids, $form_state);
+  return theme('autocomplete_node_finder_results_page', $delta, $nids, $form_state);

The other problems will take a little more investigation.

1) Pager'd result output doesn't seem to work for me. At first glance it appears that it's just because an actual pager_query isn't used which sets some globals that are used by theme_pager. It may just be a case of adding a couple globals by hand which I was going to look at next here.

2) The "Find nodes by this field" block configuration option seems to be a little confused. If the cck field list is truly supposed to be unique by content type *AND* field, then it's missing options for fields that are present in more then one content type. If it's only supposed to indicate the cck field to be searched then it should probably just display the actual field names rather then content type names. I'm just not sure yet what it's doing with the option without reading the code further.

3) In IE I'm seeing a JS error of "'Drupal' is undefined" whenever a block is active on a page. Basically a timing issue as the autocomplete js is loaded via a form "hack" before the base drupal js is. I think this will be easy enough to fix.

So that's what I'm looking at currently.

As for new features, I'd like to add the ability to select a View to define the list of nodes that are searched. CCK's Nodereference module already does this and I think most of the code could be lifted and modified without a lot of pain. I've used parts of it for other functions already. It's well written.

Finally, I'd also like the ability to specify the query by hand if need, via some sort of hook call. Then the module becomes a very open autocomplete search option.

Sorry for the long message, just wanted to let you know where I'm coming from. I think it's a very useful module ;)

UPDATE: Posted a patch for 3 of the 4 issues mentioned above at:

#340108: Few small fixes..

2) The "Find nodes by this field" block configuration option seems to be a little confused. If the cck field list is truly supposed to be unique by content type *AND* field, then it's missing options for fields that are present in more then one content type. If it's only supposed to indicate the cck field to be searched then it should probably just display the actual field names rather then content type names. I'm just not sure yet what it's doing with the option without reading the code further.

If I recall correctly, I couldn't figure out how to make use of fields that are used in multiple content types, except for the content type they were created in. Probably because of the method I use to 'discover' this information.

I don't understand what globals you're talking about - got a link about this?
Also the pager query is not used, but I do this to the results:
$nids = array_chunk($nids, $limit, TRUE);

edit: errr... this doesn't do any offset does it.. :/

edit again: oh yes it does, because then I pick which chunk to use a few lines later

I've tried to create some javascript to solve this problem, but it just isn't working for me

here is what I have so far

Drupal.behaviors.autocompleteAutoSubmit = function (context) {
  $("div.block-autocomplete_node_finder div#autocomplete ul li", context).mousedown(function() {
    alert('click');
  });
};

Doesn't work. Can't even detect a click on one of those options :/

Hello,

I would like add my comments in these subject, using Firefox 3.

New users that dont know about the "autocomplete feature" will think its a regular search form.
They will type a word and quickly press Enter - Nothing happens.

At this point, no suggestions come up. So the user's only option is to press Enter again. The results page will come up.

Note, the user doesnt even notice there is an "autocomplete feature" because he never sees the suggestions.

My suggestion is that at the first time he presses Enter, the suggestions should come up. This will let the user know THERE IS an "autocomplete feature" and either pick one suggestion OR press Enter again and go thru with the Results page.

How is that better than what we have now? Are you saying to show autocomplete matches that don't match the user's typed words?
I am considering making some kind of 'fuzzy' matching thing that uses this: http://en.wikipedia.org/wiki/Levenshtein_distance
so it would mean there is a more likely chance of getting an autocomplete suggestion.

I'm saying SHOW the matches that do match the users typed words when he presses Enter.

Because right now, you have to wait for the suggestions to popup. Sure they are quick, but if you're faster and press Enter first, they do not come up at all (the suggestions).

Hmm that one might be harder.

I really loved how this module worked, great job!
But as mentioned having to hit enter-twice and hitting enter too quick causes an error.
From my understanding this cannot easily be changed. An example of why it's crucial would be on such websites as gsmarena.com
You would enter a phone model and it either takes you to the phone page, or to a results page if multiple are found. (this module does this part great btw!) Is there any way to simply modify this for the desired results? thank you

I have no idea what your question is shiver.

I will keep my eye open on this, but there are other problems than just solving this, there is also the question of whether it's a good idea to submit a form as soon as a selection is made.
If any possibilities open up I'll be sure to do something about it.

This is being addressed in the Finder module http://drupal.org/node/456764