Hi, All!

Возникло тут следующее предложение - расширить функциональности Anchor-а ещё
4-мя флагами - соответственно Stick to Left/Top/Right/Bottom (Прилепить к
Левой/Верхней...). Если Absolute привязка сохраняет изначальный промежуток
между контролом и границей контейнера, Relative - соответственно
пропорционально изменяет этот промежуток, то Stick to должно будет убрать
вообще соответствующий промежуток. Т.е. "прилепить" границу контрола к
соответствующей границе контейнера. Если заданы все 4 таких якоря, то
контрол займёт всю площадь контейнера.

Конечно всего этого можно добится и с помошью имеющихся якорей - просто
тогда приходится очень тщательно выравнивать контролы (и положение, и
размеры) при их начальном размещении на форме. Ну а якоря задать как
абсолютные или относительные - это уже неважно, т.к. ширина промежутка 0.

Если такая идея имеет право на жизнь, то прошу высказаться за. Я пока не
писал про это на vfpfeed.

P.S. На днях надеюсь смогу выложить в решения "эмулятор Anchor-ов" для VFP8
(но по идее он также должен работать на VFP7 и VFP6). В его рамках я
постараюсь реализовать и предложенное "расширение".

А мне и существующих возможностей вполне хватает.

Hi, Sergey!

Цитата:

А мне и существующих возможностей вполне хватает.

Это если рука тверда, а глаз зорок - а ежели нет? Я и сам часто подгоняя
размеры залажу в Property Window чтоб уточнить а скока-же реально форма
имеет в Width - ибо она то не по Grid-у ресайзится
В основном эти причины как говорится рулят...
Можно конечно оставить и "приблизительно", тока порой юзера попадаются
въедливые Даже не понимаю как они могут углядеть такие мелочи...

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

PUBLIC m.gfrmATest
m.gfrmATest = CREATEOBJECT('AnchorTest')
m.gfrmATest.Show()
WAIT WINDOW
m.gfrmATest.Hide()
STORE 300 TO m.gfrmATest.Height, m.gfrmATest.Width
m.gfrmATest.Show()
WAIT WINDOW
STORE 400 TO m.gfrmATest.Height, m.gfrmATest.Width

DEFINE CLASS AnchorTest AS Form
Height = 200
Width = 200
ADD OBJECT cntTest AS Container WITH Anchor = 15, Height = 100, Width = 100
ENDDEFINE

*В начале посмотри так, а потом закомментируй Hide и второй Show.

Из этого примера следует, что ANCHOR НЕ РАБОТАЕТ КОГДА СОДЕРЖАЩИЙ ЕГО ОБЪЕКТ НЕВИДИМ!

Если мы можем добиться результата более простыми путями, я скорее противник усложнения. Давным-давно я ввёл себе за правило - в настройках, на вкладке Forms, в Horizontal spacing и Vertical spacing устанавливать 10 и 5 соответственно, а также не бояться показывать сетку в дизайнере форм. Большинство проблем пропало . Если уж совсем невмоготу - можно переопределить размеры объектов кратными 5, а не 6 как по умолчанию. Не могу сказать, что мне хватает существующих возможностей, но скажу честно, больше бесит, когда дизайнер "забывает" размеры форм и произвольно их уменьшает на 20 - 50 px (причём в девятой версии это стало повторяться гораздо чаще, чем в восьмой). Безмерно раздражает, что в девятке, в отличии от предыдущих версий, когда в дизайнере начинаешь набирать текст, Лис вместо того, чтобы в текущем поле свойств начать вводить твои данные (как это было раньше), скачет как блоха по свойствам и объектам. Пусть они лучше ДОреализуют то, что уже сделали и IDE поправят.
Жутко убого выглядит софт с примитивно-на-коленке сделанныим формами. Посему всегда достаю народ требованием: "Смотрите как сделаны продкуты Microsoft, не ругайте, а учитесь у них!". Если призадуматься, то в большинстве продуктов формы у них сделаны, хорошо, качественно, с большим удобством. Многих начинающих программистов надо прогонять через ввод каких-либо карточек - после того они будут понимать, ЧТО ЗНАЧАТ TabStop и Hints!ЧТО ЗНАЧИТ удобство работы для пользователя, тем более оператора!
Тем более, что Anchor далеко не решает всех проблем. ("Дыба?" - "Дыба в натуре решает" - народная мудрость, Шматрица). До появления этой возможности в версиях 7 и 8 я делал для своих форм базовый класс, в котором определял четыре свойства nPrevHeight, nPrevWidth, nOffsetX, nOffsetY. В коде события Resize определял, что nOffsetX = ThisForm.Width - ThisForm.nPrevWidth, а потом сохранял ThisForm.nPrevWidth = ThisForm.Width дабы получить прирост по оси X и Y. Далее прибавлял xOffset к ширинам (Width) объектов входящих в форму и таким образом изменялись их размеры.
Но и сейчас, даже с Anchor приходится пользоваться всё тем-же методом. Пример - у нас есть Grid из трёх полей. При Resize этого Grid, установив Anchor = 15 мы получим не очень приятное зрелище - три ужатых столбца и пустота справа. Вывод будем Resize'ить, ну например второе поле. А на какую величину?! Вот и приходтся вспоминать былое

Hi, BladeRunner!

Ну тут сложно спорить но попробую
Насчёт "невидимого ресайза" - да, возможно что это баг, но не в анкоре.
Самое смешное, что мой эмулятор походу на 100% соответствует реализации MS -
т.е. твой тест он проходит точно также Пока не выложил в решения просто
опишу суть его работы:
1) В Init каждого контрола он запоминает свои начальные размеры
(Left,Top,Width,Height) а также начальную ширину и высоту своего контейнера
(ну там для Page своя фишка конечно . Эти 6 парметров позволяют получить
всё что нужно потом для работы якорей.
2) Также эти размеры запоминаются (уже новые!) по nAnchor_Assign - т.е. при
смене свойства.
3) В Resize всех классов-контейнеров прописан код обхода This.Objects (опять
же с понятным исключением для PageFrame где двойной цикл - Pages и внутри
Page.Objects) - и соответственно анализ, расчёт новых координат и
obj.Move() - т.е. рекурсии явной нету - просто по Move() срабатывает Resize
вложенных контейнеров. Пока только не реализовал принудительный Resize для
CommandGroup/OptionGroup - почему-то в этих контейнерах нету события Resize.
4) Я кстати как и в VFP9 Public Beta испытывал проблемы с "неперерисовкой"
контролов на страницах PageFrame, ну и т.п. (пришлось вставить Form.cls() -
это вроде помогает). Вот где пока не очень помогает - так это для TreeView
(возможно и иных ActiveX-ов) - пока этой заразе не передать фокус она не
всегда прорисовывается полностью

Теперь к проблемам. Твой код лишний раз демонстрирует, что для невидимой
формы Resize не срабатывает... Как у меня так и у MS Anchoring очевидно
на Resize и висит
Насчёт гридов - я считаю что там и не должно быть никакого Anchor-инга даже
близко - у меня давно было для колонок "пропорциональное расширение" в
классе, пока не перенёс в новый Framework, ибо думал существенно улучшить -
там была проблема потери пропорции после многочисленных сжатий/расжатий
грида (надо продумать как это решать идеологически!)

Цитата:

в настройках, на вкладке Forms, в Horizontal spacing и Vertical
spacing устанавливать 10 и 5 соответственно, а также не бояться
показывать сетку в дизайнере форм.

У меня она всегда и включена, но это НЕ ПОМОГАЕТ.
1) Форма при своём ресайзе (в дизайнере ессно) на сетку не смотрит! Получив
ширину формы в скажем 121 попробуй при "блокированном по сетке" размещении
контролов точно подстроить их ширину! Или наоборот - точно подстроить ширину
формы под шаг сетки
2) При вложенных контейнерах и тем более PageFrame-ах эта сетка скорее
мешает чем помогает - она то относительно формы рисуется/контролы цепляет, а
не относительно клиентских размеров контейнера Попробуй на лист PageFrame
выровненный по сетке положить скажем грид, чтоб он "точно" занял клиентскую
область (PageWidth+PageHeight в особенности) - вот где сложности начинаются

Я на 100% уверен, что если не предложенный мной якорь, то уж тулзу
дополняющую Layout тулбар (наверное свой собственный тулбар) и позволяющую
выровнять в дизайнере контролы по параметрам их контейнера (как и
предложено - хотя-бы "прибить" к той или иной границе контейнера). Делать
придётся

Цитата:

больше бесит, когда дизайнер "забывает" размеры форм и произвольно их
уменьшает на 20 - 50 px (причём в девятой версии это стало повторяться
гораздо чаще

Очень странно - у меня такие проблемы за всё время были
лишь с одной формой - со сплэш-скрином. И то там явно играло роль отсуствие
строки заголовка, BorderStyle формы, наличие Image по
координатам -1,-1,ширина+2,высота+2 (ну чтоб рамки никакой не было видно) и
т.п. Я правда этот сплэш уже года 4 не трогал, потому не знаю как оно в
VFP7/8/9 с этим дело обстоит

Цитата:

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

У меня именно вводит в то где стоит (ну если символ допустимый) но точно не
скачет. Может это какая настройка где слетела?

Цитата:

В коде события Resize определял

Мне знаком такой подход, я
как-то одному коллеге открыл глаза не его существеннейшие недостатки Он
даже переписал потом часть своего каркаса...
Попробуй активно так посдвигать/пораздвигать форму, увидишь как довольно
быстро накопятся ошибки округления и форма примет очень безобразный вид -
особенно тому способствует настройка винды "показывать содержимое окна при
перетаскивании" - тогда даже простой ресайз это не 1 срабатывание события, а
куча
Anchor в этом пладе значительно лучше - он всегда пляшет от "начальных
пропорций" (и "сбрасывает" их - точнее принимает новые - только по смене
содержимого Anchor - ну как в хелпе и написано) - и потому никаких ошибок не
накапливается, сколько форму не тереби

P.S. Не надеюсь на авторитетный разбор полётов, но может Алексей Цингауз
таки скажет своё веское слово?

Цитата:

Насчёт гридов - я считаю что там и не должно быть никакого Anchor-инга даже
близко - у меня давно было для колонок "пропорциональное расширение" в
классе, пока не перенёс в новый Framework, ибо думал существенно улучшить -
там была проблема потери пропорции после многочисленных сжатий/расжатий
грида (надо продумать как это решать идеологически!)

На мой взгляд Anchor-инг для гридов очень полезная штука.
Пропорциональное расширение зачастую не оправдано , так как есть колонки для которых не имеет смысла
увеличивать ширину (например даты или числовые коды) .
Проблема же потери пропорции решается довольно просто.
Сначала считаем число колонок , учавствующих в resize.
Далее делением вычисляем величину resize для 1 колонки.
Остаток от деления относим на любую колонку (например последнюю).
Интереснее (и сложнее ) сделать интелектульный resize , кода функция resize зависит от ширины grida.
Т.Е. при достижений определенной ширины прекратить (или начать) resize колонки .

Да, нам остаётся лишь уповать на Алексея ... что же до Grid'а - я поддерживаю Евгения - на мой взгляд он прав - есть поля который и не нужно расширять, а вот с Reisze - у меня никогда проблем не было - формы и объекты изменялись пропорционально и ничего не смещалось ... хотя ... ... я думаю Игорь - что это просто странности нашего любимого зверя - Лиса Уже не раз сталкивался - у одних людей возникают ошибки, о которых я и слыхом не слыхивал и наоборот.
А вот об ActiveX - хотелось бы отдельно поговорить ... и если это читает Alexey Tsingauz - пожалуйста, прокомментируйте - у меня стабильно наблюдаются проблемы с OleTree - два примера:
1. При помощи формы без заголовка и Border делается "выпадающий список" в виде дерева. При запуске форма не видна, т.е. используется NOSHOW - НО! тем не менее она на миг появляется, потом исчезает! ... а потом возникает снова. Хотя в коде чёрным по белому написано - запустить форму с параметром NOSHOW, построить дерево, показать форму! Если же изначально скрыть дерево, ещё на этапе дизайна установить Visible = False для дерева, а потом показать его вместе с показом формы - всё отрабатывает отлично!
2. Пример два - даже если указать, что OleTree находится ПОД к.-л. объектом, при показе формы он всё равно будет торчать как перст! Вот верхнего он уровня и хоть ты тресни!

С чем это связано - с такой релизацией OleTree и с чем-то ещё?

P.S.: Хотелось бы всё таки услышать комментарий о срабатывании невидимого Anchor'а.

P.P.S.: Не в тему конечно, но всё же - каковы перспективы расширения функциональность стандартных команд импорта\экспорта в соответствии с новыми версиями офисных продуктов - Word и Excel?

Hi, BladeRunner!

Цитата:

что же до Grid'а - я поддерживаю Евгения

Я тоже, только это
же не Anchor Это другие свойства - другая реализация. Думаю для начала
хватит только логического поля lNoResize - участвует колонка в
пропорциональном ресайзе или нет. Ну и ессно и тут надо плясать не от
"текущих значений ширины" а от начальных - иначе после пары-тройки-пятёрки
сдвинуть/раздвинуть получим одно широкое поле и все остальные узенькие -
это я уже проходил, потому и не спешу старый код переностить, а на написание
нового пока нету сил.
Нюансом там будет то, что "начальные пропорции" надо сбрасывать при ручном
изменении ширины колонок. А ещё надо продумать как-то "порог работы
авто-ресайза" Если грид сильно ужимают, то ужимать колонки до ширины 2-3-4
пиксела смысла IMHO никакого нету - надо остановится, и пускай появляется
горизонтальный скроллер. Возможно это лучше сделать как свойство nMinWidth
для каждой колонки (тогда напрашивается и nMaxWidth - а значит можно
спокойно убрать флаг lNoResize - вместо того ставить Min=Max). В общем пока
мысль не сформировалась, лучше подождать...

Цитата:

а вот с Reisze - у меня никогда проблем не было

Зависит от
того как тестировать Попробуй ради эксперимента включив в винде "показ
содержимого окна при перетаскивании" свои формы интенсивно покачать -
сузить-расширить-сузить и так пару раз. IMHO всякая схема "относительного"
ресайза (т.е. "от предыдущего к текущему") при этом даёт сбои (накапливаются
ошибки округления) - тогда как схема "от начального к текущему" тут работает
заметно лучше.

Цитата:

А вот об ActiveX - хотелось бы отдельно поговорить ...

Ну
надо было отдельной веткой писать Причём не в VFP9 форуме.

Цитата:

При запуске форма не видна, т.е. используется NOSHOW.... Пример два -
даже если указать, что OleTree находится ПОД

Всё это вытекает из
особенностей реализации UI в фоксе - свои контролы фокс рисует сам, а
ActiveX-ы рисует винда - они являются полноценными окнами, имеют свои хендлы
и т.д. От того и "мелькает" дерево (хотя это IMHO можно исправить - просто
анализ усложнить в коде создания/внедрения ActiveX-а на форму). От того и не
может что-то рисуемое НА форме (как все фоксовые контролы) оказаться
нарисованным поверх ДРУГОГО окна (в смысле Винды) - дерева.

Цитата:

Хотелось бы всё таки услышать комментарий о срабатывании
невидимого Anchor'а.

И Resize для невидимой формы, как первопричины
Надо либо исправить, либо документировать!

P.S Я выложил свой "Anchor эмулятор" - надеюсь он вскоре будет доступен для
скачивания.

Цитата:

Это если рука тверда, а глаз зорок - а ежели нет? Я и сам часто подгоняя
размеры залажу в Property Window чтоб уточнить а скока-же реально форма
имеет в Width - ибо она то не по Grid-у ресайзится

Вообще предпочитаю точно устанавливать размеры формы
Видеть сетку и т.д.

Цитата:

В основном эти причины как говорится рулят...
Можно конечно оставить и "приблизительно", тока порой юзера попадаются
въедливые Даже не понимаю как они могут углядеть такие мелочи...

Вообще сейчас появилось много разных прог (особенно бухгалтерских),
где размещение контролов просто ужасно.
Иногда даже вместо ресайза делают масштабирование , причем с маштабированием
шрифтов - по моему верх непонимания законов оконного интерфейса.
Уровень интерфейса современных ОС требует от программиста и дизайнерских
способностей, а если не умеешь надо учится. (даже как-то необычно говорить это тебе Игорь,
да и слышать от тебя такое прямо таки неожиданно )

Цитата:

Зависит от того как тестировать Попробуй ради эксперимента включив в винде "показ содержимого окна при перетаскивании" свои формы интенсивно покачать -сузить-расширить-сузить и так пару раз. IMHO всякая схема "относительного" ресайза (т.е. "от предыдущего к текущему") при этом даёт сбои (накапливаются ошибки округления) - тогда как схема "от начального к текущему" тут работает заметно лучше.

Попробовал потестить по твоей методике - в гриде 5 колонок , 3 из них resize.
Включил показ содержимого окна при перетаскивании. Действительно сбой появляются. Придется подумать о переходе к схеме "абсолютного ресайза"



[i][small][color=Gray]Отредактировано (04.10.04 09:29)

А я за. Насколько я понял эта возможность менять размеры контролов на форме при изменении размеров формы. Уж извините я про Delphi. Там сделано так.
Есть свойство Align - его значения:
alTop
alBottom
alClient
alLeft
alRight
alNone

Дополнительно имеются еще и минимальные / максимальные размеры кажого контрола

Да и еще. Мне когда переходил на Delphi очень понравилось возможность изменения размеров групп объектов использую Splitter - ы. Т.е. разделители. Идея вот в чем. Делается панелька с элементами. Выставляются все Align на панельке. У панельки Align = alClient. Соответственно изменяем размеры формы - меняются положения объектов. Добавляем еще 1 панельку и ставим у нее Alignment = например alTop между ними сплиттер - можно менять размеры панелек а следовательно и объектов...

Я этим в VFP не пользуюсь. Потому что не знаю как это делать...

Hi, Syberex!

Цитата:

Вообще предпочитаю точно устанавливать размеры формы

А это как? Пока не раскидаешь контролов точно и не знаешь что будет А как
раскидал, то я например считаю (в уме или на калькуляторе ) скока же там
занимает реально нижний-правый контрол, скока надо форме поставить чтоб
Indent был такой-же как и сверху и слева... Ну если на форме "заполняющие"
контролы - тот-же грид, то проще - отступ значит 0, достаточно посчитать
Top+Height и Left+Width. Но ведь напрягает! хочется избавится от такой
ручной работы

Цитата:

Иногда даже вместо ресайза делают
масштабирование

Да, бывает. Я вот сейчас начинаю задумываться, как получше реализовать
авто-подгонку с учётом выбранной в винде "Большой" темы (когда шрифты не
8-9, а там 12-14 кегля), и с Custom настройкой DPI (ну тоже на размеры
влияет - хотя кегль и не меняется, но физический размер буковок - меняет).

Цитата:

причем с масштабированием шрифтов - по моему верх непонимания

ну вопрос сложный Конечно когда на здоровом мониторе форма выводится с
аршинными буквами - это нехорошо. Но когда юзерские настройки размеров
шрифтов "побоку" - это не лучше

Цитата:

а если не умеешь надо учится.

Надо... Но как говорится ежели с рождения слеп... Будем хотя-бы "принципам"
следовать. До "переливающихся" заливок, фигурных кнопок и т.п. мне к
сожалению далеко

Hi, Андрей!

Цитата:

А я за. Насколько я понял эта возможность менять размеры контролов на
форме при изменении размеров формы.

Это вообще-то _расширение_ имеющихся в VFP9 средств. Посмотри в разделе
решений...

Цитата:

Есть свойство Align - его значения

У нас их вроде даже
побольше Вот alClient нету, я и предлагал нечто подобное...

Цитата:

Дополнительно имеются еще и минимальные / максимальные размеры кажого
контрола

Хм. Может и это сделать?

Цитата:

использую Splitter

На UT есть неплохой класс - ActiveX Aware
splitter вроде называется. Я его чуток переделал под наши нужды (ну прописал
жестко метод Split, чтоб не нужно было самому юзеру думать - он всё что
слева - ужимает, что справа - расширяет - ну или наоборот Для
горизонтального соответственно другая ось. В принципе для "надежности и
очевидности" рекомендуется иметь лишь по 1 контролу справа и слева (сверху и
снизу) - контейнеры - ну а уж в них...) Если надо, могу выложить... Он
сейчас настроен на мой анкоринг (VFP8), но заменив везде nAnchor на "просто
Anchor" будет работать и со встроенным в VFP9...

Цитата:

Делается панелька с элементами

Ну да, у нас это контейнер будет Тока вот alClient нету, но зато есть
другие, почти аналогичные якоря

Цитата:

Ты знаешь Игорь, всё же если призадуматься, то я против. Объясню почему - любое расширение возможностей - это усложнение, усложнение - это потенциальная возможность возникновения ошибки. Не буду далеко ходить за примером, проверь этот код пожалуйста, либо лыжи не едут, либо как говорится, одно из двух:
PUBLIC m.gfrmATest
m.gfrmATest = CREATEOBJECT('AnchorTest')
m.gfrmATest.Show()
WAIT WINDOW
m.gfrmATest.Hide()
STORE 300 TO m.gfrmATest.Height, m.gfrmATest.Width
m.gfrmATest.Show()
WAIT WINDOW
STORE 400 TO m.gfrmATest.Height, m.gfrmATest.Width

DEFINE CLASS AnchorTest AS Form
Height = 200
Width = 200
ADD OBJECT cntTest AS Container WITH Anchor = 15, Height = 100, Width = 100
ENDDEFINE

*В начале посмотри так, а потом закомментируй Hide и второй Show.

Из этого примера следует, что ANCHOR НЕ РАБОТАЕТ КОГДА СОДЕРЖАЩИЙ ЕГО ОБЪЕКТ НЕВИДИМ!

Попробовал в одном из последних билдов, визуальной разницы не наблюдаеьтся. Деталей уже не помню, но, по-моему, Anchor применяется при показе скрытой формы.

Aleksey Tsingauz
Visual FoxPro Dev Team

2Aleksey Tsingauz

Большое спасибо, что не оставили без внимания!