Технический форум по робототехнике.
=DeaD= » 08 сен 2011, 22:52
Michael_K писал(а):Вот в концепции "биндинга" такая процедура мне кажется уж очень корявой.
Ну, по крайней мере, неочевидной с моей точки зрения.
А в чем именно корявость - есть форма, в ней элементы "забиндены" на переменные, есть методы формы, закрытые для основного кода (основной код про такую фичу ничего не знает, он думает, что просто пользователь подряд в каждом элементе управления выставил новое значение), позволяющие выставить пакет настроек, ранее сохраненный куда-то, где грабли?
Уж простите за явно неуместную аналогию, просто каждый день работаю - в 1С есть такая вешь, как сохранение настроек формы - оно все значение позволяет сохранить под заданным именем и потом любой пакет настроек взять готовый из таких "комбо". Обычный код в форме ничего про пакетное сохранение настроек не знает.
Michael_K » 08 сен 2011, 22:56
С моей точки зрения корявость в том, что дизайнер в этом случае должен описать эти самые "методы формы", то есть программировать. Это типичная концепция "вижуал-бейсика"...
Или я вас не так понял?
К чему это приведет - к тому, что каждому элементу интерфейса (даже самому тупому) придется прикручивать обработчики событий (которые теоретически дизайнер может или должен программировать). Это доставит массу неявных проблем - например, придется реализовывать дебаггер, обработчики ошибок ран-тайма.
Последний раз редактировалось
Michael_K 08 сен 2011, 23:00, всего редактировалось 1 раз.
Сергей » 08 сен 2011, 22:59
Michael_K писал(а):Вы действительно не понимаете, или притворяетесь?
Вы можете ответить на мой вопрос? Почему и в каком месте приведенный пример реализации не решает задачу разработки GUI отдельно от функционала прибора? Форма рисуется отдельно, а потом байндится к функционалу и состоянию прибора.
Michael_K » 08 сен 2011, 23:02
Рпаспишите, пожалуйста, как происходит процесс, скрытый у вас за словами "а потом байндится".
Angel71 » 08 сен 2011, 23:03
Сергей, да какая разница на чём вы пишите? хоть на чистом си пишите, используя на меге свою графическую библиотеку, подгружая только файлы уи (без всякого встроенного в них кода). нужно просто реализация паттерна, т.е. нужно написать код, а не выбрать на чём писать.
вот несколько примеров
откомпилированное здесь
Сергей » 08 сен 2011, 23:08
Я и предлагаю реализацию паттерна. Я пишу уже год на XAML, и считаю эту технологию очень удачной. Я предлагаю тот же XAML, только в упрощенной форме в виде XML + Binding. Хотите примеров - смотрите примеры XAML.
=DeaD= » 08 сен 2011, 23:08
Michael_K писал(а):С моей точки зрения корявость в том, что дизайнер в этом случае должен описать эти самые "методы формы", то есть программировать. Это типичная концепция "вижуал-бейсика".
Или я вас не так понял?
Ага, не так
я имею в виду, что дизайнер максимум может сказать "этот контрол не сохранять в настройках", но лучше и это отпилить, чтобы дизайнер вообще не мог потрогать инструмент пакетных настроек - лучше всего место под такой инструмент зарезервировать где-нибудь в тулбаре приложения. Возможно это потребует небольшого расширения фреймворка, но вроде не фатально и достаточно прозрачно - об инструменте пакетных настроек таким образом знает только разраб фреймворка, а дизайнер и само функциональное приложение про него не знает.
Michael_K » 08 сен 2011, 23:13
А, тогда, да. Вот я о таком и думаю как раз!
Только набор инструментов придется сильно расширять под вот такие спецслучаи.
Это не страшно, конечно...
С ходу, правда, фиг все предусмотришь, но по ходу, думаю, мясо будет нарастать.
=DeaD= » 08 сен 2011, 23:19
А что за другие спецслучаи есть? Я кроме сохранения пакета настроек ничего особо не встречал...
Michael_K » 08 сен 2011, 23:22
Angel71 писал(а):хоть на чистом си пишите, используя на меге свою графическую библиотеку, подгружая только файлы уи
Именно это и сейчас уже реализовано (и работает) - Сишный код подгружает картинки, показывает их и т.п. Ну, пусть луа это будет делать - какая разница?
И тут прибегает "зоказчег" и говорит, а давай время сеанса задавать не в окне измерения параметров, а после, а на первом экране вставим кнопку "пропустить измерения" и "сменить язык интерфейса"...
И он, зараза, делает это по три раза в день, потому что прибор "многофункциональный"
А ведь он еще и через пару лет прибежит, и хорошо если ко мне - вот тогда вопрос ясной структуры будет стоят очень остро.
Angel71 » 08 сен 2011, 23:23
Сергей, ксамл - это язык разметки.
ни больше, ни меньше. а то, про что вы пишете складывается из взаимодействия кучи "кирпичиков", один из которых ксамл.
Michael_K » 08 сен 2011, 23:30
=DeaD= писал(а):А что за другие спецслучаи есть? Я кроме сохранения пакета настроек ничего особо не встречал...
Ну там много всяких необычных элементов будет - например, придется делать специальные элементы, которые одновременно являются индикаторами и элементами управления. Например, ты прибавляешь ток слайдером, а он дальше не хочет расти (например сопротивление нагрузки слишком велико), и должен тебе об этом сказать.
Причем, если ток больше некоторого порога, то окно не должно "уметь закрываться", пока ток не спадет и т.п.
Некоторые величины нельзя менять слишком быстро - параметры должны регулироваться, но обязаны нарастать плавно.
Там куча всяких таких ограничений (медицина, млин)...
Последний раз редактировалось
Michael_K 08 сен 2011, 23:34, всего редактировалось 1 раз.
Сергей » 08 сен 2011, 23:34
Вы о своем, я о своем. Ладно, забейте - в итоге все-равно получится то, что я и имел ввиду
Ну и посмотрите примеры, так, на всякий случай
http://msdn.microsoft.com/en-us/library/ms752059.aspxhttp://www.wpftutorial.net/XAML.html
Виталий » 08 сен 2011, 23:38
С моей точки зрения корявость в том, что дизайнер в этом случае должен описать эти самые "методы формы", то есть программировать. Это типичная концепция "вижуал-бейсика"...
Ну согласитесь, что специфика создания интерфейсов, т.е. _интерактивных_ картинок, диктует необходимость написания какого-то кода. Но дело в том, что реализовать это одному в разумный срок - нереально.
=DeaD= » 08 сен 2011, 23:39
Вроде всё имеет очевидные решения:
Michael_K писал(а):Например, ты прибавляешь ток слайдером, а он дальше не хочет расти (например сопротивление нагрузки слишком велико), и должен тебе об этом сказать.
Это составной элемент, у него просто несколько биндов.
Michael_K писал(а):Причем, если ток больше некоторого порога, то окно не должно "уметь закрываться", пока ток не спадет и т.п.
А вот это уже программирование, а не дизайн интерфейса, причем "по определению".
Michael_K писал(а):Некоторые величины нельзя менять слишком быстро - параметры должны регулироваться, но обязаны нарастать плавно.
Опять же составной элемент. Возможно на уровне программной логики надо делать объект, получающий целевое значение и выдающий текущее управляющее, но это тоже точно не GUI.
Michael_K писал(а):Там куча всяких таких ограничений (медицина, млин)...
И масса их явно выходит за пределы GUI
