Changing default values off fields on change of select box

This isn't a bug, it's normal Forms API behavior, but probably you've never run into it before. If you'd make this a normal multi-step form, then it would act like this as well.

The reason is as simple as it could be. For example your page_height field. I'll explain you two scenarios:

Scenario 1.
1) The page_height form item doesn't exist.
2) You select "Number pager". The default value 25 is set.
2a) (optional) change the value to whatever you like.
3) (repeat) Change the pager type to another pager type. This won't change the default value, it will keep the final value of step 2.

Scenario 2.
1) The page_height form item doesn't exist.
2) You select "Number pager". The default value 25 is set.
2a) (optional) change the value to whatever you like.
3) (repeat) Change the pager type to "none" and then change it to any of the other pager types. The proper default value will be set.

The cause for this? Drupal's processing of form values. For example in scenario 1, it receives the value 25. This is stored in $form['your_form_item']['#post']. Drupal uses #post to set the values the user entered.

Now, you can override this by removing the corresponding value from $_POST:

So this is in fact a FAPI bug/curiosity, not an AHAH helper bug/curiosity.

Finally, your code is completely wrong:
ahah_ex4_get_variable($form_state['values']['pager_dimensions']['pager_height'], 25);
You forget that $form_state['values']['pager_dimensions']['pager_height'] will always be populated after the first time you've changed the selection (because all values are submitted to the server, but the form itself is only rebuilt, not submitted, thanks to ahah_helper_generic_submit()).
Instead, you should check if the previous value equalled one of the defaults, and if it did, then you should override it with the appropriate current default. Otherwise, the custom value entered by the user should be kept.

In my modified example, I've changed it to always using the default value. I'll leave it up to you to implement the behavior I just explained.

And one more clarification: yes, your particular example works when JS is turned off, thus when you use a normal form rebuild instead. The reason it works? Because you set your #default_value to the value you're receiving through $form_values. When you rebuild a form, the form is first rendered with $_POST as it was originally received. $form_state['values'] is then also filled in accordingly. Next, it builds the form *another* time (i.e. in the same page rendering, not a secondary one!), but this time with $_POST and $form['#post'] cleared. So your new #default_value settings are set properly now. However, $form_state['values'] is *not* cleared, and since that's where you look for values in your form definition, your dynamic default values are set to the value last set by the user.

Now, imagine that you have another form item without a default value. The value that the user entered here would be *lost*! You can see this for yourself by commenting the lines in which you set the default values for your form items. Then try using the form when JS (and thus AHAH updates) is disabled. You've got a form that simply doesn't work.

There simply isn't a sensible way to have dynamic default values. In fact, that description already shows the contradiction: "dynamic default values". How can a default value be dynamic? Then it's not a default value anymore, it's just a value. So probably it's better to use form_set_value() in your case.

Please also read this comment: http://drupal.org/node/328201#comment-1117163.

Hi wim,

Thanks for your comments.

I have not enough understanding of the inner workings of the Forms API to follow all of your reasoning but...

I don't understand your reasoning about default values can not be dynamic.

If you load a normal form with values stored in the database, you use the values form the database. If the values are not stored in the database you use a default value. This default value can be different in different situations like in my pager example. I don't see anything wrong with that.

When I use the same code with a multi-step form it works perfect. (used http://drupal.org/node/262422 as example how to make multi-step form work with $form_state['storage'] to store values of previous steps)

I will go for this solution for now, but hopefully AHAH functionality will be more robust and easier to use in the future.

I don't have enough knowledge for now to help you to get it working and I am working on the next version of the Dynamic display block module, so not much time either. Problem of all I think:)

It would be great if you would extend your ahah_helper_demo.module a little bit and store the values actually in the database or in the variables table to make us all understand how we can use your module with stored data. What to use to store data? form_state['storage']? How to retrieve stored data? I mean AHAH forms to fill in data and retrieve it later for editing/adjusting

I know you are a busy man. But this little extension would help us all to have a better understanding, more users using your module and therefore more eyes to make your module better!!!

thanks again,

Philip

Default values should only be set *once*, i.e. they should not change over the lifetime of a single form instance. You're trying to change the default value all the time.

It took me quite a lot of time to go through your example, find out again how everything works and then do this write-up. I've got 6 deadlines upcoming in the next 9 days. Darn university :/ I'm afraid some time will pass until I find the time to get back to you.

Please update to version 2 and check if this problem persists.