Не знаю, известен ли уже этот баг общественности и MS. VFP9 beta игнорирует ControlBox = .F. при узком заголовке (HalfHeightCaption = .T.) и все равно отображает кнопки управления окном (Dockable при этом 0, т.е. абсолютно стандартная простая форма)

Если добавить свойство Closable=.f. - то работает правильно.
Видимо так разрулили противоречие когда раньше было ControlBox=.f., a Closable=.t. ;)

Hi, Aijik!

Вообще-то в хелпе сказано что эта установка включает/выключает "pop-up menu
icon" - т.е. кнопку системного меню - она-же Icon формы. А про то что она
убирает ВСЕ контролы из заголовка - не сказано ни слова. Так что тут ещё
большой вопрос когда она работает правильно - когда из "обычного" заголовка
выкидывает кнопки, или когда из "половинного" не выкидыват. IMHO второе
соответствует хелпу, тогда как первое - нет. И как я вижу оно работает точно
так-же и в VFP8...

2 Igor Korolyov

Цитата:

И как я вижу оно работает точно
так-же и в VFP8...

А я не вижу. Может еще раз проверишь? ;) Я вообще это обнаружил случайно при перекомпиле одного своего проекта на VFP9b. В VFP7 и VFP8 кнопки отсутствуют. Так было всю жизнь

Цитата:

Вообще-то в хелпе сказано что эта установка включает/выключает "pop-up menu
icon" - т.е. кнопку системного меню - она-же Icon формы. А про то что она
убирает ВСЕ контролы из заголовка - не сказано ни слова. Так что тут ещё
большой вопрос когда она работает правильно

Меню и кнопки - суть одно и то же, т.к. выполняют одни и те же функции и работают синхронно (доступность/недоступность), хотя формально по тексту хэлпа ты и прав. Далее... Во-первых, в любом случае HalfHeightCaption не должен влиять на этот закон, ибо тогда бред получается первостатейный. Во-вторых, сейчас специально посмотрел в VB6 - поведение абсолютно идентичное старым фоксам - ControlBox = .F. скрывает кнопки управления окном и в обычной форме, и при BorderStyle = 4,5 (ToolWindow - васиковский аналог HalfHeightCaption = .T.). В третьих, Borland Delphi 3 (сорри за покрывшуюся плесенью версию - другой нет под рукой ;)) - установка в фальш biSystemMenu (прямой аналог ControlBox) так же скрывает унопки управления. С BorderStyle=bsSizeToolWin (like bsSizeable with a smaller caption) поведение также полностью аналогично VB6/VFP3-8. Так что "большой вопрос" тут не проханже ;)
С учётом вышеизложенного, имею весьма стойкое подозрение, что сабж - это не сознательный шаг, а глюк, вылезший в следствие плясок разработчиков с переписыванием движка форм под поддержку Dockable (которое автоматом выводит форму в HalfHeightCaption=.T.)



2 Равиль

Цитата:

Если добавить свойство Closable=.f. - то работает правильно.
Видимо так разрулили противоречие когда раньше было ControlBox=.f., a Closable=.t. ;)

Ну вот и отлично, значит если в релизе все-таки решат оставить сабжевое поведение, то есть обход

Цитата:

Видимо так разрулили противоречие когда раньше было ControlBox=.f., a Closable=.t. ;)

Не противоречие это, а куммулятивная настройка, аки Form.Visible=.F. делающее всем конролам формы Visible=.F.
Если говорить о противоречиях, то гораздо более противоречиво вот это:


Родительская форма по клику на кнопке "WindowType" честно отвечает, что она модальна (WindowType=1) - и претензий к ней нет. Она действительно модальна, т.к. её вызвали Show(1), хоть она и была описана как немодальная. Дочерняя же форма, помимо того как была тоже была описана как немодальная, еще и вызывается точно также. Более того, ее немодальность подтверждается тем, что после вызова выводится надпись "После вызова дочерней". Факт: форма немодальна - как и, по-идее, должно быть. Более того, сама форма отвечает "WindowType=0". Вроде все прекрасно. Однако, читаем хэлп и видим, что:

Цитата:

Modal. No other forms can become active and the menu is inactive

Цитата:

Modal. No user input (keyboard or mouse) can occur in any other form or in the menu until the modal form is hidden or released. The program must hide or release a modal form (usually in response to some user action) before further user input can occur. Although other forms in your application are disabled when a modal form is displayed, other applications are not.

Цитата:

If the form is modal, the user must close the form before accessing any other elements of your application's user interface.

А теперь возьмем и проверим эти три положения с нашей дочерней формой. Все три выполняются - пункты меню вызвать нельзя, никакой ввод клавиатурой и мышью в родительской (либо какой другой форме) невозможен, другие элементы интерфейса приложения недоступны. Так модальна наша дочерняя форма или нет? Половина фактов говорит, что да, половина - что нет. При этом свойство, которое за это отвечает, говорит, что немодальна (WindowType=0). Вот это - ПРОТИВОРЕЧИЕ, а ControlBox - это просто баг ;)

Hi, Aijik!

Цитата:

Может еще раз проверишь? ;)

Да уж, и куда я только смотрел...

Цитата:

Так было всю жизнь

Угу, было, было... Сорри за дезинформацию.

Цитата:

Меню и кнопки - суть одно и то же

В WinAPI они и есть одно и
то-же, ну точнее синхронизированны они там... Есть стили WS_MINIMIZEBOX,
WS_MAXIMIZEBOX, WS_SYSMENU и иного нету, и судя по всему MinButton,
MaxButton и ControlBox есть их прямые аналоги. Closable кстати как стиля
нету, т.е. это уже другой механизм работает. Кстати HalfHeightCaption окно
вообще не имеет TitleBar как такового - т.е. это фокс рисует синюю полоску,
кнопки, буковки Caption-а и т.д. Вот и нерабериха там имеется.

Цитата:

формально по тексту хэлпа ты и прав.

Значится надо и хелп в
этой части подкрутить, а то вводит в заблуждение...

Цитата:

в любом случае HalfHeightCaption не должен влиять

Угу, должно
быть согласованно.

Цитата:

специально посмотрел в VB6

Это идёт от WinAPI, если считать
что свойства напрямую рулят стилями. НО конечно не для HalfHeightCaption
окна, т.к. там саму строку заголовка рисует фокс...

Цитата:

при BorderStyle = 4,5 (ToolWindow - васиковский аналог
HalfHeightCaption

AFAIK нет, стиля WS_EX_TOOLWINDOW у такого окна
нету - вроде фокс вообще такой стиль в формах и даже тулбарах не
использует... Посмотри если не лень Spy-ем какие стили у того окна будут...

Цитата:

имею весьма стойкое подозрение, что сабж - это не сознательный шаг, а
глюк

Да я согласен, похоже на то. Также обращает на себя внимание:
неестественный цвет блокированной кнопки закрытия (Closable = .F.),
игнорирование "тем" WindowsXP при наличии всех 3-х управляющих кнопок.

Цитата:

Ну вот и отлично, значит если в релизе все-таки решат оставить
сабжевое поведение, то есть обход

Не, пусть лучше фиксят, и среду
и документацию. Кстати - в порядке бредовой идеи - а как оно под рантаймом
выглядит то?

Цитата:

Если говорить о противоречиях, то гораздо более противоречиво вот
это:

Я уже как-то пытался прояснить немного что есть модальность в
понимании фокса - поищи по форуму - "модальность", "модальное состояние".
Кратко - модальность - это не свойство формы, а "состояние" фокса. И т.к. ты
в это состояние "вошёл" (показав модально форму), то пока не выйдешь -
будешь наблюдать подобные вещи ("усугубив" это дело ещё одним Show(1) или
MessageBox() можно порой поиметь дизейбленную X-кнопку для главного окна).
Но что-то мне кажется что для 90% (возможно конечно что я слишком строг тут
) разработчиков на фоксе мои объяснения будут слишком сложными, и
им проще думать так как описано в хелпе. А подобные "аномальные" ситуации
просто напросто никогда не использовать...

Aijik, привет. Пример показательный, а помнится мы стобой как-то обсуждали "странности" поведения As-Top-Level форм
Игорь Королев, у меня тоже есть свое, доступное для моего уровня, понимание модальности ;)
Вот я, например, женат, то есть запущен модально (не в смысле "все запущено"), и, следовательно, по моральным устоям другие женщины мне недоступны. Но вдруг я на некорое время "размодалился" ( ) и завел себе любовницу, незамужнюю, то есть немодальную, а потом (на утро) ко мне вернулась модальность, но с ней я расставаться не хочу, то есть я ее снова запускаю ("высоко") немодальную, но в это время она принадлежит только мне, то есть становится модальной по отношению к окружающим, хотя по определению - свободна
Это к тому, что все мы создаем по образу и подобию своему и операционки - не исключение

Описание бага отправлено на vfpfeed

2 Равиль
Сильно ;)


2 Igor Korolyov
Привет, Игорь!

Цитата:

AFAIK нет, стиля WS_EX_TOOLWINDOW у такого окна
нету - вроде фокс вообще такой стиль в формах и даже тулбарах не
использует... Посмотри если не лень Spy-ем какие стили у того окна будут...

Да, ты прав. Так оно и есть. Фоксовский HalfHeightCaption - самопал:

VFP9. Окно с HalfHeightCaption=.T.
****************************

Стили окна
---
WS_CHILD
WS_VISIBLE
WS_CLIPSIBLINGS
WS_CLIPCHILDREN
WS_BORDER
WS_THICKFRAME
WS_GROUP
WS_TABSTOP

Расширенные стили окна
---
WS_EX_NOPARENTNOTIFY
WS_EX_WINDOWEDGE
WS_EX_LEFT
WS_EX_LTRREADING
WS_EX_RIGHTSCROLLBAR

Стили класса
---
CS_OWNDC



Delphi6. Форма с BorderStyle=bsSizeToolWin
***********************************
Стили окна
---
WS_OVERLAPPEDWINDOW
WS_VISIBLE
WS_CLIPSIBLINGS
WS_CLIPCHILDREN

Расширенные стили окна
---
WS_EX_TOOLWINDOW
WS_EX_WINDOWEDGE
WS_EX_LEFT
WS_EX_LTRREADING
WS_EX_RIGHTSCROLLBAR

Стили класса
---
CS_DBLCLKS



[i][small][color=Gray]Отредактировано (14.10.04 11:45)

Ответ от MS:
"Опаньки... Мы упустили это, спасибо... Благодаря Вам баг обнаружен . Спасибо за тестирование... <ля-ля-тополя>"

2 Aijik
Круто ты их
Тут вот еще про неработающую F3 в Gride писали,
forum.foxclub.ru
может напишешь им - пусть поправят ;) пока не поздно...

Syberex 2 Aijik:

Цитата:

Круто ты их Тут вот еще про неработающую F3 в Gride писали,
forum.foxclub.ru
может напишешь им - пусть поправят ;) пока не поздно...

А лучше пуcть не поправят, а разовьют эту фичу в метод грида, то есть встроенный форматонезависимый поиск внутри грида, например метод Grid.Find()

2 Равиль
А зачем мне ихний Find жестко привязанный к F3,
если у меня на эту клавишу должна открываться форма редактирования...

Да и все равно не сделают, пусть бы хоть поправили

Syberex

Цитата:

А зачем мне ихний Find жестко привязанный к F3, если у меня на эту клавишу должна открываться форма редактирования...

Вот я и предлагаю отвязать этот механизм от F3 и вcтроить в метод грида с вызовом диалога типа Find&Replace - тогда всем будет хорошо А сделают или нет - читают же нас парни из MSFT ;)

Привет всем
Я отправил на vfpfeed описание этого явления с взятым за основу кодом Равиля
ИМХО F3 - баг однозначно. Тем более, что в рантайме возикает WAIT WINDOW с текстом "Not found". Примечательна вот эта цитата с топика "Interactive Development Environment (IDE) Enhancements":

Цитата:

When a Browse window is open and you search for a word with the Find dialog box, you can search for the word again (Find Again) after the Find dialog box is closed by pressing the F3 key.

Видимо, оттуда все и пошло...
В прошлый раз, у VFP8 были проблемы с F5, у VFP9 теперь вот с F3. Нездоровая тенденция, однако... ;)

2 Aijik
Спасибо

А ведь точно, в RelNotes написано, что в релизе будет поиск в брауз-окне по слову на F3 висеть.
(придется снова на Browse с Grid-ов переходить? )

Ответ от MS:

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



[i][small][color=Gray]Отредактировано (01.12.04 18:02)