Ну вот, сейчас опять виноватым буду... - Calendar

Программы на Clarion, шаблоны, библиотеки и пр.

Модератор: Дед Пахом

Правила форума
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
Ответить
Гость

Сообщение Гость »

Hello clalist,

Есть ШВС.
Родительское - MDI Frame
Дочерние - MDI Child
В дочерних вызывается Form. По умолчанию вызывается как MDI, но это поведение меня не устраивает и делаю его НЕ MDI. Работает.

На Form размещаю CalendarLookup. Запускаю. Не работает.
При попытке вызвать календарь имею нехорошее сообщение про MDI, Application и GPF.

Думаю...
Открываю Perso_SF.clw. Нахожу определение окна CalendarWindow.
В нем вижу установленное свойство окна - MDI.

Думаю...
Открываю StdFunc.tpw. Нахожу шаблон для CalendarWindow.
Вижу:

Код: Выделить всё

#FIX(%Procedure,%FirstProcedure)
CalendarWindow WINDOW('Календарь'), ...
#IF(%ProcedureTemplate = 'Frame' OR ~%FirstProcedure)
         ALRT(DownKey),ALRT(HomeKey),ALRT(EndKey),TILED,GRAY,DOUBLE,MASK,AUTO,MDI
#ELSE
         ALRT(DownKey),ALRT(HomeKey),ALRT(EndKey),TILED,GRAY,DOUBLE,MASK,AUTO
#ENDIF
Думаю...
Стираю нафиг MDI. Имею:

Код: Выделить всё

#IF(%ProcedureTemplate = 'Frame' OR ~%FirstProcedure)
         ALRT(DownKey),ALRT(HomeKey),ALRT(EndKey),TILED,GRAY,DOUBLE,MASK,AUTO
#ELSE
         ALRT(DownKey),ALRT(HomeKey),ALRT(EndKey),TILED,GRAY,DOUBLE,MASK,AUTO
#ENDIF
Сохраняю. Запускаю Make, потом Run и радуюсь жизни вместе с Calendar.
Однако думаю, что нехорошо это - исходники изменять...

--
Best regards,
Иван mailto:shkmail@inbox.ru


(Добавление)
В дочерних вызывается Form. По умолчанию вызывается как MDI, но это поведение меня не устраивает и делаю его НЕ MDI. Работает.
Вот с этого места - подробнее. Что именно не устраивает?
Почему нельзя просто заблокировать повторный запуск нитки не снимая атрибута MDI?
Однако думаю, что нехорошо это - исходники изменять...
Сам догадался? :):):)

С уважением,
Владимир Смелик vovs@bigfoot.com
Думаю...
Это полезно
Сохраняю. Запускаю Make, потом Run и радуюсь жизни вместе с Calendar.
Молодец!
Однако думаю, что нехорошо это - исходники изменять...
Сделай еще один шаблон по типу существующего, зарегистрируй его и будет тебе щасье без изменения исходников.

------------------------------------------------------------
Igor Gubin (igor@quantor.com)
Quantor-Soft Metal
Phone/Fax: (+7 095) 234 4905
WEB: http://www.metaldata.info
http://www.metaldata.ru
Однако думаю, что нехорошо это - исходники изменять...
Точно нехорошо.
Если используешь в приложении MDI-модель - окна должны иметь соотвествущий атрибут. Если тебе не нужна многопоточность (как для 90% задач - реально не нужно, а не просто "шоб було") - тогда убери фрейм.

--
Best regards,
Vadym mailto:vadim@softcreator.com
ICQ: 82308757

Мало подумал. Зачем теперь #IF вообще? А что будешь делать, когда MDI
_понадобится_?
Сохраняю. Запускаю Make, потом Run и радуюсь жизни вместе с Calendar.
Однако думаю, что нехорошо это - исходники изменять...
Поставочные - нехорошо. Будут трудности при апгрейде. Делаешь так:
1. Рядом с TEMPLATE создаешь папочку MyTemplate.
2. В RED файле вписываешь для шаблонов эту папочку _перед_ TEMPLATE.
3. Копируешь туда шаблон.
4. Правишь скопированный шаблон.
4.1. В описании шаблонного диалога добавляешь настройку
#PROMPT('Window type',DROP('Standard!MDI!NonMDI')),%CalendarWindowType,Default('Standard')
4.2. Тот фрагмент, что ты исправлял записываешь так:

Код: Выделить всё

#CASE(%CalendarWindowType)
#OF ('Standatd')
  #IF(%ProcedureTemplate = 'Frame' OR ~%FirstProcedure)

ALRT(DownKey),ALRT(HomeKey),ALRT(EndKey),TILED,GRAY,DOUBLE,MASK,AUTO,MDI
  #ELSE

ALRT(DownKey),ALRT(HomeKey),ALRT(EndKey),TILED,GRAY,DOUBLE,MASK,AUTO
  #ENDIF
#OF ('MDI')

ALRT(DownKey),ALRT(HomeKey),ALRT(EndKey),TILED,GRAY,DOUBLE,MASK,AUTO,MDI
#OF ('Non MDI')

ALRT(DownKey),ALRT(HomeKey),ALRT(EndKey),TILED,GRAY,DOUBLE,MASK,AUTO
#ELSE
  #ERROR('Unexpected value in %%CalendarWindowType: ' & %CalendarWindowType)
  #ABORT
#ENDCASE
WBR, Nick Tsigouro mailto:nick@arsis.ru
Написал: ClaList(2)
Гость

Сообщение Гость »

Если используешь в приложении MDI-модель - окна должны иметь соотвествущий атрибут. Если тебе не нужна многопоточность (как для 90% задач - реально не нужно, а не просто "шоб було") - тогда убери фрейм.
Не, Вадим, ты малость не прав :D
Простейший пример:
- есть полноценное MDI-приложение
- в нем-же есть пункт меню для блока админских функций по обслуживанию БД.
- ряд функций этого блока для пущей безопасности ("защита от дурака" даже для админов!) запускаются ТОЛЬКО в монопольном режиме.

По твоему совету получается:
- или не используй полноценный интерфейс в таких функциях
- или выводи эти функции в отдельные приложения

Ну, первый пункт даже обсуждать не буду - не серьезно!
Что-же касается второго пункта - имхо, мне БОЛЕЕ удобно, как разработчику, вести ТОЛЬКО одну версию приложения без боковых ответвлений и сопутствующих утилит, использующих часть функционала ядра основного приложения.
Мелкие утилитки типа промежуточных конвертеров, естественно, не в счет.
Не люблю я мульти-DLL, не люблю!

Так что, имхо, более правильный вариант предложил Николай.
У меня что-то подобное. Только я не стал "плодить" дубликаты а просто внес соответсвующие изменения прямо в оригинальные шаблоны. И теперь проблем нет - где надо сам задаю модель окна таких утилит как календарь!

--
С уважением,
Oleg mailto:Oleg_Rudenko@mail.ru

А накой так сложнно ??? насколько я понял, важно не дать запустить второе окно в отдном потоке ? тогда все просто.. на окно вешаеться свое (этого окна) меню, даже можно из одно пункта и у меню устанавливаеться признак (DoNotMarge) и это окно при окрытии перекрывает меню фрейма. Насколько я понимаю, именно это и надо.

--
Best regards,
Курко Максим mailto:ClaList@enigmasoft.com.ua
ICQ: <164766643>
Не, Вадим, ты малость не прав :D
- Не согласный я йми.
- С кем? C Энгельсом или Каутским?
- Да с обоими...

Вот так и я ;)

Я прав в пределах логики избранной модели приложения.
Если приложение MDI - все окна должны быть MDI-ными (т.е. иметь такой атрибут). Это как в ООП - ведь можно использовать публичные члены - но "...неаккуртненько выходит...".
Исключение пожалуй в клаше только одно - превью отчета, но это уж очень специфическое окно, оно в реальной жизни само по себе не живет.
- или не используй полноценный интерфейс в таких функциях
Что значит неполноценный в твоем понимании?
- или выводи эти функции в отдельные приложения
Действительно серьезные функции должны быть вынесены в отдельную утилиту - на мой взгляд. Dll тут и не нужны - просто отдельное сервисное приложение на базе одного словаря.
Не люблю я мульти-DLL, не люблю!
Твое право.
Но кажется ты немного путаешь использование атрибутов MDI и Modal.
Если нужно модальное поведение некого окна в пределах MDI-модели - отнюдь не обязательно лишать его атрибута MDI - и 32-разрядное окно с MDI-атрибутом может быть прекрасно модальным.
Замечу в скобках - в MDI приложении таких окон должно быть пара-тройка. Если оно состоит наполовину их окон, нуждающихся в модальности - может все же не так модель выбрана? ;)

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

P.S. И давай не будем углублять дисскуссию. Ибо это все вопрос "веры"
и "привычки" (в том плане что доказать что либо никто никому не сможет).
Подобно использованию goto в языках высокого уровня...


--
Best regards,
Vadim
Если приложение MDI - все окна должны быть MDI-ными (т.е. иметь такой атрибут).
Ну ты хватанул... А как же Word, Excel? Классика MDI и полно не MDI-ных окон - все, что из меню открывается.

WBR, Nick Tsigouro mailto:nick@arsis.ru

(Добавление)

Может я чего не понимаю...
уж не ругайте сильно...

Я так понимаю SDI:

1. есть окно-"главная процедура"
2. на нем меню - возможно вызвать другие "процедуры-окна"
3. при вызове этих новых окон их размеры и положение на экране не определяются размерами главного окна и при перемещении или изменении их размеров главное окно может стать видимым.
ИМХО это по крайней мере некрасиво.
4. вызов другого дочернего (в процедурном смысле) окна _через__меню_главного_окна_ невозможен без предварительного закрытия текущего.
То есть в каждом окне должна быть кнопка "вернуться в главное окно". И только после ее нажатия пользователь получает доступ к управляющим элементам главного окна.

может быть есть элегантные способы удовлетворения моих слишком уж больших потребностей, описанных в пунктах 3 и 4, и в рамках SDI модели.
намекните, чего и как... приведите примеры других SDI со многими окнами и хорошим "useability".

Если используешь в приложении MDI-модель - окна должны иметь соотвествущий атрибут. Если тебе не нужна многопоточность (как для 90% задач - реально не нужно, а не просто "шоб було") - тогда убери фрейм.

Фрейм мне нужен, чтобы преодолеть проблемы пунктов 3 и 4.

Я прав в пределах логики избранной модели приложения.
Если приложение MDI - все окна должны быть MDI-ными (т.е. иметь такой атрибут).

Я не понимаю, почему окно календаря, которое по сути является диалогом, не может вызываться как независимое окно, не привязанное физически (не процедурно и не через параметры, а именно физически) к какому-то определенному окну, в качестве которого предложено использовать MDI Frame.

Ведь возможно же делать не-MDI форму для работы с записями файла?
Или это недосмотр разработчиков? Давайте сделаем так, чтобы этой возможности не было... пусть они все будут ТОЛЬКО MDI

Но кажется ты немного путаешь использование атрибутов MDI и Modal.

MODAL has no effect for 32-bit applications.
The Microsoft Win32 API does not support system modal windows.

или я чего опять-таки не понимаю?
или между строчек читать не умею?

это то, что мы получаем, если снимаем флажок MDI:

A WINDOW without the MODAL attribute, may be either "application-modal" or "modeless."
An application-modal window is a non-MDI window opened as the top window of an MDI execution thread.
An application-modal window restricts the user from moving to another execution thread in the same application, but does not restrict them from changing to another Windows program.

а это - с флажком MDI:

A modeless window is an MDI "child" WINDOW (with the MDI attribute)
without the MODAL attribute. From a modeless window, The top window on other execution threads may be selected by the mouse, keyboard, or menu commands.
If so, the other window takes focus and becomes uppermost on the video display. Any window not on the top of its execution thread may not be selected to receive focus, even from a modeless window.

Если нужно модальное поведение некого окна в пределах MDI-модели - отнюдь не обязательно лишать его атрибута MDI - и 32-разрядное окно с MDI-атрибутом может быть прекрасно модальным.

мне нужно не просто модальное поведение, а то, чтобы это окно не было ФИЗИЧЕСКИ привязано к какому-то другому.
Например у меня на экране приложение занимает только треть. И я хочу сдвинуть окно календаря на свободную (от моего приложеня) сторону экрана, чтобы полностью наблюдать вид приложения до вызова календаря.
(вот такая странная прихоть - мы же можем подобным образом поступить с окном, появляющимся в результате вызова MESSAGE(...))

Замечу в скобках - в MDI приложении таких окон должно быть пара-тройка. Если оно состоит наполовину их окон, нуждающихся в модальности - может все же не так модель выбрана? ;)

см. пункты 3 и 4

Почему нельзя просто заблокировать повторный запуск нитки не снимая атрибута MDI?

если речь идет о дочерних MDI Child, то я так и делаю.
правда грубо наверное - запоминаю Thread = START(...) и потом при открытии других окон я это окно закрываю, а при вызове (через главное меню или тулбар, к примеру) того же самого окна, я этот вызов просто игнорирую.

Да, кстати - если я не ошибаюсь - вопрос возник из проблемы, которую его автор не знал как решить по-человечески (запуск только одного экземпляра окна в потоке) и поэтому решил как смог.

ошибаетесь. вопрос возник сам по себе и к "запуску только одного экземпляра окна в потоке" не имеет никакого отношения

Так что не нужно перекладывать проблемы одной головы на другую (неважно, чья голова больная и чья здоровая).

никто и не перекладывает в том же C++Buider я могу ручками сделать все что угодно (с вызовом функций API, разумеется)

а о том, что ограничения MDI модели распространяются И на диалоговые окна (типа открыть-сохранить файл, выбрать цвет, выбрать день в календаре) я раньше нигде не слышал

так что просветите, если только это не написано в документации по Клариону. :))

Вот с этого места - подробнее. Что именно не устраивает?

Меня не устраивает то, что окно формы (в случае, если оно MDI) принадлежит родительскому фрейму и его нельзя, скажем, сдвинуть в сторону от основного окна, если то, к примеру, не развернуто на весь экран.
Или то, что в случае перемещения (пусть случайного) этого окна формы (не MDI) оно может уползти за границу фрейма (появятся всякие скролл бары) и пользователь офигеет - не поймет что ему с этими полосами прокрутки делать.
Короче, я хочу, чтобы окно формы (работы с записями) было модальным в Борландовском понимании этого слова - окном диалога(по типу MESSAGE()).

Поэтому я и снимаю флажок MDI в этом окне. То, что я получаю - меня более чем устраивает.

Почему нельзя просто заблокировать повторный запуск нитки не снимая атрибута MDI?

если речь идет о дочерних MDI Child, то я так и делаю.
правда грубо наверное - запоминаю Thread = START(...) и потом при открытии других окон я это окно закрываю, а при вызове (через главное меню или тулбар, к примеру) того же самого окна, я этот вызов просто игнорирую.

Почему нельзя просто заблокировать повторный запуск нитки не снимая атрибута MDI?

или я не понял какая нитка имеется в виду?
окно формы и так вроде не позволяет вернуться к браузу, пока его не закроешь... собственно это поведение не зависит от флажка MDI

С уважением,

Симметрично :)

А что будешь делать, когда MDI _понадобится_?

Я так понимаю, что MDI может понадобиться, если я буду вызывать календарь не из "не MDI" окна, каким я сделал окно формы-диалога, а из обычного поточного дочернего MDI окна разных там браузов?

ну вообще-то да...

Мало подумал.

это точно

--
Best regards,
Иван
Написал: ClaList(2)
Гость

Сообщение Гость »

Короче, я хочу, чтобы окно формы (работы с записями) было модальным в Борландовском понимании этого слова - окном диалога(по типу MESSAGE()).
Имхо. Форма - это документ. Брауз - это тоже документ, но с табличной частью. И в отношении к MDI интерфейсу они равноправны. То, что из брауза форма вызывается в том же потоке - это от лени шаблонописателей и нужно только для однообразия с SDI. По уму связка Browse-Form в MDI д.б. другой.
Форма должна запускаться через фрейм в новом треде. Запуск в том-же треде должен быть только для браузов, выступающих в роли селектора, т.е. когда нужен возврат результата в вызвывшую процедуру.
окно формы и так вроде не позволяет вернуться к браузу, пока его не закроешь... собственно это поведение не зависит от флажка MDI
Угу. Имхо это не правильно. Почему я в браузе не имею права выбрать и открыть 2-3-... документа?

WBR, Nick Tsigouro
Написал: ClaList(2)
Гость

Сообщение Гость »

Ну ты хватанул... А как же Word, Excel? Классика MDI и полно не MDI-ных окон - все, что из меню открывается.
Ну ты и примерчик подобрал... На заре цивилизации офис действительно имел вид mdi-программы. А сейчас каждый новый "поток" ("документ") живет абсолютно своей жизнью - даже отдельное окно на каждый документ в списке задач есть (хотя реально задача одна). Но внутри этого отдельного окна типичный sdi - все окна кроме панелей инструментов модальны.

--
Best regards,
Vadym

Так я их и имел ввиду. Клашин интерфейс как раз где-то на уровне MSWord 2.0 застыл :-((
Но внутри этого отдельного окна
> типичный sdi - все окна кроме панелей инструментов модальны.
Ну это в общем только картинка другая - к каждому MDI окошку дорисован фрейм, а не один фрейм на всех. Идеология по сути таже.

WBR, Nick Tsigouro
Написал: ClaList(2)
Ответить