Не надо ничего изобретать, в PFC все уже давно написано. Роутер сообщений манипулирует объектом message, который в основном использует только параметр StringParm, а вообще говоря message эта структура которая имеет не только этот параметр, но и другие. Так почему бы их не использовать, если в этом есть потребность. Никаких правок и расширений PFC не надо, если конечно не хочется довести дело до "красивости", несколько раз порывался было но так и не сподобился. Я постоянно пользуюсь описанным способом передачи параметров через merssage, например открываю окно и передаю "номер сделки" клиента в это окно.

edmikecaОгромное спасибо всем за ответы! Сейчас начну пробовать.

Один только вопрос к PavelBuilder. То что Message Router использует Message.StringParm для передачи имени Event я знаю. А не будет ли каких-то side effects (побочных явлений) если через него (Message.StringParm) передать еще и свой параметр? Я, честно говоря, никогда глубоко не разбирался как работает Message структура и что будет если через нее последовательно передавать несколько параметров. Она что их в стек помещает? Я помню из help, что рекомендуется извлечь значение из структуры как можно скорее, поскольку PB может использовать ее в своих целях.

Еще раз спасибо всем за ответы.

Михаил.

Может и будет, я передавал только имя окна и номер, пока большего не требовалось. Билдер передает структуру messge целиком, никакой последовательной передачи там нет, получая в pfc_open объект message нужно незамедлительно из него получить все что надо, поотом остальной скрипт.

pandЗдравствуйте .
коль зашла речь о передаче параметров.
Хочу поделиться своей технологией ( возможно и не новой и не сверх уникальной )

очень часто приходится передавть несколько параметров между окнами/ объектами для этого сделат объект в котором можно заполнять масив именованых параметров и соответсвенно извлекать их по имени .

Объект и структуры прилагаю.
Хотелось бы услышать мнение по поводу такой технологии.
И возможно кому то эти объекты прийдутся по Душе.

Нрмальная техноогия, только по-моему слегка "за уши". Объяви свою структуру глобально и используй где ни попадя, только нездорово в принципе объявлять глобаные перменные, нехорошая практика, но если знать, что есть ряд параметров которые всегда в приложении нужны и к ним частое обращение, то почему нет. Есть у нас приложение отчеты и там как раз удобно всегда помнить последний интервал дат применяемый в последнем отчете, возможно выбранного клиента, еще ряд параметров и тогда пользователь открывая отчеты где появляются новые парметры только их и определяет, уточняя даные введенные в других местах, очень удобно, пользователи в восторге. А такое часто, приходитт клиент и начинает просить отчет по счетам, выписку со счета, отчет по завершеным операциям, по незавершенным, выписку их реестра ипрочую ерунду и тут все очень быстро и оперативно. Потому у меня просто обявлены некоторые глобальные переменные и при открытии отчета, все необходимые переменные-параметры легко заполняются кодом предка от которого унаследованы все отчеты. Возможно есть другие решения, но жизнб показала устойчивым и этот подход.
Вообще моя практика показала, что когда возникает проблема передачи параметров и это начинает доставать, значит где то упущение в разработке интерфейса программы, не должно такого быть.

По ссылке что дал Филипп, есть колмментарий:

OpenWithParm также не гарантирует доставки Message событию open окна.
Попробуйте добавить в окне some_window u_em из pfc, в конструкторе которого напишите скрипт:
of_setdropdowncalendar ( true)
Ваш пример работать не будет.

Это как раз ответ на то всегда ли будет работать передача параметров через message, так вот не всегда, стандартный объект может использоваться при работе конструкторов и ... но pfc использует n_msg объект, т.е. они поступили придерживаясь политике наследования, расширения фукнционала нового объекта и его использования, так что даже используя n_msg проблем быть не должно, а если переживаете, то надо создавать свои "навески". А вообще действительно красиво получается :)