Четвёртый раз пытаюсь....
Не пристёгиваются картинки к сообщению

gorr wrote:

http://www.drupal.ru/node/46872[/quote]
Тема закрыта.
Спасибо.
Будем учиться дальше.

Интересная тема.
Спасибо за подсказку.
Буду пробовать.

И самое поганое, что этот DIV с overflow:auto - Друпальский, добавляется автоматом при рендировании fieldset.
То есть недоступен.

Был неправ, погорячился.
Больше не повторится.
Есть overflow:auto от system.css и вешается точно на каждый DIV, вложенный в fieldset.
Отловил в эксплорере девелопер тулсом.
Только ширина нигде не лимитируется, кроме как ширина таблицы в целом, где fieldset расположен в одной из колонок без уточнения ширины.

Во всём Друпале overflow:auto торчит только в fck_dialog_common.js
Но он тут не при делах.

Прошерстил все вышестоящие DIV и TABL заодно.
overflow:auto не встречается нигде.

Так я же вроде свой код дал.
В Firebug для fieldset вижу только

Знать бы ещё, откуда ноги растут.
Я же не пишу сам ничего из этого.
Свойства наследуются от Друпала.
А к станице пристёгивается с дюжину CSS-файлов.
И где в них искать?
Да и трогать их как-то боязно.

Это уже по ту сторону добра и зла.

Восстанавливаю ситуацию по шагам:
Определяю свой тип контента.
В нём - поле 'Price' тип файл с расширением 'xls'.
Начинаю вводить контент,прикачиваю экселевские файлы.
После каждого шага запускаю проблемный модуль.
И вылетаю в задницу где-то на пятом экземпляре.
Модуль начинает выдавать эту хрень.
Откат не помогает.
Даже если удалить нововведённое.
Только если снести и восстановить базу.

Вывод напрашивается сам собой - проблема внутри Друпала.

Не думал, что в этом есть нечто криминальное.
Но от того, где лежит этот файл картина не меняется.
Пробовал по всякому.

brg wrote:

$form_state передается первым элементом, а не вторым .. правильно использовать function formexample_nameform($form_state)
У меня всё отлично работает. Проверьте ещё раз, если проблема останется, выложите свой модуль, я попробую помочь.

Так и есть, первым.
Но как им верить после этого?
Ведь пишут совсем не так.

Ещё раз спасибо за заботу, дорогой. Всё путём.
Будем учиться дальше.

P.S. При наличии в VALIDATE form_set_error(); картина не меняется.
Проваливаюсь в SUBMIT, а не в ALTER, как хотелось бы.

Красиво я изложил, только глупость сморозил.
form_set_error(); - без параметров -вроде бы и есть form_not_validate() как я обозвал.
Но вот в чём загвоздка.
И в примере http://stroynn.ru/test, и в моём модуле ALTER ПРЕДШЕСТВУЕТ VALIDATE, а не наоборот как в документации.
Или я уж совсем притупел.

brg wrote:

Наверное будет правильнее сделать через JS, т.е. через друпаловский ahah или просто при помощи jQuery .. на мой взгляд это будет более так сказать по феншую

А то, что ты спрашиваешь .. нужно думать .. потому что вообще не очень логически правильная задача

brg wrote:

Странно ... у меня в 'post' находятся переменные собственно полученные POST запросом.
http://drupal.ru/files/test.module_0.txt - тут все работает, если у вас пусто, значит нужно смотреть что ещё там у вас есть.

Где-то я туплю.

Потому что у Вас всё работает штатно по схеме
VALIDATE -> ALTER -> THEME.
А у меня с вывертом
VALIDATE -> PAGE -> CONSTRUCTOR -> ALTER -> THEME.
Как я и предполагал, уже в PAGE $form_state теряется.
И это уже по ту сторону добра и зла.
Откуда ноги растут - тайна сия велика есмь.

Так я и не пытаюсь форму в валиде трогать.
Точно в альтере хочу над ней поизгаляться.
Но совет не катит.
После конструктора $form['#parameters']- пустой массив
Array ( [0] => win_constructor_nameform [1] => Array ( [storage] => [submitted] => [post] => Array ( ) ) )

Ну прописана у меня в модуле своя темизация формы и двух видов полей в ней.
Разве это может как-то повлиять на процесс её обработки после возврата?

Нужно убрать немного информационного шума.
Повторные ALTER после THEME идут от двух других форм, расположенных на той же странице (login, search).
Ими можно пренебречь.
Остался один вопрос, ключевой.
Почему при возврате формы ПОСЛЕ VALIDATE процесс генерации формы запускается сначала через PAGE -> CONSTRUCTOR -> ALTER -> THEME.
Вроде как в CONSTRUCTOR (или уже в PAGE без разницы) теряется при этом $form_state, что логично.
И это вместо продекларированного в документации
VALIDATE -> ALTER -> THEME.

P.P.S. Забыл сказать, что все полученные из формы значения сбрасываются в CONSTRUCTOR после VALIDATE, что очевидно, но невероятно.
Поскольку, судя по http://drupal.org/node/165104, после валидации мы должны выходить на темизацию непосредственно, минуя конструктор.
Правда, судя по той же схеме, после валидации там нет места и для _form_alter. Однако после #theme стоит #post_render.

Нижайше прошу прощения у уважаемого сообщества.

В функции темизации забыл задать формирование 'NAME' в 'INPUT'.

Отсюда вся свистопляска.
Ещё раз прошу прощения.

Будем учиться дальше

Кажется проясняется, где собака зарыта.
В форме темизируется несколько 'fieldset' с 'input type radios' одной функцией темизации.
Непоследовательно, между ними в форме рендируются другие элементы собственно Друпалом.
Так вот, Firebug мне показывает, что в форме все ручно темизированные INPUT относятся к одной группе с именем первой ручно отрендированной.
Все checked в этой окрошке сброшены в false, понятное дело.
Уверен, что дело не в разметке.

Поясняю:
Вот кусок от функции темизации радиобаттона
$output .= ($i==$element['#default_value']) ? ' checked="checked" ' : '';

Ещё идеи есть?