Igor Korolyov

Taran
Действительно есть ошибочка. Имелось ввиду "Апофис".

Какой из оных? Все такие миляшки
[attachment 28319 Apophis.jpg]

Игорь, ну когда разве я мог блеснуть знаниями про шнурок полосатый и загорелого мальчугана?
Булыжник, это да. Напрягает. Ибо огород у меня. Тащи его потом за дорогу.

Igor Korolyov
Так оно ж не для дизайн-тайма то...

Да понятно. Я для Run-time.
Какой там мастер то для чекбокса нужен в дизайн-тайме?
Ежели на такую хрень городить огород, то ...
Ну не тема.

А для Run-time согласись caption_assign вполне к месту. Ну и соов. value_assign такоже и enabled_assign.
В принципе новые методы можно и не придумывать.
Стандартно свойства установил и вуаля.
В том числе и ControlSource аналогично можно обыграть.



Исправлено 1 раз(а). Последнее : Taran, 13.09.17 15:12

Taran
Игорь, ну когда разве я мог блеснуть знаниями про шнурок полосатый и загорелого мальчугана?
Булыжник, это да. Напрягает. Ибо огород у меня. Тащи его потом за дорогу.

Не, этот булыжник никуда тащить не придётся - ежели таки шлёпнется где-то километров за 400 до тебя или ближе, то про огород можно будет больше не беспокоиться... вообще... никогда

Taran
Да понятно. Я для Run-time.

Да, для рантайма этого достаточно.
Но сам согласись, при дизайне UI несколько напрягает то что ты не видишь реальные размеры контрола (автоподгонку тоже можно лишь в рантайме сделать, ну или опять таки при помощи Builder-а), и чего там на нём написано...
Особенно для автора темы, который даже тень "ужирнившую" буковки разглядел вот так сразу (я то под Magnifier-ом её разглядывал )

P.S. С ControlSource, боюсь, ничего не выйдет. Он очень уж хитрО в фоксе сделан - для его "ручной реализации" нужно иметь событие "изменение хранимых данных в..." для полей курсоров, простых переменных, свойств объектов... События такого нет даже в FoxAPI, а реализовывать через таймер или на рефрешах - криво, ненадёжно и в общем коряво до невозможности...
Лучше уж тогда просто сам текст ControlSource пробросить для "настоящего" фоксового контрола с таким свойством (можно, наверное, и для "невидимого" - скажем сдвинутого за границы видимой/внутренней части контейнера), и через него и работать - но это тоже решение не блещущее особой красотой.





Исправлено 1 раз(а). Последнее : Igor Korolyov, 13.09.17 15:23

Про булыжник ладно. Пошутили и забыли. Я в курсе что он слишком тяжеловат для моего огорода. ;)

Ежели говорить про интерфейс и дизайн а-ля CheckBox_From_Ce, то один такой объект не имеет смысла. Нужны будут и другие аналогичного дизайна.
Естественно это все в 99.9% прикладных программ абсолютно ни к чему.

Ежели некоторое приложение не для "бухгалтерии", то боюсь что и label в контейнере не пригодится.
Захочется рисовать целиком весь контрол. Чтобы и текст финтиперцевый был, например градиент какой etc.
Т.е. картинку галочки каждого состояния увеличить и текст туда врисовать.

ControlSource вполне можно обыграть. Чтобы не париться на анализ поле курсора это или свойство объекта.
Я в момент сохранения или чего еще создаю невидимый объект TextBox, прописываю туда ControlSource и получаю почти стандартное поведение изменения полей.
Смотреть конечно надо. Забыл уж.
С пяток контролов есть таких. Для ввода DateTime например контейнер с парой текстбоксов и кнопками ±...
Или календарь на кнопках.
Работает.



Исправлено 1 раз(а). Последнее : Taran, 13.09.17 15:58

Taran
создаю невидимый объект TextBox, прописываю туда ControlSource и получаю почти стандартное поведение изменения полей.

Я про то же... "Прямого" способа свой собственный ControlSource сделать увы нет... Разница между полем/переменной/свойством тут дело второе. Важнее двунаправленная связь - надо же не только при изменении в контроле запихать в источник, но и обратное - при изменении в источнике обновить данные в контроле. И визуально отображаемые (тут ещё пол-беды, на Refresh можно повесить), и программно доступные. А то будет ой нехорошо - где-то в другом месте поменяли переменную/поле, а ты по прежнему со "старым" значением играешь. Т.е. как бы сам принцип ControlSource нарушается. Тогда уж лучше вообще без него - чисто на Value работать, и полностью вручную туда-сюда значение гонять. Хотя бы будет очевидно что нет "автомата"

Вполне согласен что можно и через Value. Но Value какого объекта? А ежели он еще и внутри Control`а. А такого свойства может и вообще не быть.
Т.е. нужно как минимум пару методов для установки значения и для чтения.
Я все-таки предпочитаю замкнутость объекта. Прописал ему ControlSource и забыл. А уж как он там будет читать-сохранять без разницы.
Естественно присутствует ControlSource_Assign.
И, как правило, на таких контейнерах есть свойство Value, которое содержит актуальное значение. (Естественно и Value_Assign присутствует)
Т.е. максимально приближено к нативным контролам.
Более того, у таких контейнеров есть метод Valid.

--
Кажется мне ТопикСтартер не вернется. Или придет почитает и скажет: Да пошли вы все...

Я про то что можно сделать Value у контейнера, и при том адекватно работающее (да, через access/assign), не в пример проще и, скажем так, логичнее, чем сделать ControlSource. Всё же подход считал/записал явно гораздо проще в реализации чем "отследил когда нечто снаружи изменилось и синхронизировался с ним". Тем более в системе которая не предусматривает никаких извещений о том что снаружи что-то таки изменилось

Igor Korolyov
Я про то что можно сделать Value у контейнера...

Да я понял, понял. Не спорю - проще.
Просто у меня иначе. И всё.
В частности из-за того, что некоторые формы вообще не существуют, а строятся динамически.
И для единообразия описания метаданных-объектов все делается через CS.