forum.clarionlife.net

А вот как динамически окна создавать?
Пробежался по ClarionLife - примеров не нашел.

Такое:
wnd &= NEW(WINDOW)

не прокатывает.

А хочется.

Чем хорохша Клара(хотя и другие языки наверное хорошие), позволяют использовать API
CreateWindowEx
(подсказка Poweroffice но есть примеры и попроще.)

На ftp в каталог sample закинул файл slider.zip
Пример использования CreateWindowEx для создания слайдера.
Лучше всего MSDN почитать ...

Вроде и я залил

AnDS писал(а):А вот как динамически окна создавать?

А зачем?
Если для отдельных контролов, то уже посоветовали WinAPI.
А если для создания полноценного окна, то только через RTL с использованием недокументированных структур - описываешь в глобальных данных пустое окно, а где необходимо - создаешь его копию в памяти и "натравливаешь" на эту область памяти обычный реферал типа &WINDOW.
Ну, или обьявляешь окно в процедуре и вызываешь эту процедуру для создания нового окна. Правда, прийдется придумать механизм управления такими окнами - оно будет открыто, пока работает создавшая его процедура. Поэтому процедуру прийдется запускать через START как новый поток и ждать в ACCEPT-цикле команд для этого окна.

Вообщем, опиши более конкретно свою задачу. Возможно найдется более простое решение.

Олег писал(а):А зачем?

Заранее не известно, какие контролы будут в окне и сколько окон вообще будет открыто.
Окна создаются на основании информации в БД.

Олег писал(а):А если для создания полноценного окна, то только через RTL с использованием недокументированных структур - описываешь в глобальных данных пустое окно, а где необходимо - создаешь его копию в памяти и "натравливаешь" на эту область памяти обычный реферал типа &WINDOW.

Вот приблизительно это и хочется наверно.

Олег писал(а): Вообщем, опиши более конкретно свою задачу. Возможно найдется более простое решение.

Описываю:
Описание окон и контролов в них содержится в БД (количество окон - произвольно)
На основании входных данных принимается решение какие окна необходимо создать/открыть в данный момент в этой процедуре.
Т.е. одновременно открывается несколько окон в одной процедуре.

Вот приблизительно так. Сейчас уже задумался, нужно ли реализовывать именно так, как написал выше. Пока думаю.

PS. Кстати, пример CCTRL мне очень понравился.
Два вопроса:
Почему никто это не использует?
Список контролов, которые можно создать, полный или можно еще какие-нибудь создавать?

AnDS писал(а): Т.е. одновременно открывается несколько окон в одной процедуре.

Хмм... И как ты себе это представляешь? Я имею в виду одновременное открытие нескольких окон в ОДНОЙ процедуре! Одна процедура - один поток. В потоке может быть только ОДНО активное окно. Т.е., ты можешь, конечно, делать вложенные ACCEPT-циклы, но работать сможешь только в последнем. И пока его не закроешь - не сможешь работать в другом. Таким образом, получается - понасоздаешь несколько окон, а работать сможешь только в последнем! При этом, переключать фокус между ними не сможешь! И пока не закроешь текущее активное окно - не получишь доступ к предыдущему! Ну, и какой при этом смысл в открытии нескольких окон?
А если ты имел в виду одновременное открытие нескольких окон через START новых потоков с возможностью переключения между ними, то кто тебе мешает описать в процедуре, которую START-ушь в новом потоке, пустое окно и при открытии такой процедуры наполнить это окно нужными контролами и создать полноценное окно? Это довольно легко реализуется в стандартной концепции Клариона!
Т.е., при запуске нового потока передаешь в эту процедуру адрес группы или очереди, в которой содержиться описание всех необходимых контролов, которые должны присутствовать в новом окне - по этой информации формируешь окно в необходимой конфигурации.!

AnDS писал(а):PS. Кстати, пример CCTRL мне очень понравился.
Два вопроса:
Почему никто это не использует?
Список контролов, которые можно создать, полный или можно еще какие-нибудь создавать?

В том примере используется вариант создания контролов, которых нет в самом Кларионе. И, естественно, они создаются через WinAPI.
Но большинство контролов, которые используются для работы пользователя, реализованы в Кларионе и для их создания нет необходимости в довольно сложных манипуляциях с WinAPI - достаточно обычного оператора CREATE!
Т.е., с помощью этого оператора можно создавать ВСЕ контролы, которые доступны для окна в Кларионе. А те контролы, которых нет в арсенале Клариона, можно создать с помощью WinAPI. Таким образом можно создать практически любой контрол, доступный для Windows.

Олег писал(а):

AnDS писал(а): Т.е. одновременно открывается несколько окон в одной процедуре.

Хмм... И как ты себе это представляешь?

Легко! Форма, в форме много кнопочек - выбор из справочника. Ну например.

Олег писал(а): Я имею в виду одновременное открытие нескольких окон в ОДНОЙ процедуре! Одна процедура - один поток. В потоке может быть только ОДНО активное окно. Т.е., ты можешь, конечно, делать вложенные ACCEPT-циклы, но работать сможешь только в последнем. И пока его не закроешь - не сможешь работать в другом. Таким образом, получается - понасоздаешь несколько окон, а работать сможешь только в последнем! При этом, переключать фокус между ними не сможешь! И пока не закроешь текущее активное окно - не получишь доступ к предыдущему! Ну, и какой при этом смысл в открытии нескольких окон?

Я уже написал -- вложенные формы. Мне и не нужно одновременно работать в них.

Олег писал(а): В том примере используется вариант создания контролов, которых нет в самом Кларионе. И, естественно, они создаются через WinAPI.
Но большинство контролов, которые используются для работы пользователя, реализованы в Кларионе и для их создания нет необходимости в довольно сложных манипуляциях с WinAPI - достаточно обычного оператора CREATE!
Т.е., с помощью этого оператора можно создавать ВСЕ контролы, которые доступны для окна в Кларионе. А те контролы, которых нет в арсенале Клариона, можно создать с помощью WinAPI. Таким образом можно создать практически любой контрол, доступный для Windows.

Да это все понятно. Я как раз и имел ввиду -- что еще может понадобится из контролов WinAPI?
Вот выбор даты, например, мне понравился -- оно всегда работает? Или ограничения какие есть?

AnDS писал(а):Легко! Форма, в форме много кнопочек - выбор из справочника. Ну например.
Я уже написал -- вложенные формы. Мне и не нужно одновременно работать в них.

Тогда - какие проблемы?!
Пишешь процедурку, в ней обьявляешь пустое окно.
При нажатии на любую из кнопок в основной форме вызываешь эту процедурку с параметрами настройки окна - по этим параметрам настраиваешь размеры окна и создаешь на нем любые необходимые кнопки. При нажатии на любую из этих кнопок опять можешь вызвать эту-же процедуру уже с новыми параметрами настройки. И так далее, пока хватит ресурсов системы!
Только вот - как ты собираешься обрабатывать события в таких окнах? Что напишешь в ACCEPT-цикле шаблонного окна?
Тут выхода два - или использовать технологию ABC-шаблонов или в качестве одного из параметров процедуры передавать имя внешней процедуры, которая будет обрабатывать события ACCEPT-цикла. Правда, при этом прийдется заранее писать уже готовый код такой процедуры. Но, тогда - что мешает в этой-же процедуре обьявить и окно со всеми необходимыми контролами!?

AnDS писал(а):Да это все понятно. Я как раз и имел ввиду -- что еще может понадобится из контролов WinAPI?
Вот выбор даты, например, мне понравился -- оно всегда работает? Или ограничения какие есть?

Вроде-бы ограничений нет.

"Внезапно" потребовался горизонтальный слайдер на стандартной форме в CW6 ABC, посмотрел вышеуказанные примеры, все вроде получается норм, но что-то не могу пока победить "недочетик" - при прокрутке колесом мышки (мин - слева/мах-справа) или при кнопках Home|End не в ту сторону изменяется, TBS_DOWNISLEFT + TBS_REVERSED указал в стиле.
Как победить - только вариант обрабатывать отдельно для них из очереди сообщений или есть недокументированные опции?
Совсем отказываться от контрола неохота - довольно "логично" вписывается в процесс заполнения данных...
ps обратил внимание что "из коробки" в code::bloks тоже "неправильно" работает подобный контрол (понятно что там тож winapi работает), а в QT например - норм
PSS еще - "до кучи" - если нестандартный контрол формируем "поверх" на стандартном заранее отрисованном в дизайнере окне, а не в полностью созданном динамически с "0", можно ли без больших заморочек (громоздкого отслеживания и корректировки фокуса ручками) переопределить порядок обхода в окне всех контролов/полей для пользователя в таком окне на новый - выбираемый программой с учетом добавленных новых контролов? сейчас порядок такой - сначала все поля/кнопочки отрисованные дизайнером, а потом по очереди - все вновь созданные контролы