Okay I give up. Test just became Test and Test2 and Test3 and Test4 where ... where they do testing stuff on this disable/enable stuff with checkbox and html_textarea and THEY ALL WORK AS ONE WOULD EXPECT.

So it's something I'm doing but I sure can't figure it out. Wow I feel so totally Aussie :'(

Hi Ed,

This is some Google magic:

http://www.w3.org/TR/html4/interact/forms.html#h-17.12
website wrote:

17.12.1 Disabled controls

Attribute definitions

disabled [CI]
When set for a form control, this boolean attribute disables the control for user input.

When set, the disabled attribute has the following effects on an element:

* Disabled controls do not receive focus.
* Disabled controls are skipped in tabbing navigation.
* Disabled controls cannot be successful.

The following elements support the disabled attribute: BUTTON, INPUT, OPTGROUP, OPTION, SELECT, and TEXTAREA.

This attribute is inherited but local declarations override the inherited value.

How disabled elements are rendered depends on the user agent. For example, some user agents "gray out" disabled menu items, button labels, etc.

In this example, the INPUT element is disabled. Therefore, it cannot receive user input nor will its value be submitted with the form.

<INPUT disabled name="fred" value="stone">

Note. The only way to modify dynamically the value of the disabled attribute is through a script.

excerpt from quote from website wrote:

The following elements support the disabled attribute: BUTTON, INPUT, OPTGROUP, OPTION, SELECT, and TEXTAREA.

You didn't mention your pubic hair. Not that I am interested. So please spare me on the details.

--F

Afwas wrote:

You didn't mention your pubic hair. Not that I am interested. So please spare me on the details.

Scary detail is when he tells you that even that's a tad threadbare :|

¥

I think I'm on to something. Nothing to do with w3 standards I think given that my Test4 plugin will disable an html_textarea based on selecting the right (wrong?) thing from a select box. In other words: what I want to do is very doable, but not the way I'm doing it in the situation where I want to do it. Clear yah?

ANYWAY one thing I just noticed that is in Test (and therefore all my variants of Test) is that it goes like this:

function GetDefaultSettings( & $params )
{
	$r = array(
...
...
...
	return $r;
}

I, for some reason, do it this way:

function GetDefaultSettings() {
	return array(
...
...
...
	}

Unfortunately changing that little detail did not result in satisfaction. Yet. Clearly though if I can have a modified version of Test do as I desire then I should be able to get "tiny random youtubes" to do as I desire. Unfortunately I'm probably going to give up on it entirely and go with the monstrously ugly "query plugins for a plug_ID based on plug_classname and if it exists then query pluginsettings for a pset_value of my desires based on the pset_plug_ID being what I figured out in the first query and if that is set then use it to figure out a simple stupid true false" - which I know for a fact works under all conditions. It's just not cool ya know?

BTW there is a bug in that section of code somewhere. Take the Test plugin and add a third option to the select box for Tuesday. Now see what happens when you select Tuesday. I was somewhat surprised to see that, in my Test4 setup (starts enabled, selecting sunday disables) selecting Tuesday also disabled the html_textarea box. In both cases that change 'stuck' after pressing save and review.

Okay one word with which you can experience word association: NAIR.

BTW there is another obvious bug in the "Test" plugin. Install it, then remove it and you'll see

Fatal error: Call to a member function get() on a non-object in /home/wonderw/public_html/test/installation/path/plugins/_test.plugin.php on line 468

It is NOT line 468 in the real plugin though. The area that generates the issue is function AdminBeginPayload(), and the problematic line is if( $this->UserSettings->get('echo_random') ).

There ya go!

Okay solved. It seems that ignoring a key bit right before returning $r is not a good idea

		);

		if( $params['for_editing'] )
		{ // we're asked for the settings for editing:
			if( $this->Settings->get('my_select') == 'mon' )
			{
				$r['a_disabled_one']['disabled'] = false;
			}
		}

		return $r;

Now I can take advantage of http://forums.b2evolution.net/viewtopic.php?p=70253#70253 and make pleasant looking yet functional plugin settings. I sure hope after all this that *someone* other than me wants tiny random youtubes in their sidebar...