Вверх ↑
Этот топик читают: Гость
Ответов: 9906
Рейтинг: 351
#1: 2006-09-25 00:36:27 ЛС | профиль | цитата
В этом примере
Add(ChildPanelEx,6277293,238,112)
{
}
BEGIN_SDK
Add(EditMultiEx,11435705,3,3)
{
Width=188
Height=130
}
Add(Panel,14080006,35,28)
{
Width=648
Height=23
Align=2
}
Add(Button,8738818,133,28)
{
Left=105
Height=23
Align=1
}
Add(Edit,12781221,112,49)
{
Width=105
Height=23
Align=1
}
END_SDK
ухищрения с Z-координатой не дают расположить батон справа
Неправильно как-то все это у нас сделано....

[size=-2]------ Добавлено в 00:36
Вроде и "ошибкой в компонентах" не назовешь...
Но и не "среда" же
карма: 9

0
vip
#1.1контекстная реклама от партнеров
Ответов: 278
Рейтинг: 4
#2: 2006-09-25 00:44:34 ЛС | профиль | цитата
Это точно, именно батон ломится вперед всех
карма: 0
Время верстки: %cr_time% Текущее время: %time%
0
Ответов: 3655
Рейтинг: 69
#3: 2006-09-25 00:55:27 ЛС | профиль | цитата
Galkov, Хотел сделать такой компонент Edit +кнопка - неполучилось.
Гораздо удобнее было бы, и этой проблемы бы, небыло.
карма: 0

0
Ответов: 9906
Рейтинг: 351
#4: 2006-09-25 01:09:09 ЛС | профиль | цитата
Ну, можно и уточнить...
1) Самый нижний батон ломится вперед всех
2) Самый нижний Edit ломится в зад всех


Причины-то понятны: контролы батонов создаются в конструкторах, а Edit-ов - а методах Init (которые позже всех конструкторов, и порядок которых обратен Z-координате)
Получается, что нужен фиксинг (в плане наведения порядка) во всех Win-элементах

кстати о порядке...
На форуме был пример (это было там), когда форма (в понимании Билла) так и не создавалась до окончания инициализации. И оказывалась, следовательно, самой нижней, независимо от декларированной нами Z-координаты.
Т.е., наши коды НЕ ГАРАНТИРУЮТ создания формы по окончании метода Init
А это - непорядок

карма: 9

0
Администрация
Ответов: 15294
Рейтинг: 1518
#5: 2006-09-25 02:02:27 ЛС | профиль | цитата
Galkov, судя по такому:
code_308
задача это не тривиальная....
карма: 26
0
файлы: 1code_308.txt [541B] [451]
Ответов: 9906
Рейтинг: 351
#6: 2006-09-25 12:16:22 ЛС | профиль | цитата
Ну собственно привязками Кладов занимается, а не Билл...
И не по каждому чиху...
И если чихнуть таким образом (например): code_311
то срабатывает...
Но Кладов работает с Align в порядке создания контролов, а это не тоже самое, что порядок создания форм (CreateWindowEx), определяющий Z-координату.
А тогда необходимо либо ВСЕ конструкторы помещать в Create-элемента (что, видимо, не получится), либо ВСЕ - в Init-элемента.


P.S. С TabOrder-ом еще не разбирался, но там те же чудеса, кажется будут....

карма: 9

0
файлы: 1code_311.txt [832B] [498]
Ответов: 9906
Рейтинг: 351
#7: 2006-09-26 21:52:31 ЛС | профиль | цитата
Не получается сортировать посты по темам..............


1) Имея в виду исправно работающий Splitter, не понятно, почему onResize есть только у MainForm, а не у Win

2) Работа со Splitter-ом очень большие напряжения вызывает. Коллега tsdima научил, конечно... Но не факт, что кроме нас, у кого-то еще хватит здоровья расставить больше 3-х по своему желанию. Отсюда предложение: ликвидировать его как элемент, но ввести дополнительно в св-во Align win-элемента дополнительные 4 значения, типа: caLeft+Splitter; в этот же win-элемент добавить группу св-в, персонально для возможного Splitter-а

3) Глядя на предыдущие пп., можно сделать вывод, что очень непросто это делать без механизма наследования св-в и точек. Не считая того, что у меня и так (без Splitter-ов) такого уже есть...

4) А, глядя на предложения из пп.3 повнимательней, понимаешь, что все возможные св-ва выводить для юзера глупо, а порой и вредно. А отсюда мысль про вкладку "дополнительных" св-в (аналогичную точкам), с той логикой работы, что если св-во не попало в "основную" вкладку (путем оптичивания в "дополнительной" ) - то и CodeGen про нее ничего не знает. Не выполняет присваиваний, в смысле...
карма: 9

0
Администрация
Ответов: 15294
Рейтинг: 1518
#8: 2006-09-26 23:05:11 ЛС | профиль | цитата
На данный момент вне зависимости от правильности этих предположений заниматься такими преобразованиями нет возможности.
карма: 26
0
Ответов: 9906
Рейтинг: 351
#9: 2006-09-27 18:01:48 ЛС | профиль | цитата
Ну и ладно: Ограничивает это не столько мои возможности, сколько возможность поделиться своими результатами.

1) Добавить "ручками" строки в ini-файлы нужных мне элементов - не столь уж и большая работа. Но делает результаты работы плохо передаваемыми другим, и, следовательно, ограничивает объем тестирования.
2) С местом вызова конструкторов контроллов сам попробую разобраться - все равно нужно.
3) У себя-то я включу коды Splitter-а в win.pas Что потеряю: не отработает редактор формы элемента Splitter - сделаю корректировку размера контролла на его размер
Зато не буду заморачиваться с их расстановкой, как на форме, так и на схеме - вместо мучений по поводу их Z-координат, просто включу св-во Splitter в нужных контроллах.

Получится очередное отклонение от дистрибутива, почти не передаваемое другим - изменения в системных файлах. И опять - "у меня это работает:"
карма: 9

0
Администрация
Ответов: 15294
Рейтинг: 1518
#10: 2006-09-27 18:54:21 ЛС | профиль | цитата
Galkov, в данном случае идею включать сплиттеры в win не разделяю, даже если это прекрасно будет работать. Кроме того точно такой же код на VCL расставит контролы совершенно верно и заниматься таким образом залатыванием недоделок KOL не имеет смысла.
карма: 26
0
Ответов: 9906
Рейтинг: 351
#11: 2006-09-27 19:48:23 ЛС | профиль | цитата
Вот не смог уловить логики , в следствии которой:
из недостатков (или достатков) KOL (или VCL) следует необходимость выбора менее удобного (и менее понятного) интерфейса пользователя
карма: 9

0
Администрация
Ответов: 15294
Рейтинг: 1518
#12: 2006-09-27 20:28:30 ЛС | профиль | цитата
менее удобного (и менее понятного) интерфейса

где такое написано - хочу почитать А логика заключается в том, что Splitter есть элемент, который мягко говоря не обязан вести себя(да и выглядеть тоже) так, как Splitter в KOL. Объединение его и Win это тоже самое, что Menu+Form или StatusBar+Form(такой подход до сих пор демонстрировал одни только проблемы)... идея засунуть все в один компонент хороша, но до определенной степени.
карма: 26
0
Ответов: 9906
Рейтинг: 351
#13: 2006-09-27 22:23:18 ЛС | профиль | цитата
Dilma писал(а):
менее удобного (и менее понятного) интерфейса

где такое написано - хочу почитать

Нигде не написано.
Один интерфейс - то что есть сегодня. Что он вызывает вопросы - достаточно сообщений на форуме. Если вопрос в этом - можно все ссылки и найти...
Второй - это то, что сейчас у меня (но что пытался описать в постах выше). Если конкретно, то в самый конец THIInit.Init дописано:
   if _prop_SizeSp>0 then
    begin
Split := NewSplitterEx(FParent,0,0,_prop_BevelSp);
with Split{$ifndef F_P}^{$endif} do
begin
Width := _prop_SizeSp;
Height := _prop_SizeSp;
Color := _prop_ColorSp;
Enabled := _prop_EnableSp;
Visible := _prop_VisibleSp;
if Align in [caTop,caBottom] then
Control.Height := Control.Height - _prop_SizeSp
else
Control.Width := Control.Width - _prop_SizeSp;
end;
end;
А в INI нужных win-элементов дописан комплект св-в:
##Splitter=Динaмичecкoe измeнeниe paзмepoв элeмeнтoв нa фopмe вo вpeмя выпoлнeния пpoгpaммы
SizeSp=Размер Splitter-а, Активизирован, если >0|1|0
VisibleSp=Splitter виден/скрыт|14|0|True,False
EnableSp=Splitter разрешен/заблокирован|14|0|True,False
ColorSp=Цвет Splitter-а|8|clBtnFace
BevelSp=Определяет внешний вид Сплиттера|14|2|esRaised,esLowered,esNone
##

И, естественно, +логически из предыдущего следующее: определения полей
   ....
   protected
Split:PControl;
....
public
....
//Св-а Splitter-а
_prop_SizeSp:integer;
_prop_VisibleSp:boolean;
_prop_EnableSp:boolean;
_prop_ColorSp:TColor;
_prop_BevelSp:TEdgeStyle;
....
и +добавка Split.free в деструктор

И вот , как мне кажется, расставить Splitter-ы в таком варианте - просто без проблем
И нарушений "визуальности" как-то не вижу - какая визуальность у элемента без точек...
карма: 9

0
Гость
Ответов: 17029
Рейтинг: 0
#14: 2006-09-27 22:57:32 правка | ЛС | профиль | цитата


Редактировалось 3 раз(а), последний 2021-05-21 12:55:28
карма: 0

0
Ответов: 9906
Рейтинг: 351
#15: 2006-09-28 00:29:42 ЛС | профиль | цитата
Да нет особой проблемы...
Если не считать того, что <Редактор форм> их может поменять местами Drag-and-Drop, а Z-координаты элементов при этом не меняет (у меня 156-я)

А должен бы - по любому
И должен я согласовать эти координаты у двух элементов, а не у 4-х - как бы совсем не проблема

[size=-2]------ Добавлено в 00:29
Собственно я не уверен, что речь идет именно об этой проблеме - просто другой у меня не наблюдается...

НО
Это же вовсе не проблема Splitter-а.
Нет его - все равно положение в редакторе форм может не соответствовать откомпилированному.
Так у меня сегодня
Привожу в соответствие, регулируя Z-координаты элементов (нету никаких Splitter-ов)

Привел.
А вот теперь давайте сравнивать
Предстоящие мучения со Splitter-ами, с несколькими щелчками в панели св-в нужных компонентов

карма: 9

0
Сообщение
...
Прикрепленные файлы
(файлы не залиты)