roboforum.ru

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

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

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

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

Или я вас не так понял?

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

Вы можете ответить на мой вопрос? Почему и в каком месте приведенный пример реализации не решает задачу разработки GUI отдельно от функционала прибора? Форма рисуется отдельно, а потом байндится к функционалу и состоянию прибора.

Рпаспишите, пожалуйста, как происходит процесс, скрытый у вас за словами "а потом байндится".

Сергей, да какая разница на чём вы пишите? хоть на чистом си пишите, используя на меге свою графическую библиотеку, подгружая только файлы уи (без всякого встроенного в них кода). нужно просто реализация паттерна, т.е. нужно написать код, а не выбрать на чём писать.
вот несколько примеров



откомпилированное здесь

Я и предлагаю реализацию паттерна. Я пишу уже год на XAML, и считаю эту технологию очень удачной. Я предлагаю тот же XAML, только в упрощенной форме в виде XML + Binding. Хотите примеров - смотрите примеры XAML.

Ага, не так я имею в виду, что дизайнер максимум может сказать "этот контрол не сохранять в настройках", но лучше и это отпилить, чтобы дизайнер вообще не мог потрогать инструмент пакетных настроек - лучше всего место под такой инструмент зарезервировать где-нибудь в тулбаре приложения. Возможно это потребует небольшого расширения фреймворка, но вроде не фатально и достаточно прозрачно - об инструменте пакетных настроек таким образом знает только разраб фреймворка, а дизайнер и само функциональное приложение про него не знает.

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

А, тогда, да. Вот я о таком и думаю как раз!
Только набор инструментов придется сильно расширять под вот такие спецслучаи.
Это не страшно, конечно...

С ходу, правда, фиг все предусмотришь, но по ходу, думаю, мясо будет нарастать.

А что за другие спецслучаи есть? Я кроме сохранения пакета настроек ничего особо не встречал...

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

Именно это и сейчас уже реализовано (и работает) - Сишный код подгружает картинки, показывает их и т.п. Ну, пусть луа это будет делать - какая разница?

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

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

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

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

Причем, если ток больше некоторого порога, то окно не должно "уметь закрываться", пока ток не спадет и т.п.

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

Там куча всяких таких ограничений (медицина, млин)...

Вы о своем, я о своем. Ладно, забейте - в итоге все-равно получится то, что я и имел ввиду
Ну и посмотрите примеры, так, на всякий случай
http://msdn.microsoft.com/en-us/library/ms752059.aspx
http://www.wpftutorial.net/XAML.html

Ну согласитесь, что специфика создания интерфейсов, т.е. _интерактивных_ картинок, диктует необходимость написания какого-то кода. Но дело в том, что реализовать это одному в разумный срок - нереально.

_________________
Все новости о моих проектах http://savethebest.ru

Вроде всё имеет очевидные решения:


Это составной элемент, у него просто несколько биндов.


А вот это уже программирование, а не дизайн интерфейса, причем "по определению".


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


И масса их явно выходит за пределы GUI

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов