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

Та ничего он не хранит. У всех контейнеров есть свойство DataContext, все данные там, а вложенные контролы просто могут привязываться к ним.

Чиво?  

Мне сложно говорить о том, кто кого уделает, ибо не в курсе. Ява и нет - платформы с родственной идеологией, развиваются, так скажем, с оглядкой друг на друга. Тем не менее мое поверхностное знакомство с явой как-то не очень впечатлило. Понятно, что сравниваю с нетом, который просто знаю лучше, но тем не менее, думаю, что и у тебя недостаточно инфы, чтобы делать такие выводы.

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

Ее же. Тогда на русском языке было доступно две книжки: Мак-Дональда и Петцольда, - Мак-Дональд первым попался  

Я тебе больше того скажу, в винфрмах тоже есть привязки. И там не просто можно привязать данные к контролам, а можно без кода, прямо в дизайнере реализовать функционал master/details или, к примеру, фильтрацию списка, путем выбора в другом списке чего-то(когда они связаны), я уже говорил тебе, что в датасете присутствует коллекция таблиц и связей, так вот свойства контролов можно привязывать и к тому и к другому. И чо? Думаешь этим можно было кого-то удивить?

  

Поясни.

Это пример использования довольно старого интерфейса, который неплохо себя зарекомендовал еще в винформах
http://msdn.microsoft.com/query/dev11.quer...%29&rd=true
Здесь все дело в том, что событие обрабатывается платформой, а не "ручным" кодом. Хотя интересно было бы посмотреть, как подобный функционал реализовал бы ты без литералов. Я думаю, бесполезного кода было бы больше.

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

А контроллер тогда что делает в мвц к примеру? Весь смысл этого действа как раз в разделении. 


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

Откуда эта статистика? Несколько страниц назад ты написал, что запустил впф, малость поковырялся, решил что г-но и бросил. Теперь выдаешь "точные" цифры.

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

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


В том, что они написали "очень хороший код" тоже .Net виноват?  

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

Похоже что вас пугает XAML. На самом деле можно просто накидать контролы и компоненты, ничего на меняя и не написав ни строки XAML. Оставив всё как есть стандартно. Нащелкать событий и т.р. и будет счастье. 
Но зато если нужно чтото сделать по другим требованиям, то здесь WPF (и братик Silverlight) предоставляет массу возможностей, ну очень много... Я лично стараюсь, что касается гуя и не только, всё делать с ними, если это возможно.

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


Мои пояснения приведены ниже этой фразы


Здесь дело в том, что если вместо символа "C" разраб наберет символ "C", то стрельнет это (если стрельнет) только в рантайме. 


Я так понимаю - реализует логику переключения вью и обеспечивает взаимодествие вью с контроллером 
Я не знаток тонкостей MVC. Просто читал много гневных статей о пхп###ерах, размещающих логику на контроле. Да и впедевике это вроде как отражено


Так-то вообще ничо. Повторюсь, я просто пытаюсь понять что такое MVVM, и оценить степень его революционности.

Добавлено через 13 минут и 41 секунду

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

Если XAML это не код а данные, странно что в данных присутствует ссылки на структуры программного кода. Надеюсь что валидность этих ссылок проверяется при сборке, иначе это будет тоска-тоска.

Ну само собой замерить тут ничего нельзя, но расклад описывает достаточно верно, для одиночного разработчика даже древняя D7 дает сравнимую с последней VS продуктивность и удобство. Новые версии еще больше сближаются. Для меня в таких условиях куда более значимы поддержка имеющегося и эстетические предпочтения.

XAML это не данные и не код как таковой. Это формальное декларативное представление того как будет выглядеть и с чем будет взаимодействовать наш любимый гуй. Причем ясно что чем больше програмист о нем знает тем лучше. Но в тоже время аж два графических дизайнера с ним работают так, что хватит немного мозгов и умения двигать мышкой к тому чтобы вообще не лезть в него руками. 
Но если ощ надо то можно и руками с помощью дизайнера или вообще только руками. А то что дизайнер нагенерит кучу XAMLa так это и любая другая технология гуя кде то там нагенерит, вот только добратся руками до неё и чегото изменить бывает (не знаю как у Д) проблемма.   

Это сообщение отредактировал(а) SKrivosein - 21.4.2013, 13:39

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



Скажем так, очень многие программы от MS сильно лагают при переключениях окон, т. е. что-то не в порядке с отрисовкой. Когда Багланд ударилась в .NET во всех смыслах и начала клепать новую IDE ЕМНИП называлась она Galileo, то они тоже заюзали .NET для нее, итог те же самые лаги, что и у MS. Сейчас про .NET абракадабра не вспоминает, C#-builder мертв, Delphi for .NET мертва, Delphi Prism фактически сторонний продукт от технологического партнера, но и с IDE никаких проблем, вся дурь испарилась. Вопрос, если сама MS не может или не хочет решать проблему отзывчивости своего ПО на основе .NET годами, то можно ли доверять MS и .NET?



Меня товарищь давно уже агитирует за C#, вот с ним обсуждали это (немного отцензурено):


 Beltar (22:53:26 20/04/2013)
http://megadarja.blogspot.cz/2010/04/mvvm-wpf.html

Это и есть WPF way to do?

 A (23:31:23 20/04/2013)
Есть нюансы, но в целом да.
Нюансы:
1) Некоторые (в том числе я) предпочитают не MVVM Toolkit, Prism и прочие MVVM-либы, а собственные велосипеды. Есть поверье, что каждый программист WPF должен в своей жизни написать MVVM-либу. ) В частности, с моей ViewModelBase запись для PropertyChanged в однсу строку и для get, и для set. Ну и последние фишки решарпера поддерживаются.
2) DelegateCommand -- это в целом нормальное решение (хотя есть некоторые неоптимальные места, если проверки на доступность команды тяжеловесные), только я не понимаю, что все так носятся с ленивым созданием. ИМХО, один раз в конструкторе прописал -- и больше не вспоминаешь, меньше кода, потери памяти на команду смешные.

 Beltar (23:32:34 20/04/2013)
Курево же.

 A (23:33:04 20/04/2013)
Обоснуй.

 Beltar (23:34:52 20/04/2013)
Ну начать можно со вступления в статье. Можно понять, что юзать это без бумажки уже весьма проблемно.
Ну и я не увидел там ничего, что не реализовывалось 1 методом диспетчером.

 A (23:46:31 20/04/2013)
Думаю, тебе надо найти нормальную статью, которая объясняет, что такое MVVM (вариация на тему MVC), и нафига он сдался.
Традиционный подход к программированию UI (т.н. "дельфовый" подход; дельфи в быстрой разработке UI -- первопроходец) -- это нарисовать форму, в конструкторе формы загрузить данные, распихать их по контролам, к котролам добавить обработчики событий типа Button1OnClick, в них ровным слоем размазать логику обработки данных и логику обновления состояния контролов. Это офигительно быстро и удобно, однако при определённом пороге сложности оказывается, что вносить изменения в такой код очень проблематично, потому что в одном классе оказалась мешанина из всего, что только можно -- очень высокая связность. Задача паттернов семейства MVC -- это разделить логику: вот здесь данные и их преобразование (model, модель), вот здесь контролы (view, отображение, вьюха), вот здесь логика получения и отправки моделей, вызов их методов (controller, контроллер).

 A (23:46:33 20/04/2013)
В MVVM роль контроллера заменяет толстая обёртка над моделью -- view-model. К ней через байндинги приклеивается вьюха и сама разбирается, что и как отображать, про вьюху никто ничего не знает, она сама по себе. Результат: всё разложено по полочкам, код легко поддерживать.
Если ну очень хочется писать в стиле Button1OnClick, то это не труЪ, конечно, но вполне возможно -- WPF палок в колёса не вставляет, можно писать и традиционным способом.

 Beltar (23:48:10 20/04/2013)
>в них ровным слоем размазать логику обработки данных и логику обновления состояния контролов

Так никто не делает, если свяни не один к одному, пишется метод-диспетчер, который и будет работать с данной и обновлять интерфейс.

 A (23:49:30 20/04/2013)
Насчёт "никто так не делает" я бы поспорил, я на всех фреймворках всех языков встречал такую лапшу. )

 A (23:50:49 20/04/2013)
Для аналогичной формы в дельфи этот "метод-диспетчер" примерно какой код будет содержать?

 Beltar (23:53:39 20/04/2013)
Когда ты сам писал в плюсах то, что в православных языках вроде Паскаля или шарпа является ересью, тебе было <Censored>, потому что тебе так было удобно и быстрее. Теперь метод, который в принципе работает в 90% случаев, т. к. связь обычно очень проста и не надо в куче мест что-то проверять и границы применимости которого понятны, стал вдруг лапшой.

procedure Dispetcher;
begin
UpdateData(ValueId:Integer);//например.
UpdateInterface;
end;

 Beltar (23:58:38 20/04/2013)
Если совсем правильно, то надо ф-ию для работы собственно с данными и обертку для обработки ошибок, но таким я действительно, обычно не заморачиваюсь, т. к. число букофф начинает превышать разумное в то же время метод работает в пределах конкретной программы и выгода от полного разнесения работы с данными и UI не столь очевидна.

 Beltar (23:59:57 20/04/2013)
Собственно сама VCL во многом и состоит из оберток вроде ShowMessage над трудными в использовании функциями API с дюжиной параметров.

 A (00:05:49 21/04/2013)
Прошу уяснить несколько вещей:
1. Когда я был школьником, мой код был ###м. И вообще, любой код пятилетней-десятилетней давности обычно вызывает грусть, потому что ты изучаешь много нового, и понимаешь, что можно сделать гораздо лучше.
2. Когда я был школьником, я писал очень простые программы. Когда писал сложные, их поддерживаемость была нулевой (включишь повротник -- отвалится выхлопная труба). Мой код на похапэ несколько раз захлёбывался от сложности из-за недостатков архитектуры.
3. Как я писал код, на каком языке, в какой среде, с какими библиотеками будучи школьником -- никакого отношения к делу не имеет.
4. Простой подход без разделения на слои прекрасно работает, но у него есть чёткие границы применимости (как и у чистого процедурного кода есть границы применимости, например). Пока ты находишься в этих границах -- можно не мудрить, так как это будет овердизайном.
5. WPF не ограничивает тебя в выборе архитектуры. MVVM это популярный подход, но есть как более простые (Button1OnClick), так и более сложные (Prism).

<...Skip...>

 A (00:13:52 21/04/2013)
А вот теперь смотри. Когда ты в WPF делаешь байндинг к данным, то вьюха обновляется сама. Добавил элемент в список в модели -- в контроле списка добавился только он. Обновил свойство модели -- перерисовался ровно один элемент списка, причём только та область, в которой выводится обновлённое свойство. Надо отсортировать данные -- вьюха сама сделает сортирующую обёртку над твоим списком, даже не трогая твою модель. Для всего этого тебе нужно всего лишь прописать байндинги. И больше голова не болит, не нужно обрабатывать десятки разных типов изменений.

 Beltar (00:24:44 21/04/2013)
Понимаешь, проблеме этой 100 лет в обед, сравнить ее можно с неструктурированным программированием времен фортранового периода, тогда тоже никто не знал, как надо правильно кодить, в итоге пришли к функциональной декомпозиции. Методы решения в принципе известны, и программист быстро понимает, когда можно писать под кнопкой, а когда нельзя. Сказать, что решение проблемы тривиальное нельзя, что собственно и демонстрирует пример по ссылке, описание столь простого случая потребовало уйму работы. Нам же выдают данный подход, как некую панацею, хотя настраивать связи ты будешь долго и выигрыш по сравнение с закидывание дескрипторов данных в UI прямо в коде может оказаться вообще минимальным, если будет.
И это меня почему-то удивляет.


Потом он мне кинул линк на Prism, часть I. Одной прокрутки страницы и оценки размера уже было достаточно чтобы понять, что народ будет забивать болт. Потому что, есть предел сложности в использовании.

Добавлено через 7 минут и 32 секунды
Линк я уже позавчера кидал, но оно стоит того, чтобы повторить: http://local.joelonsoftware.com/wiki/Не_да...ры_вас_запугать

Прекрасно, что мы теперь можем использовать XML для формата данных в сети. Вот это да. Но мне это примерно так же интересно, как и то, что мой супермаркет использует грузовики, чтобы привозить товары со склада. Зевок. Это интересно. Скажите мне что-нибудь новое, чего я не мог делать раньше, о, Астронавты, или оставайтесь там, в космосе и не тратьте больше моё время.

Насчет X(A)ML можно вспомнить особо, ну действительно ведь до фени, как там в WPF записываются данные, однако любая статья по WPF полна текстов на XAML, заставляет задуматься, то ли с головой у авторов не в порядке, то ли это действительно важно, в эту мешанину букв нужно лезть в каждодневной работе, и мне решительно непонятно, чем это лучше работы с кодом.

Джависты не сидят на свинге.


На джаве вообще гуевые приложения мало кто пишет.


Interface Builder в NeXTSTEP появился раньше делфей например.

Beltar ну что я должен думать о приведённой тобой переписке? Человек тебе пытается обьяснить что с помощью WPF можно писать наподобии как на Delphi, писать по другому и о чудо ещё по другому. А ты ему отвечаешь, нет надо писать ТАК как мы. Так удобно и хорошо.
Тебе сказали что десктоп в .NET можно сделать с WinForms, WPF, Silverlight (с развертыванием с веба или без)
Ты нет, хорошо и удобно делать ТАК как мы.
Сказали что веб можно делать с ASP.NET WebForms, ASP.NET MVC и опять же с Silverlight. Ты нет, это мы толком не умеем, веб ваще гов...., да нам и ненадо. Надо делать ТАК как мы. Это хорошо и удобно.
Тебе сказали что в .NET  появился функциональный язык. Понеслась аргументация что это вообще ерунда. И надо делать ТАК как мы, это просто, хорошо...
А речи о том что XAML страшный и окна в VS какие то не такие, ну просто смешны. И сылки на демогогические выплоды великого гуру, не астронавта и просто хорошего человека тоже.   
Короче чего нового вам не напиши, всюду жо.. Покажите ка вы чего нибуть нового и необычного. Я за вас порадуюсь.   
P.S. я кстати пытался поговорить о вазможности создания мобильных приложений, не разказали что это не надо и вообще игрушки   

Это сообщение отредактировал(а) SKrivosein - 21.4.2013, 17:15

В том-то и дело, что опять с ног на голову поставили. Я что ли запрещаю кому-то писать так, как позволяют их инструменты? Со стороны же антидельфистов идут постоянные вопли, что в Delphi пишут только 100500 строк под кнопками. Ну кто-то пишет, опять же WPF никак не запрещает писать точно так же. А нормальный дельфин продумает архитектуру и код под кнопками будет однострочный. Ну есть в WPF инструмент, который данную проблему, типа решает. Серебрянная пуля не меньше! А Delphi УГ и зомби! Хотя как он там решает эту проблему еще вопрос, а в самих дельфях тоже появилось связывание, всех возможностей не скажу, по виденным простым примерам полезность оценить сложно. От того, что можно настроить связь и будет при изменении одного контрола изменяться другой это круто, но весьма туманно в практическом плане. В общем товарищ уговорил меня написать реализацию подобного примера в Delphi через отдельного диспертчера. Отличие, сделано со стандартным ListView, плюс я добавил книгам Id. Тут у меня действительно уже есть практический интерес, как связать столбец ListView с полем данных в каком-то левом классе, это может быть полезно, особенно если столбцы в программе могут быть перемешаны (хотя в реальных случаях с БД, грид и так эту задачу решал уже 18 лет назад).

Сырец в XE3.
https://github.com/BeltarTheLion/DataModel/...ata%20Model.rar

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

Если хотите, сделайте то же самое в WPF, сравним снижение трудоемкости, если таковое есть. Наверное, стоит покопаться и в возможностях XE3, можно ли заюзать Live bindings и сэкономить на этом.

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

Сырцы в рар-архиве на гитхабе? Нет пути.

Тебе проще было бы скачать десяток файлов проекта? Мне же ничего там синхронизировать не надо.
В общем случай тяжелый...

git clone кто-то отменил? И мне бы было проще просмотреть сорцы прям там, не скачивая их себе.

Добавлено через 58 секунд

Согласен, делфизм — это тяжелый случай.

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

Добавлено @ 20:26
Есть предложение. Нарисовать относительно полноценное (библиотечной кодировкой и т. п. заморачиваться не будем, вряд ли библиотековедение кто-то знает) небольшое приложение для работы в библиотеке под MS SQL Server. С базой читателей, кто какие книги брал и т. п. Могу сделать на Delphi старинным способом, кто-то займется аналогом на WPF. UI можно согласовать. Проектирование БД могу взять на себя.

Это сообщение отредактировал(а) Beltar - 21.4.2013, 20:29

Vendor-lock не нужен. Тем более не работает в OSX.

Я предлагаю то, что у меня имеется в наличии (MS SQL 2008R2, Access 2003, IB 2007)
Ваше предложение?
Хотя есть у меня чувство, что все сошлются на занятость.