none
WinForms, WPF - Мнения RRS feed

  • Общие обсуждения

  • Данной обсуждения является отдельной веткой, которая родилась в процессе спора в данной теме.

    Algol36 уверен у вас огромный опыт работы с WinForms, но "ориентирован на приложения определенной направленности" я с вами ну никак не соглашусь. В WPF можно создать любое приложение которое можно создать в WinForms (утверждаю это потому что сам с нее начинал). А что до сложности, то тут и подавно. Сложно переучиваться с одного на другое и это актуально для всего, а не только для платформ программирования. Если же учить сразу WPF, то ничего сложного нет (хотя я достаточно легко переучился с одной платформ на другую).

    Ну и давайте просто вспомним мнение сотрудников Microsoft по этому вопросу. Цитата: "Если у вас уже есть полноценный проект на WinForms, то конечно же не стоит сломя голову переделывать его на WPF. В случае если вы начинаете новый проект и открыты для новых знаний то мы настоятельно советуем вам переход на WPF"

    И последний гвоздь. Когда вы соберетесь писать приложение под Windows8 в стиле Metro, то поймете, что это особо преднастроеннй проект WPF, с конкретной моделью, но с той же мощью и философией. А вот WinForms туда никаким боком не вставить.


    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!


    Отвечающий

Все ответы

  • Algol36 ваш код для меня немного сложен, мне нужно нарисовать с помощью GDI+ копию picturebox, а не косую прямую или же круг, с помощью пустого внутри квадрата я могу как то это сделать, но есть ли способ нарисовать квадрат не пустой, а заполненный точками, чтобы весь был к примеру чёрным?

    На счёт WPF я думаю изучить полностью Win, а потом перейти к нему.


    Бог движок на котором мы написаны, а Библия компилятор, и верующие постоянно компилируют себя в нём.


  • 
    

    LXGDARK, я не сомневался, что вы откликнитесь, потроллил я вас немного :)

    Если кратко, мои аргументы сводятся к следующему:

    1)Основные претензии к XAML. Он громоздок, избыточен, переусложнен и в нем не поддерживается IntelliSense.

    2)Какова основная идея WPF? Это отделение работы дизайнера от работы разработчика. Даже если оставить в покое реальную выполнимость этой идеи, то можно сказать что это необходимо только для определенного типа приложений с развитым дизайном. Грубо говоря, если вы делаете "свистелки-перделки" (в данном случае этот термин аж никак не унижает достоинства и нужность этих приложений, просто он точно говорит о том, какие приложения имеются ввиду), то WPF - для вас. Я понимаю, что сейчас это актуально и круто. Но, вы не поверите, есть куча софта которое решает технические и научные задачи, которое считает статистику, проектирует мосты, управляет девайсами, считает бухгалтерию наконец. И WPF нам ну мягко говоря не нужен. Вот я прямо сейчас разрабатываю систему для программирования медицинских приборов. Ну зачем мне здесь WPF? Кроме усложений, связанных с повсеместным байдингом, мне оно здесь ничего не даст.

    3) Ну а что касается "Ну и давайте просто вспомним мнение сотрудников Microsoft по этому вопросу" то можно вспоминать очень много громогласных заявлений о порабощении галактики с помощью COM, потом ActiveX, потом .NET, потом Silverlight/WPF, и наконец с помощью HTML5. Знаете, в это все верится только в первые 10 лет работы в этой сфере, а потом как то уже нет :)

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

    
    
    
    Все выше перечисленное сугубое ИМХО с целью развести холивар и толстый троллинг :)
    Отвечающий
  • А да, и насчет Win8, вот прямо сейчас на codeproject висит опрос "Do you plan on writing Windows 8 Metro style apps?". Так вот, 50% программистов даже не собираются писать под Win8, так что "последний гвоздь" как то мимо.

    
    Отвечающий
  • Algol36 а про меня забыли? нужно создать копию picturebox с помощью GDI+ или это не возможно и придётся делать это через пустой прямоугольник?

    Бог движок на котором мы написаны, а Библия компилятор, и верующие постоянно компилируют себя в нём.

  • Doctor Gordon, да что вы, конечно не забыли.

    Хотите рисовать графику? Забудьте про PictureBox.

    Я же вам привел пример рисования, разве там есть PictureBox?

    
    Отвечающий
  • Я думаю наш спор с Algol36 не противоречит первоначальному вопросу ведь по моему мнению переход на WPF избавит Doctor Gordon от большого количества PictureBox.

    Algol36 я вас понимаю, но имею маленькое преимущество - на WinForms я в свое время писал так же много как сейчас на WPF, а по вашим же словам в сделали всего один проект на WPF. Сначала мои аргументы относительно Doctor Gordon и его вопросов. Данный форумчанин в данном случае разрабатывает игру, а игра должна быть и интересной и ПРИВЛЕКАТЕЛЬНОЙ, а значит куда лучше подходит система для свистелок-пирделок. Doctor Gordon поверьте мне - откажись вы сейчас от идеи "сначала освою WinForm", скачайте в сети книгу WPF в .NET 4 с примерами на C# для профессионалов 2010" Мэтью МакДональда и вы закончите эту игру раньше чем если продолжите писать ее на WinForms, но она будет эстетичной и привлекательной, а то что у вас сейчас я в такие школе на Windows 3.11 играл. И к стати игра даже рисуй вы на низком уровне с помощью GDI+ будет в определенный момент так же тормозить, так как я уже писал выше WinForms совершенно не умеет использовать мощи современных видеокарт.

    Algol36 теперь отвечу на ваши остальные контраргументы. Не сочтите за грубость, но вы видимо просто не смогли до конца понять как работать с XAML. А IntelliSense в нем есть, только вот может у вас VS2008 и тогда вы имеете сырой WPF, так как в VS2010 XAML приятен и отзывчив. Да ввод XAML понадобился в том числе и для разделения труда, но уверяю вас я работаю один, и никакого дизайнера у меня нет, а и Блендом я толком не пользуюсь, но что дает XAML конкретно мне? Да то что я имею полный контроль в компоновке окна. Я могу с легкостью сделать окно которое будет одинаково эстетичным на нетбуке с маленьким экраном и на мониторе с пол стены размером.

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

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


    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!


    Отвечающий
  • Doctor Gordon, да что вы, конечно не забыли.

    Хотите рисовать графику? Забудьте про PictureBox.

    Я же вам привел пример рисования, разве там есть PictureBox?

    
    Извините, но я почти ничего не понял в вашем коде, там страшные слова для меня, окажете услугу если покажете как нарисовать только квадратик размером (10, 10) на поле.

    Бог движок на котором мы написаны, а Библия компилятор, и верующие постоянно компилируют себя в нём.

  • LXGDARK,

    >Данный форумчанин в данном случае разрабатывает игру, а игра должна быть и интересной и ПРИВЛЕКАТЕЛЬНОЙ, а значит куда лучше подходит система для свистелок-пирделок.

    Да яж не против. Для арканоиодв WPF вполне себе подходит. Но только два момента. Во-первых, чел пишет програмку для себя, и пишет то что ему интересно, игрушку. Но когда он пойдет работать он будет писать гораздо менее интересные и более прозаичные вещи. С другой стороны, если он пойдет в геймдев(полноформатный), то ему не нужен будет ни WPF, ни даже XNA, да и C# тоже ему не нужен. Поскольку серьезные игры пишутся на DirectX и C++.

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

    

    >Не сочтите за грубость, но вы видимо просто не смогли до конца понять как работать с XAML

    Та шо вы, шо вы, не стоит извиняться :)  Ну конечно не смог. Как же можно разобраться в куче тегов в string-style? Ну не нравится мне XAML, не люблю я нетипизированные языки. Можете считать это субъективным фактором, но таких я как я - не мало.

    >можете написать на WPF все, что можно написать на WinForms

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

    >приходится делать какие то не стандартные контролы и знаю какое мучения сделать это на WinForm даже с большим оптом.

    Напомнило анекдот "-Вас часто мучают эротические сны? -Ну почему же мачают?". Не вижу я никаких мучений делать контролы под winForms, наоброт очень даже просто. Береш graphics и рисуешь все что душа пожелает. Не вижу ничего сложного.

    >Пилит взрослый дяденька...

    Не, не убедило :) Непонятно, зачем вы выделили это болдом эту софистику :)

    В целом, вы так и не ответили на основные моменты, которые я приводил. Придется ответить на них самому.

    Конечно, WinForms давно устарел, и конечно на смену ему должно что-то придти. И в целом WPF движется в правильном направлении (например использование DirectX и самое главное - произвольная компоновка контролов). Вопрос не в том, что реализовывает WPF, а в том, как он это делает. А вот как он это делает мне и не нравится. Это ugly XAML, и это байндинг (хотя я конечно понимаю, почему он им понадобился, DirectX - декларативная система, и императивный стиль winForms не подходил для него, пришлось делать байндинг).

    Другой момент - вы уверены, что WPF просуществует долго? Вы разве не видите, что сейчас активно продвигается HTML5? Несмотря на то, что сулхи о смерти WPF сильно преувеличены, но все же в каждой шутке есть доля правды, и неприятный осадок остался :)

    Ладно, давайте заканчивать междусобойчик, тем более народ особо не интересуется видимо:) Кроме топикстратера, но у него сейчас совершенно другие проблемы :)

    Отвечающий
  • >Ладно, давайте заканчивать междусобойчик, тем более народ особо не интересуется видимо:) Кроме топикстратера, но у него сейчас совершенно другие проблемы :)

    А может продолжите? Интересно всё таки почитать вас :) Сам сейчас изучаю WPF, раньше немного ковырял WinForms, так что тоже находился в раздумьях, стоит ли гнаться за чем то новым.

    >то ему не нужен будет ни WPF, ни даже XNA, да и C# тоже ему не нужен

    XNA ж весьма неплохой движок, если не ошибаюсь - Flight Simulator на его основе написан. Что в нем плохого?


    DreamSpark Premium User

  • Algol36 я вообще не люблю никого ни в чем убеждать и всегда стараюсь дать объективную информацию что бы человек смог выбрать, но признаю тут меня задело. Если бы автор тем сказал мне "Нет меня интересуют только WinForms", то я бы забыл вести речь про WPF (как и произошло попозже) но я видел что изначально человек сомневался и не знал всего. Я дал ему информацию и предложил выбрать, но вы сказали "Зачем изучать новое когда и старое не плохо работает" и все последующие мои посты были попыткой сказать "Что как бы хорошо не ездила лошадь машина ездит быстрее и удобнее во всех отношениях".

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

    > Другой момент - вы уверены, что WPF просуществует долго? Вы разве не видите, что сейчас активно продвигается HTML5? Несмотря на то, что сулхи о смерти WPF сильно преувеличены, но все же в каждой шутке есть доля правды, и неприятный осадок остался :)

    Вы VS2011 в глаза то хоть видели? А Windows8 metro-style? Внимание на HTML5 было направлено исключительно для привлечения новых разработчиков на рынок Windows, то есть теперь приложения для метро могут разрабатывать те кто пишет на C++, знаком с Silverlight/WPF и HTML5 имея при этом равные возможности.

    WPF и его идея (в частности XAML) проживет еще очень долго, а вот WinForms уже на грани вымирания как в свое время MSDOS и QBasic. Согласен на ваш век хватит работы в WinForms, а вот стоит ли тратить время зря новичкам?


    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!

    Отвечающий
  • Black-millenium

    >XNA ж весьма неплохой движок, если не ошибаюсь - Flight Simulator на его основе написан. Что в нем плохого?

    Плохо то, что он не выжимает из видеокарты все 100% производительности. А в играх это критично.

    LXGDARK,

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

    Вот вы например, уже и в старперы меня записали, и winForms на мой век хватит (видимо мне не долго осталось :), и в WPF я не разобрался. Ну я ж не обижаюсь :)

    При этом вы даже не вчитываетесь в мои посты, вы ни слова не скзали о том, что XAML просто неудобен. Хотя я вам уже третий пост про это пишу. Вы наверно уверены, что я просто упертый старикашка, который не хочет ничего нового? Ну да, клевый образ, мне даже нравится, пусть будет так :) Хотя на самом деле, я просто объективно смотрю на вещи. У меня в год случается десяток проектов (может даже и больше, если учитывать те что пишу просто так, для себя). И за послений год - ни в одном не было WPF! Его просто заказчики не заказывали. Хотя был и Си и Java под андроид, и даже Compact FW был. А WPF не было. Может я не в той вселенной живу? 

    
    
    
    Отвечающий
  • У вас одни эмоции, хотя я вам с самого начала сказал, что немного троллю вас...

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

    ...Может я не в той вселенной живу?

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

    Я игнорировал наезд на XAML потому что мне он удобен и понятен и хотя его можно просто свернуть и по прежнему кидать элемент из тулбара прямо в окно, я же пишу XAML руками, мне это удобно и удобно всем кто разобрался с WPF. Вы же тот факт, что вам не удобно выдаете за недостаток. Вы говорите человеку что XAML и binding не удобны, но при этом не говорите что проект можно написать не разу не воспользовавшись ни тем ни тем и это будет внешне и внутренне точно такой же проект как написанный на WinForms но с плюсами движка WPF. Возможно вы изучали WPF с разу с паттерна MVVM (а он на самом деле сложен и не все его используют).

    Мы все живем в своих вселенных, но сильно сомневаюсь что ваши заказчики требуют проект именно на WinForms. Они просто описывают задачу, а вы основываясь на своем опыте выбираете как ее проще сделать. Кто то будет делать те же самые проекты на WPF, а заказчик же получит результат не сильно вникая что там за кулисами и даже не заметит разницы.


    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!

    Отвечающий
  • Black-millenium

    >XNA ж весьма неплохой движок, если не ошибаюсь - Flight Simulator на его основе написан. Что в нем плохого?

    Плохо то, что он не выжимает из видеокарты все 100% производительности. А в играх это критично.


    Хм, то есть по-вашему простенький трёхмерный арканоид должен грузить видеокарту так же, как и Crysis? Или я не совсем правильно понимаю термин "100% производительности"?

    DreamSpark Premium User

  • LXGDARK,

    >вводите в заблуждение новичков

    Чем же я их ввожу в заблуждение? Ок, я умолкаю :)

    
    

    >но сильно сомневаюсь что ваши заказчики требуют проект именно на WinForms. Они просто описывают задачу, а вы основываясь на своем опыте выбираете как ее проще сделать

    Мои заказчики это в основном программистские фирмы, а не конечные потребители, так что они прекрасно знают что им нужно. Да достаточно просто зайти на hh.ru или на какой-нить job.ru и сравнить число вакансий C# и в скольких из них требуется WPF. Сегодня вот специально зашел и посмотрел. Из первых 10 вакансий C# ни в одной нет требования WPF. Вот пусть новички и думают.

    В целом, я ождал от вас услышать хоть какие-то аргументы в поддержку XAML. Я даже хочу, что бы вы меня убедили что XAML прекрасный, лаконичный и стройный язык. Но ничего кроме отлупов типа "вам не удобно, но это не недостаток" не услышал. Или другой перл "вы можете писать на WPF точно так же как и под WinForms, без байндинга, без MVVM, ибо оно сложно". Ну да, могу. Только стоит ли ради этого использовать WPF? Все примеры, все видеоуроки, все в WPF крутится вокруг байндинга и MVVM. И тут вы вдруг предлагаете это не использовать?

    Ладно, меня уже немного утомил этот диалог:) Я привык беседовать на более предметные темы, там где можно доказать свою правоту. Здесь же мы имеем религиозный холивар. Затем, разрешите откланяться :)

    Отвечающий
  • Хм, то есть по-вашему простенький трёхмерный арканоид должен грузить видеокарту так же, как и Crysis? Или я не совсем правильно понимаю термин "100% производительности"?"

    Эммм, я тож не очень понял о чем вы. Я имел ввиду что XNA не обеспечивает максимальную производительность видеокарты. Арканоид конечно можно(и нужно) писать на XNA, а Crysis - нельзя.
    Отвечающий
  • А у вас нет доводов, что бы что то доказать. Все ваши доводы основаны на 3% знаний о WPF и 1% практики работы с ним. Я же как писал выше одинаково много писал и на той и на той платформе. Что же до работодателей - да они не требуют WPF, только во время работ они затребуют от вас решения таких задач которые в WinForms в не решите. Благо когда это произошло со мной я уже изрядно по привык WPF, которй начал изучать для себя. Вот пусть новички и думают.

    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!


    Отвечающий
  • Хм, то есть по-вашему простенький трёхмерный арканоид должен грузить видеокарту так же, как и Crysis? Или я не совсем правильно понимаю термин "100% производительности"?"

    Эммм, я тож не очень понял о чем вы. Я имел ввиду что XNA не обеспечивает максимальную производительность видеокарты. Арканоид конечно можно(и нужно) писать на XNA, а Crysis - нельзя.
    А вообще XNA не только игровая платформа. Насколько мне известно, он позиционируется просто как графическая платформа(?).

    DreamSpark Premium User

  • А у вас нет доводов, что бы что то доказать. Все ваши доводы основаны на 3% знаний о WPF и 1% практики работы с ним. Я же как писал выше одинаково много писал и на той и на той платформе. Что же до работодателей - да они не требуют WPF, только во время работ они затребуют от вас решения таких задач которые в WinForms в не решите. Благо когда это произошло со мной я уже изрядно по привык WPF, которй начал изучать для себя. Вот пусть новички и думают.

    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!


    Кстати когда я только наяинал изучать WPF (примерную дату можно найти по моим первым темам, касательно WPF :D ), то в общем то не увидел сколь нибудь сильных отличий от WinForms. Пока не потребовалась привязка к данным и прочая XAML'овская специфика. А на мой взгляд преимущество WPF в том, что оно более рационально использует возможности современных пека, отрисовывая окошки видеокартой.

    DreamSpark Premium User

  • Ой! Люблю холивары! Можно я, можно я?

    Algol36, давайте сделаем так. Есть база данных, в ней таблица, она расширена еще 3 таблицами. Например: Мебель (Артикул, название, тип) и таблицы расширения Мягкая мебель (тип каркаса, материал обивки), Кухонный гарнитур (Тип стульев, размер стола), Встраиваемый шкаф (материал дверей, размер ДхВхШ, количество полок).

    Вы пишите 1 WinForm-у в которой в 1 списке показываются все объекты этих типов. Причем для каждого объекта я должен видеть только их поля, я могу прямо в этом гриде выбрать любой объект и отредактировать. Я решаю ту же задачу на WPF. Засекаем время решения (по честному, я вам, как джентльмен-джентльмену верю). Потом выкладываем эти формы для обсуждения, какая удобнее. Затем посмотрим на сколько отличие будет в занимаемой памяти на 5000 записей, потом поскролим этот список в WinForm и WPF. Ну а после этого на одного WPF программиста станет больше :P

    Отвечающий
  • О, холивор вынесли в отдельную тему :)

    Algol36, через меня (как менеджера/тимлида) прошла пачка проектов и на WinForms, и на WPF. Так вот, по моему опыту, байндинг и почти принудительный MVVM - это не недостаток, а наоборот, основное преимущество. Потому что натягиванием шкурки на приложение должен заниматься дизайнер. А WFP дает дизайнеру почти полную свободу действий + язык разметки (а не императивный C#).

    А для разработчика, при клепании приложений с несложным UI их каких-нибудь devexpress - да, XAML не нужен.

  • Ой! Люблю холивары! Можно я, можно я?

    Да конечно можно :) Правда я немного поостыл, да и не такой уж я ярый противник WPF, как вам кажется.

    Есть база данных, в ней таблица, она расширена еще 3 таблицами....

    Во-первых, если вы читали мои посты, то вы бы видели, что я не против того ЧТО делает WPF, а у меня есть претензии к том КАК оно это делает. Мне не нравится XAML и мне не нравится принудительный байдинг. Во-вторых, ясен пень, что в WPF вложенные контролы делать легче чем в WinForms. Разве я с этим спорю? Наоборот, я отношу это к преимуществам WPF.

    Есть база данных, в ней таблица, она расширена еще 3 таблицами....

    Но, тем не менее, давайте сделаем эти програмки, just to fun. Из любви к искусству. Только давайте не таблицы из БД, а просто список объектов (что бы не возится с базами данных). Напишите пож, объектную модель, три (или сколько их там) классов, и код по заполнению списка. И еще, давайте объектов не 5000 - это как-то не серьезно. А давайте 5 000 000 объектов, чисто по-взрослому что бы было :)

    И еще, давайте уберем ограничения на время. Потому что 1)я заведомо в проигрышной позиции нахожусь, ведь я знаю, что в WPF это сделается быстрее 2)а во-вторых, у меня нет желания убить день напролет на детские игры :)

    Отвечающий
  • Так вот, по моему опыту, байндинг и почти принудительный MVVM - это не недостаток, а наоборот, основное преимущество. Потому что натягиванием шкурки на приложение должен заниматься дизайнер. А WFP дает дизайнеру почти полную свободу действий + язык разметки (а не императивный C#).

    Ну вы повторяете мои слова в каком-то там посте выше. Я с вами абсолютно согласен.

    А для разработчика, при клепании приложений с несложным UI их каких-нибудь devexpress - да, XAML не нужен.
    Ну да, согласен. Я вот такой как раз "клепатель", как вы выразились :)
    Отвечающий
  • Поучаствую и я.

    В основном я согласен с Algol36.

    Не буду повторяться, напишу своё.

    Декларируемое преимущество WPF - аппаратное ускорение графики. Начну с того, что это миф. Причина проста: в современных видеокартах по сути нет ускорения двухмерной графики. Трёхмерная - да, ускоряется, и ещё как. А с двухмерной прекрасно справляется центральный процессор, поэтому видюхи обладают лишь зачатками ускорения 2D. Когда-то давно, в эпоху 8- и 16-битных игровых приставок и микрокомпьютеров, на некоторых из них действительно было ускорение двухмерной графики: спрайтовая анимация, аппаратная проверка столкновений спрайтов и т. п.

    Недавно на другом форуме видел такое обсуждение: 400 чекбоксов на форме WPF (20*20) - и всё - тормозит... Вернее, при ресайзинге формы процессор грузится по полной. Те же 400 чекбоксов в WinForms или на чистом Win API - нагрузка на проц намного меньше. Даже если в браузере сделать столько же чекбоксов - и то нагрузка на ЦП меньше! Вот вам и ускоренная графика WPF...

    Едем дальше. В любой доке по WPF и XAML прямо пишется: не увлекайтесь глубокой вложенностью элементов, не создавайте сложную иерархию, а то будет тормозить. Но постойте! В рекламных агитках говорится, что эта технология предназначена для создания Rich UI, а оказывается, как дойдёт до практики, так низзя делать богато. :(

    Рассмотрим три типа приложений: с простым GUI (хеллоуворлд), со средним по насыщенности, и со сложным. Простое неважно на чём создавать: хоть WinForms, хоть WPF - элементарное дело. Сложный GUI, в силу приведённых выше причин, на WPF будет нещадно грузить процессор. Так что, стихия WPF - средненький GUI. trollface.jpg

    Выскажусь насчёт соревнования по созданию произвольного ГУЯ. На простом нет смысла меряться, а на сложный жаль своего времени. Однако, мне приходилось делать сложный ГУЙ. На WinForms. Да, что-то было бы проблематично реализовать стандартными контролами. Однако, зная кишки WinAPI (лезем в WndProc), несложно доработать их поведение. И главное, есть мощный трюк: кидаем на форму WebBrowser и в нём рисуем всё что душе угодно на HTML+CSS. Этакий WPF для бедных :). Приходилось так делать ещё до появления WPF. Работает шустро.

    Ещё одно соображение. Темы Виндоус. Если разработчик не дурак, то не станет отключать в приложении WinForms поддержку тем ОС. И таким образом, все приложения меняют свой вид в зависимости от личных настроек пользователя. А в WPF принято создавать произвольные интерфейсы попугайских расцветок. Итог: пользователям бывает сложнее начать работать с такими непривычными приложениями. Вспомните: одно из достоинств Windows в отличие от DOS - единообразие интерфейса. В ДОСе программы сильно различались своим внешним видом и поведением, что затрудняло обучение пользователей. Всё вернулось на круги своя...

    Мне встречались слабовидящие пользователи, которые настраивали шрифты побольше, цвета поконтрастнее, и все приложения, написанные на WinAPI, MFC, VCL, WinForms вели себя как и подобает: меняли свой внешний вид согласованно с системными настройками. А приложения WPF - упс! Ну вы понели... Отрывать бы руки таким дизигнерам.

    Что там следующее? Привязка данных. В WPF с ней носятся как с писаной торбой. Потому что иначе нельзя. Но и в WinForms с байндингом всё отлично. Просто там не принято на каждый чих привязывать что-то к чему-то. Но это дело вкуса. Можно работать без привязки. Можно с ней. А если ещё приперчить реактивными расширениями (RX) - м-м-м! Вкусняшка!

    Попил водички. Продолжаю.

    XAML. О, это ещё один повод для негодования! XAML - ужасен! Вернее, чудовищен XML, а следовательно и все его производные. Громоздкий, многословный... Я понимаю причины его использования: уже наработано множество способов работы с xml, созданы парсеры, трансформеры, валидаторы, вот и используют. (А всё потому, что в Майкрософт до сих пор пишут парсеры руками).

    Но ведь есть же гораздо более лаконичные и удобные технологии описания ГУЯ. Например, JavaFX, QML. Более того, в том же C# можно в коде писать формочки! Получается намного лаконичней, и на мой взгляд, понятней. Так нет же, сунули этот жуткий XAML...

    И немой укор вышеперечисленному - формат DFM.

    Напоследок отвечу на вопрос, что изучать начинающему: WPF или WinForms? Конечно же, WPF. За этой технологией будущее (к частичному сожалению). ВинФормс умрёт. Когда-нибудь умрёт и WPF. На смену придёт что-то новое. А пока работаем с тем, что есть.

    P.S. вброс засчитан? pokerface

  • P.S. вброс засчитан? pokerface

    Я бы сказал что нет, потому что 70 % ваших утверждений не имеют под собой основы. Я мог бы опровергать их по пунктам, но это еще на 35 сообщений вниз все растянется. В основном вы приводите доводы исходя из ограниченных знаний о платформе, как это делал и Algol36 выше.

    А самое интерьерное, что в пишите "Однако, зная кишки WinAPI (лезем в WndProc), несложно доработать их поведение.", а это согласитесь уже "старшие классы" в программировании на WinForms. Так что мешает изучить WPF так же хорошо и углубленно и избавится от поверхностных проблем которые в описали выше.

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


    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!


    Отвечающий
  • LXGDARK, по поводу тормозов WPF есть что сказать?

  • "WPF in С# Метью макдональд" глава "Повышение производительности больших списков", цитата: "...это должно быть очевидным, но при заполнении списка программно - например, динамически создавая нужные объекты - никакая виртуализация не происходит, поэтому необходимо использовать привязку данных..." Я же не зря написал что зная WPF на уровне "старших классов" таких проблем нет. Я могу найти массу проблем в WinForms которые вы решите, а новичок нет и примет это за не достаток платформы.

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


    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!

    Отвечающий
  • LXGDARK, по поводу тормозов WPF есть что сказать?

    Да, есть.

    Вот пример о котором мы говорили, только сори, я редактирование не стал делать.

    Структура классов:

    Работа программы на 5 миллионах записей:

    Вот исходники: http://narod.ru/disk/48717405001.15f1e0998391cbf74108f1dd21b9ef0c/GridFor5bilItems.zip.html

    Попробуйте запустить проект, поизменять размер, поскролировать. А потом давайте поговорим о скорости WinForms приложений. Чтобы небыло недоразумений, каждый элемент списка это Grid (компонент табличной разметки),  содержащий 2 TextBlock и StackPanel (компонент для разметки оля Stack), а в StackPanel еще 2 TextBlock.

    После запуска приложение в памяти занимает 750 МБ.

    Жду вариант WinForms.

    Отвечающий
  • Декларируемое преимущество WPF - аппаратное ускорение графики. Начну с того, что это миф. Причина проста: в современных видеокартах по сути нет ускорения двухмерной графики. Трёхмерная - да, ускоряется, и ещё как. А с двухмерной прекрасно справляется центральный процессор, поэтому видюхи обладают лишь зачатками ускорения 2D. Когда-то давно, в эпоху 8- и 16-битных игровых приставок и микрокомпьютеров, на некоторых из них действительно было ускорение двухмерной графики: спрайтовая анимация, аппаратная проверка столкновений спрайтов и т. п.

    А позвольте поспорить. Была у меня видюшка GTX 275, с ней шла программка, которая позволяла отдельно регулировать параметры работы для 2D режима, а отдельно для 3D. Исходя из этого, я все таки попытаюсь сказать Вам, что Вы не правы в плане невозможности аппаратной отрисовки приложений на платформе WPF.

    И предположение: тогда что же есть Aero, требующее наличия DX 9.0? То самое аппаратное ускорение 2D (ну не похоже оно на трёхмерную графику вообще никак). Замечал, что компьютер, с отключенными компонентами рабочего стола (Server2008R2) при таскании окошек отрисовывает их гораздо медленнее, чем со включенными (и, соответственно, со включённым Aero).


    DreamSpark Premium User


  • После запуска приложение в памяти занимает 750 МБ.

    750 Мб это частный рабочий набор приложения, или вся выделенная ему память?

    DreamSpark Premium User

  • Это то, что показывалось в диспетчере задач после создания 5 миллионов записей и показа их в ListBox.

    Отвечающий
  • Мы ту все мега программисты, а порой не мешает вспомнить основы. А что собственно делает процеесор? зачем это при...штукенция нужна вообще? Грубо и поверхностно но это супербыстрый калькулятор с заложенным набором операций (чем круче проц, тем больше возможных стандартных операций). Именно поэтому бывают игровые процессор, графические процессоры, процессоры для суперкомпьютеров делающих конкретные вычисление и т.д.

    Отличие процессора видеокарты от ЦПУ в том, что в видяшном заложен именно набор операций свойственных графике, а значит видеокарта будет обрабатывать графические операции быстрее чем ЦПУ. WinForms напрочь игнорирует этот факт (старенькая уже), а WPF выживает из этого все что можно. Вот вам и миф как вы говорите.


    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!

    Отвечающий
  • Это то, что показывалось в диспетчере задач после создания 5 миллионов записей и показа их в ListBox.

    Ну, какой из этих двух столбцов? :) И кстати да, можете объяснить чем они отличаются? (на правах оффтопа, пока ждём ответного удара со стороны WinForms)


    DreamSpark Premium User

  • Хм, я могу ошибаться, но это память реально используемая приложением (первый столбец) и выделенная операционной системой для обслуживания данного процесса. Выделяется с запасом, чтобы избегать фрагментации памяти, которая может приводит к медленным загрузкам в кэш процессора и прочим гадостям.
    Отвечающий
  • Алексей, а Вы на какой машине проводили данный тест?

    Мои результаты, компилировал в конфигурации Release только под x64 системы. 4 ядра, 3,6 Ггц на ядро, 8 Гб озу. В процессе создания списка общая нагрузка на процессор не превысила 25%. Server2008R2 Standard, в свойствах компьютера переключатель в полложении "Оптимизировать работу программ".


    DreamSpark Premium User



  • Вот пример о котором мы говорили, только сори, я редактирование не стал делать.

    Структура классов:

    Жду вариант WinForms.

    Это я так понимаю, вы мне пишите? Так вы хитрец, оказывается у вас уже был рабочий вариант задания :)

    Ну ок, щас скачаю ваше произведение, и напишу похожее на winforms.

    Отвечающий
  • Жду вариант WinForms.

    WPF:

    WinForms:

    

    Исходник http://www.fayloobmennik.net/1874422

    Все, я спать :)

    Отвечающий
  • Это я так понимаю, вы мне пишите? Так вы хитрец, оказывается у вас уже был рабочий вариант задания :)

    Ну ок, щас скачаю ваше произведение, и напишу похожее на winforms.

    Нет, на момент написания вашего сообщения с просьбой пример упростить у меня не было ни одной строчки кода. Рекомендую посмотреть время создания файла решения: 22:18 вчера по Москве и время создания архива 23:14. Но мы же договорились не засекать время.

    Отвечающий
  • Исходник http://www.fayloobmennik.net/1874422

    Все, я спать :)

    Хм, вы знаете, я приятно удивлен производительностью WinForms.

    Пара комментариев:

    1. По скорости создания коллекции мериться смысла нет, я это время выводил больше для справки. У меня объекты чуть сложнее чем у вас. Например, если я программно у какого то элемента изменю значение свойства, то оно автоматически, без моего участия перерисуется в списке.

    2. По памяти, тут да. Рисование GDI+ уделывает готовые контролы.

    3. Вы уверены, что тот код который вы написали, вы сможите объяснить начинающему программисту, так чтобы он сел и с ходу повторил ваше решение? Я свой смогу, да и наобъяснял уже кучу раз.

    4. Скорость разработки - no comment.

    Но, еще раз повторюсь, скорость работы производит весьма приятное впечатление.

    Отвечающий
  • Ну давайте тогда уже до конца дело доводить. Давайте вы доделаете эти проекты до конца (как изначально предлагал Алексей) и мы тогда уже будем смотреть.

    Будем оценивать такие показатели как "Скорость", "Эстетичность", "Функциональность", "Общее впечатление".

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

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


    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!

    Отвечающий
  • 3. Вы уверены, что тот код который вы написали, вы сможите объяснить начинающему программисту, так чтобы он сел и с ходу повторил ваше решение? Я свой смогу, да и наобъяснял уже кучу раз.

    Да нафига мне объяснять это начинающему программисту? :D 

    У вас аргумент препода а не разработчика :0) Если уж объясянть то лучше вообще писать на паскале а не на C#, он как бы и предназначен для обучения.

    Кроме того, если вы смотрели мой код, то абсолютно ничего сложного там нет. Все очень прозрачно.

    

    >4. Скорость разработки - no comment.

    Я не очень понял что вы имели ввиду. Наверно то, что я это делал дольше вас? Ок. Могу сказать следующее:

    1) Я делал это с нуля, как мы и договаривались. При чем этот "ноль" не тот что у вас. Вы начали с нуля имея на борту FW3.5 и WPF, которые писало куча программистов, а я писал на чистом FW2.0. Мне даже wrapper для байндинга заново пришлось писать. (это не аргумент оправдания, я просто говорю на что у меня ушло время, а то сейчас меня все начнут убеждать, что дескать в WPF это все готовое и это хорошо и т.д.)

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

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

    Отвечающий
  • Ну давайте тогда уже до конца дело доводить. Давайте вы доделаете эти проекты до конца (как изначально предлагал Алексей) и мы тогда уже будем смотреть.

    Не, сорри :)

    Сначала я тоже немного был удивлен, что Алексей не реализовал ни красоту, которую. можно было легко сделать в WPF, ни редактирования, ни строк разной высоты, ни схлопывания и т.д. Я был готов это все повторить, но поезд ушел :)

    

    >Будем оценивать такие показатели как "Скорость", "Эстетичность", "Функциональность", "Общее впечатление".

    Ну так оценивайте то что есть)

    >Пока эти проекты не показательны - Алексей вставляет в список другие элементы "а не только текст",

    И что? Вы думаете я не смогу вставить "не только текст"? Хотите поспорить?

    Шоб вы не сомневались, приложу пару скриншотов компонента, который я делал одной немецкой конторе недавно. Там есть и схлопывание/расхлопывание, и редактирование и выпадающие редакторы и картинки и анимация и еще дофига чего.

    >а Algol36 просто переопределяет отрисовку списка, так что пока что делаются разные вещи и сравнивается результат - так не пойдет, хитрить не нужно.

    Угу, а вы хотели что бы я 5млн лейб на форму кинул? Хе -хе :D Программирование оно ваще штука хитрая. Конечный юзер увидит разницу между моим проектом и проектом Алексея? Нет. А как я это сделал - его ваще не волнует. С вашей логикой любой из моих проектов - сплошная хитрость и надувательство, ай-ай-ай, я ж вместо честного и православного листобокса нарисовал его вручную :DD Дык в этом и заключается программирование, а лейбы и школьники кидать могут.

    >И кстати Algol36 добавьте пожалуйста к вашему списку черезстрочный фон не забавы радяи, а для удобства восприятия информации.

    Я б его без труда добавил бы, но в моем варианте он не нужен. Алексей сделал зебру для того что бы строки различались между собой, но у меня они различаются и так, за счет бордеров.

    Да, и вот скриншоты:

    На скринах анимации не видно конечно, но она там есть, можете мне поверить.

    Отвечающий
  • Algol36 вы ни как не можете понять наш главный аргумент. Вот на моем примере. Я перешел на WPF почти сразу, потому на сегодняшний момент WinForms изрядно подзабыл, но если сейчас мне скажут "Нужен простенький проект без лишних красот, с лейблами и текстбоксами", то я открою проект WPF и сделаю такой проект и даже на вид нельзя будет определить платформу. Завтра ко мне приходят и говорят "нужен сложный красивый проект, с прозрачностями, анимациями и т.д." и я снова открываю WPF и делаю то что нужно. Мое преимущество в том, что не зависимо от того, что от меня требуют я постоянно оттачиваю и совершенствую знания и в любой момент готов выполнить проект по нужным требованиям.

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

    Опять же из моего опыта программа рассчитанная на узкую аудиторию сделанная в WinForms приносила дохода на 95% меньше чем та же переписанная в WPF, но с мелочами типа прозрачности и анимации. Люди в большинстве своем стремятся к блестящему, а серое и сухое удел меньшинства.

    Подытожу вышесказанное - я не призываю вас бросать WinForms и переходить на WPF, так как с вашим опытом (а он виден хотя бы из примера программы выложенной выше) откажись вы от работы над проектом А, завтра вам предложат проект Б.

    Новичок же отказавшись от проекта А проект Б уже может и не получить, поэтому он должен быть готов к решению любых задач и даже тех, которые WinForms решить не в состоянии.


    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!

    Отвечающий
  • Algol36 вы ни как не можете понять наш главный аргумент. Вот на моем примере. Я перешел на WPF почти сразу, потому на сегодняшний момент WinForms изрядно подзабыл, но если сейчас мне скажут "Нужен простенький проект без лишних красот, с лейблами и текстбоксами", то я открою проект WPF и сделаю такой проект и даже на вид нельзя будет определить платформу. Завтра ко мне приходят и говорят "нужен сложный красивый проект, с прозрачностями, анимациями и т.д." и я снова открываю WPF и делаю то что нужно. Мое преимущество в том, что не зависимо от того, что от меня требуют я постоянно оттачиваю и совершенствую знания и в любой момент готов выполнить проект по нужным требованиям.

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

    Опять же из моего опыта программа рассчитанная на узкую аудиторию сделанная в WinForms приносила дохода на 95% меньше чем та же переписанная в WPF, но с мелочами типа прозрачности и анимации. Люди в большинстве своем стремятся к блестящему, а серое и сухое удел меньшинства.

    Подытожу вышесказанное - я не призываю вас бросать WinForms и переходить на WPF, так как с вашим опытом (а он виден хотя бы из примера программы выложенной выше) откажись вы от работы над проектом А, завтра вам предложат проект Б.

    Новичок же отказавшись от проекта А проект Б уже может и не получить, поэтому он должен быть готов к решению любых задач и даже тех, которые WinForms решить не в состоянии.


    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!

    Пользователь то разницы не увидит, но на простеньких проектах WPF тормозит ощутимо сильнее :)

    DreamSpark Premium User

  • Нет, немножко не так.

    Давайте я изложу свое мнение и на этом участие в данном топике закончу.

    Algol36 - очень хороший разработчик. Он великолепно знает WinForms. Но... Как всегда, но. По характеру высказываний, он великолепный одиночка. Если ему дать задачу, не трогать, то через время N будет великолепный результат, но вот если время нужно N/4, то включить его в команду из 5-7 разработчиков и получить выигрыш по времени не получится... Algol36 (извините, другого имени не знаю), я прав в оценке характера вашей работы?

    Для меня, как руководителя команды, очень важным является процесс ротации кадров. Возникает необходимость набирать новые команды, а, к сожалению, не всегда в одну команду можно набрать технических специалистов класса Algol36. И здесь приходится подтягивать разработчиков в технологиях разработки. Как я сказал выше, на WPF это требует меньше времени, чем с подходом пропагандируемым Algol36.

    P.s. Кстати, 90% моего текущего проекта на Silverlight. Пламенный привет разработке на WinForms.

    Отвечающий
  • Пользователь то разницы не увидит, но на простеньких проектах WPF тормозит ощутимо сильнее :)


    DreamSpark Premium User

    Можно пример такого проекта?
    Отвечающий
  • Пользователь то разницы не увидит, но на простеньких проектах WPF тормозит ощутимо сильнее :)

    DreamSpark Premium User

    Откуда вы это берете? Мой первый тестовый проект на WPF был перенабором существующей маленькой WinForms утилитки просто в целях практики. Внешне разницы 0%, по поведению разницы 0%. Скорость и возможности расширения 100%.

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


    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!

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

    Так может нам всем тогда на ассемблер перейти? Если много и усердно учится, много и усердно работать, то можно такое забацать !!! лет через 20...

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


    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!

    Отвечающий
  • Да и пожалуй я тоже полностью высказался по этой теме. Теперь я подожду когда DoctorGordon начнет изучать WPF, хорошенько вникнет что к сему и скажет свое мнение.

    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!

    Отвечающий
  • LXGDARK,

    Вы мне в очередной раз приводите аргументы с которыми я согласен, и не спорю. Но вы все равно настойчиво мне их приводите.

    Вы сделали прозрачные менюшки? Отлично! Я ж вам сразу сказал, что WPF подходит для того типа(!) приложений, которые вы делаете. Зачем вы мне опять про это говорите? Если бы я делал ваши приложения, я бы тоже наверно пользовался WPF. Но поймите, есть масса приложений совершенно другого типа.

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

    Или например, вы думете, что если адоб перепишет на WPF свой фотошоп, то его продажи возрастут на 95%? Ну это ж смешно.

    В общем я немного устал отбиваться от аргументов, с которыми я согласен. Конечно WPF хорошо для группировки контролов. Это отлично. DirecrtX - прекрасно. У меня лишь недовольство к тому, КАК это реализовано. Я вам уже не раз говорил про неудобство и громоздкость XAML, и про повсеместный байндинг. Вот это мне не нравится. А вы мне в очередной раз про прозрачные менюшки.

    >Так может нам всем тогда на ассемблер перейти

    Зачем же всем? У каждой технологии своя ниша. Если мне нужно будет что-то на ассемблере - я напишу и на ассемблере. Вот этим летом предвидится проект по программированию контроллеров. В лучшем случае - на Си. В худшем - даже боюсь представить. Во всяком случае мне уже посоветовали прикупить паяльник :DD

    

    >лет через 20...

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

    Отвечающий
  • Algol36 - очень хороший разработчик. Он великолепно знает WinForms. Но... Как всегда, но. По характеру высказываний, он великолепный одиночка. Если ему дать задачу, не трогать, то через время N будет великолепный результат, но вот если время нужно N/4, то включить его в команду из 5-7 разработчиков и получить выигрыш по времени не получится... Algol36 (извините, другого имени не знаю), я прав в оценке характера вашей работы?

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

    В целом, вы затригиваете уже философскую тему. Сейчас в IT происходит примерно тоже что происходило в 19-20 веках с автомобилестроением. Сначала машины делали вручную, каждая была произведением искусства. Потом пришел Форд и пошло - унификация, стандратнизация и конвеер. Мастера которые могли собрать машину целиком уступили место более низкоквалифицированному персоналу, каждый из которых умел делать только что то одно.

    Сейчас просиходит то же самое в IT. Уровень специалистов падает, число ПО - растет. Ну а качество.. гм.. не знаю, трудно сказать. Проблема(для меня) еще в том, что мало кому нужен качественный софт. Вот скринсейвер с котэ - это да, это нужно. Его поставят на неделю, потом снесут, и все довольны и потребители и производители. Есть конечно более серьезный сегмент, которму нужно качественое ПО. Но это все тонет в потоке попсы.

    Но это все конечно не касается WPF, это так, общая тенденция... А что же до WPF, то конечно от него никуда не дется. В нашей отрасли нельзя выпадать из мейнстрима. А если майкрософт решило(?) сделать WPF мейнстримом, то никуда не дется. Разве что свалить в джаву или HTML5 :)

    Отвечающий
  • Пользователь то разницы не увидит, но на простеньких проектах WPF тормозит ощутимо сильнее :)


    DreamSpark Premium User

    Можно пример такого проекта?

    Угу. Вот меня попросили сделать программку, сделал её на WPF. Тормозит довольно сильно. Сейчас переписываю её на WinForms, ка закончу - выложе для сравнения, но из того что уже сделано - WinForms вроде как быстрее.

    Ссылка.

    Сильно не пинайте, только учусь :) Возможно, под WinForms код будет более приличным.


    DreamSpark Premium User


  • [offtopic]Black-millenium, переходите на bitbucket/codeplex/github. SkyDrive для исходников - не комильфо.[/offtopic]


  • [offtopic]Black-millenium, переходите на bitbucket/codeplex/github. SkyDrive для исходников - не комильфо.[/offtopic]



    Да это исходниками стыдно назвать (>_<)

    DreamSpark Premium User

  • Всё таки я передумал переписывать проект на Windows Forms. Не нравится мне, как там реализована работа с элементами контекстного меню. На WPF через XAML меню создаётся гораздо удобнее.

    DreamSpark Premium User

  • Пишу всем сразу.

    Фанаты WPF, похоже, пропускают мимо ушей главное, что говорит Algol36 и я: за WPF будущее. Эта технология перспективная, и конечно же именно её следует изучать. Именно на WPF происходит постепенная миграция разработки.

    Однако у этой технологии есть недостатки, на которые мы и указываем. Это объективные факты!

    Но фанатизм застилает глаза, и доводы разума не слышны...

    Повторю ещё раз: WPF медленней, чем WinForms. Справедливости ради скажу, что когда-то давно и WinForms ругали за медлительность. Но с тех пор мощь компьютеров возросла, и WinForms уже кажутся образцом скорости. Так же будет и с WPF: через несколько лет он будет летать на самых слабых компах.

    Ещё раз про аппаратное ускорение графики. Ну нет её в современных видюхах, нет! Я именно про 2D. Если точнее, она есть, но в подмётки не годится ускорению 3D. В современных видюхах нет многого из того, что было в игровых микрокомпьютерах. Как я уже писал, мощи ЦП достаточно для большинства нужд отрисовки ГУЯ, для игр чаще всего тоже достаточно, потому видюхи и развивались в области ускорения лишь трёхмерной графики. Недаром в геймдеве считается очень сложным создать навороченную двухмерную игру, именно из-за проблем с быстрой графикой. Я сам не в этой области работаю, но помню некотрое время назад вышла 2D игра файтинг, и там у разрабов была много работы именно с производительностью графики.

    Другое. Внешний вид приложений. Как я уже писал (но фанаты WPF "скромно" пропустили), все приложения, написанные с использованием WinAPI, MFC, VCL, WinForms, etc подстраиваются под системные настройки. Однако, горе-дизигнеры WPF забивают на это, и клепают формочки кто во что горазд. И причём самое подлое, очень часто нет вообще никаких настроек в приложении, и невозможно подогнать его под себя! Печальный итог: слабовидящие пользователи вынуждены мучаться (либо отказываются от таких приложений). Конечно, это проблема не столько платформы WPF, сколько глупость разработчиков, но всё же.

    Снова напомню мои претензии к формату XAML. Жуткий формат. Причём внутри него существует ещё один язык специально для байндинга. Вот жеж!..

    Теперь о плюсах WPF.

    За ним стоит могучая фирма. Именно поэтому к нему приковано внимание, именно поэтому его изучают.

    Аппаратное ускорение. Пусть плохое, но есть.

    Декларативное описание поведения ГУЯ. Замечательно! Я джва года этого ждал :). Скажу лишь, что я сторонник декларативщины, метапрограммирования, функциональщины и DSL.

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

    P.S. Честно говоря, удивляют оценки некоторыми моего знания/незнания WPF: 70%. А почему не 146%? Подтверждение будет, что именно столько?

    Точно так же я могу сказать, что вы не осилили WinForms и WinAPI, поэтому и клепаете формочки на XAML. :p

  • Ещё раз про аппаратное ускорение графики. Ну нет её в современных видюхах, нет! Я именно про 2D. Если точнее, она есть, но в подмётки не годится ускорению 3D. В современных видюхах нет многого из того, что было в игровых микрокомпьютерах. Как я уже писал, мощи ЦП достаточно для большинства нужд отрисовки ГУЯ, для игр чаще всего тоже достаточно, потому видюхи и развивались в области ускорения лишь трёхмерной графики. Недаром в геймдеве считается очень сложным создать навороченную двухмерную игру, именно из-за проблем с быстрой графикой. Я сам не в этой области работаю, но помню некотрое время назад вышла 2D игра файтинг, и там у разрабов была много работы именно с производительностью графики.


    WPF использует DirectX. Насколько я знаю, DX умеет и 2D и 3D обрабатывать. Можете объяснить отличия 2D графики от 3D? Точнее разницу в обработке её видеокартами.

    DreamSpark Premium User

  • http://ru.wikipedia.org/wiki/Direct2D


    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!

    Отвечающий
  • http://ru.wikipedia.org/wiki/Direct2D

    Ну на самом деле эта ссылка ничего не объясняет. Да конечно есть такой API Direct2D. Но это просто программный интерфейс, насколько он поддерживается видеокартой - это совсем другой вопрос. Впрочем я совершенно не берусь судить, потому что не знаю. Эти вопросы нужно задавать геймдеву, они знают лучше. Кроме того, по вашей-же ссылке, GDI+ как раз рисует через Direct2D.

    Кстати, касаемо неудобства XAML. Вспомнился старый холивар C vs Pascal. Когда-то в 90-х годах обя языка были популярны. Оба имели примерно одинаковые возможности, одинаковое быстродействие. Оба поддерживались Борландом. Но, что получилось в итоге? Где сейчас Си-подобные и где сейчас Паскале-подобные языки? А в чем причина? А причина в том, что паскаль банально неудобен. Ну неудобно писать begin/end, неудобно когда переменные объявлены в другом месте, неудобно писать :=. А ведь begin/end это цветочки, мелочь, по сравнению с монcтром XAML. Но тогда был выбор, и программисты выбрали Си. Но сейчас нам такого выбора не оставляют. Это плохо. Я вообще не понимаю, кому пришло в голову использовать XML для написания вручную(!) программного кода. Ладно, я понимаю HTML, но это язык врестки, а не программирования. Он на порядок проще XAML. Сам по себе XML полезный язык, но блин, он полезен для данных, которые генерируются программно, а не для ручного ввода..

    Отвечающий
  • На счет XML как основа для XAML объясню - все дело в строгой структурированности формата. В XML есть один родитель (Ствол дерева), а все остальное это вложенные элементы (ветки дерева). Эта вложенность удобна для описания интерфейса - в окне есть панель, в панели еще одна панель (в ней 2 текстбокса) и кнопка. Вот оно дерево. Необходимость в дереве нужна для многих решений WPF - например пузырьковое распространение событий, создание сложных шаблонов и т.д.

    Да я соглашусь с вами что пока нет идеального ЧВТИП редактора для XAML и даже имея VS и Blend часто приходится корректировать XAML в ручную, но эта жертва нужна была именно из за строгости XML. Например HTML я сравниваю не с деревом а с кустом, где масса стволов на которых масса веточек, что создает массу неудобств.

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


    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!

    Отвечающий
  • Ладно, я понимаю HTML, но это язык врестки, а не программирования. Он на порядок проще XAML. Сам по себе XML полезный язык, но блин, он полезен для данных, которые генерируются программно, а не для ручного ввода..


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

    DreamSpark Premium User


  • Я не буду дискутировать, раз уж обещал. Я просто расскажу историю из моей практики.

    2008 год, может самое начало 2009 уже не помню. Мне в руки попалась книга "C# 2008 для профессионалов" и там были две главы про WPF. Так как наш проект был уже огромен и был он на WinForms, то первые поделки на WPF были небольшими служебными формами для этого проекта. Мне очень понравилась структура XAML, его внутренний размер, читаемость. В 2008 студии, для XAML не работал донаборщик, дизайнер постоянно тупил, но то что получалось на выходе мне очень нравилось. Первые формы разрабатывались так же, как я бы делал на WinForms. Потом в ход пошел Binding, Command, MVVM. Но, пока не вышла VS 2010 все остальные программисты смотрели на WPF, как на некую диковинку, которой практического применения пока нет. С выходом VS 2010 beta, пусть с тормозной, но расширенной поддержкой возможностей WPF, команда стала переходить на него. Сейчас, все вспоминают разработку на WinForms, как страшный сон. Просто для того, чтобы обсуждать достоинства и недостатки надо иметь опыт в обоих технологиях. У меня, да и многих из моей команды он есть. Delphi, WinAPI, C#, WinForms, ASP .Net, WPF, Silverlight. И если мне придется писать на WinForms, я не упаду в обморок, не буду кричать: "А!!! Мы все умрем!!!". Но, если у меня будет выбор, то я его сделал уже 4 года назад: WPF, т.к. разрабатывать быстрее, модифицировать быстрее, а если кто-то будет грузить из БД в память локальной машины 5 миллионов записей для показа в списке, то я ему лопатой дам по голове и заставлю думать над тем, что же хотел пользователь получить вместо этих 5000000 записей.

    Приятного программирования ))

    Отвечающий
  • Я вообще не понимаю, кому пришло в голову использовать XML для написания вручную(!) программного кода. ..


    А вроде никто не заставляет его писать вручную. Expression Blend позволяет практически полностью скомпоновать приложение без использвоания клавиатуры (ну почти). А возможность редактирования XAML лично для меня хороша тем, что т.к. я только начинаю изучать всё это, то мне быстрее посмотреть в XAML коде свойства объекта, чем рыскать по редактору, искать где же оно находится. =)

    DreamSpark Premium User

  • http://ru.wikipedia.org/wiki/Direct2D


    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!


    Так в 3D графике без 2D никуда. Как минимум, текстуры относятся к 2D графике и прорабатываются аппаратно (забыл как называются эти модули). Остальное сейчас не вспомню. Так что Не считаю верным высказывание, относительно того, что в WPF плохо реализована аппаратная отрисовка графики.

    DreamSpark Premium User

  • Black-millenium до конца понять смыл аппаратного ускорения графики (в том числе 2D) вам помогут эта и вот эта статьи.

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


    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!


    Отвечающий
  • Скачал я проект Алексея. Увы, мне не удалось вкусить всех красот технологии: приложение даже не запускается. Мой тестировочный комп с 1 Гб памяти не способен на такой подвиг. Свободно было более 800 Мб - не хватило.
    Скачал приложение Алгола. На том же компе, с тем же количеством свободной памяти запустилось.
    Я понимаю, что серьёзные проекты - для серьёзных компьютеров. Однако все свои проекты я гоняю на своём стареньком Атлоне. Работаю на новом, тестирую на старом. Потому что у большинства пользователей компы трёх-, пяти-, десятилетней давности. Удивляет разрабы, не догадывающиеся о таком, и если у них на топовом компе всё работает, то проект пускают в жизнь. Имхо, гнать нужно таких из профессии :).

    Опять же, не поймите меня превратно. Я не ретроград, и понимаю, что скорость разработки чаще всего важнее скорости готового приложения. Именно поэтому я использую в основном C#, а не C++ (хотя и на нём пишу). Но хотя бы чуть-чуть оптимизировать свои творения надо, нэ?


    Я пытался обратить внимание на несколько важных пунктов:

        Скорость интерфейса.
        Возможность настройки интерфейса.
        Удобство и лаконичность языка разметки.

    Рад, что хотя бы по первому пункту удалось достучаться до сознания, и фанаты WPF признали, что эта технология менее производительна.

    Но как быть с внешним видом? Я вынужден повторить ещё раз: во времена DOS и других подобных операционок, у всех приложений был свой собственный интерфейс. Что чрезвычайно усложняло работу пользователей: в каждом новом приложении приходилось с нуля осваивать команды и т. п. С приходом Windows всё устаканилось. И что теперь? Опять приложения WPF имеют свой собственный интерфейс, зачастую очень сильно не похожий на стандартный, к которому привыкли тысячи пользователей. Имхо, создателей таких GUI нужно отлучать от компов. Только не надо говорить, что пользователь выбирает "красивости". Пользователь в первую очередь выбирает привычность и удобство! А невозможность сменить внешний вид (и поведение) интерфейса под свои нужды - огромный минус! Именно этим зачастую страдают многие приложения WPF (не все, да).

    Язык разметки. Просто посмотрите мельком на QML, JavaFX, DFM. Синтаксического шума намного меньше. Взглядом проще охватить большее количество информации. Структура точно так же древовидная, как и в XML/XAML. Описание GUI на самом C# тоже древовидно! Не понимаю, как можно не видеть этого с первого взгляда. Только не надо придираться к тому коду, что генерируется автоматически: он почти не предназначен для редактирования человеком.
    Суть проста: кто ничего больше не видел, кто привык к чему-то одному, тот и защищает своё. Только не надо меня подозревать в "неосиляторстве". Я на xml собаку съел. Обожаю работать с этим форматом (когда что-то знаешь назубок, начинаешь любить это, потому что легко и быстро всё делается). Но тем не менее, XAML - ужасен.

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

    Напутствие начинающим: учите WPF. Но также обращайте внимание на другие технологии: пусть их не нужно осваивать досконально, но хотя бы знать в общих чертах - очень полезно.
  • >> Рад, что хотя бы по первому пункту удалось достучаться до сознания, и фанаты WPF признали, что эта технология менее производительна.

    "Фанаты" WPF признали, что действительно подтормаживает 5000000 элементах без без виртуализации. Не надо обобщать ;)

    По поводу "слабовидящих пользователь" - я сам не орёл, и сижу за матрицей с мелким зерном. И прекрасно знаю, как разносит WinAPI/Winforms приложения на 120% шрифтах. И знаю насколько трудно подогнать WinForms под нестандартные шрифты. Поэтому никто из разработчиков это не делает. А WPF вполне нормально тянется за нестандартным DPI, причем сам, без плясок с бубном.

    >> Ещё раз про аппаратное ускорение графики. Ну нет её в современных видюхах, нет! Я именно про 2D. Если точнее, она есть, но в подмётки не годится ускорению 3D.

    В современных видюхах нет разделения на 2D и 3D. WPF использует те фичи, которые раньше относили именно к 3D - pixel и vertex шейдеры, мультитекстурирование, и еще по мелочам - полный список был где-то в msdn. И смена слабой "современной" видюхи на нормальную современную видиху очень сильно бьет по скорости отрисовки.

    Да, в винформах стандартное шаблонное приложение на аналогичном железе будет работать чуть-чуть-чуть быстрее. Зато на построение удобного UI с нормальными transition-ами уйдут недели. А не дни, как в случае с wpf.

    Синтаксический шум в xaml? Загляните в form.designer.cs, сравните уровень шума! Вы же не руками xaml пишете, надеюсь? Научитесь работать в бленде.

    >> Только не надо придираться к тому коду, что генерируется автоматически: он почти не предназначен для редактирования человеком.

    После этого я совсем не понимаю, почему вы к xaml придираетесь.

    >> Напоследок скажу: я намеренно был резок в своих высказываниях

    Нет, вы просто приводили аргументы, не имеющие особого смысла.

    Вот вещи, которые в WPF сделаны лучше:

    1. Скорость работы интерфейса (если у вас в интерфейсе не 400 чекбоксов).
    2. Возможность сделать отзывчивый интерфейс (транзишины, всякие там вотермарки, глоу, и все прочее, что уже стандарт де-факто в веб). 
    3. Нормальная привязка к DPI (== возможность настройки интерфейса).
    4. Возможность отдать верстку и логику UI разным людям.
    5. Возможность писать юнит-тесты на логику UI.

    Да, и на последок - создателей хрома, IE, офиса, zune, и win 8 надо отлучить от компов, потому что "не похоже на windows xp"?

  • Я на xml собаку съел. Обожаю работать с этим форматом (когда что-то знаешь назубок, начинаешь любить это, потому что легко и быстро всё делается). Но тем не менее, XAML - ужасен.

    То ли лыжи не едут, то ли я чего понять не могу - а чем так сильно отличается XAML от любимого вами XML? Расширением разметки {}? Ну да в VS2008 как выше писал Алексей Лосев с этим были проблемы, но уже в VS2010 задать расширение разметки проще простого. Про то что редактор XAML постоянно совершенствуется я и вовсе молчу, будто со времен VS2003 в WinForms никаких улучшений сделано не было...

    Соглашусь я выше брякнул про 70% не особо проводя расчеты, но в целом я имел ввиду то же что говорит PashaPash "Нет, вы просто приводили аргументы, не имеющие особого смысла."

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


    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!

    Отвечающий
  • Да, и на последок - создателей хрома, IE, офиса, zune, и win 8 надо отлучить от компов, потому что "не похоже на windows xp"?

    Кстати об XP. Знаю массу людей которые активно пользуются оформлением с закругленными краями окна, но лично сам всегда делал вид аля Win2000 потому что система в разы быстрее работает. Когда столкнулся с Windows Vista/7 увидел обратное - переход от стандартной настройки к упрощенной вызывал жуткие тормоза. А с помощью какой технологии рисования создан Windows Aero? Графика совсем не ускоряется?

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

    И даже говоря о упомянутой тут пару раз Windows 8 - я пока не в восторге от metro, но смотрю на то как масса людей пользуется телефонами с metro UI, считают его удобным, интуитивным, то я начинаю думать что восприятие ПО тоже не стоит на месте и классическое окно скоро станет вызывать больше вопросов чем нестандартный metro


    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!

    Отвечающий
  • Кстати об XP. Знаю массу людей которые активно пользуются оформлением с закругленными краями окна, но лично сам всегда делал вид аля Win2000 потому что система в разы быстрее работает. Когда столкнулся с Windows Vista/7 увидел обратное - переход от стандартной настройки к упрощенной вызывал жуткие тормоза. А с помощью какой технологии рисования создан Windows Aero? Графика совсем не ускоряется?


    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!

    Дык я ж про это и говорил :) Что Aero использует возможности двухмерного ускорения, которые явно не столь плохи, как их оценил Petalvik.

    Ускорение там посредством DirectX 9 :?


    DreamSpark Premium User


  • Aero ускоряется железом. А вот упрощенная настройка - почти нет, работает по старинке.

  • И даже говоря о упомянутой тут пару раз Windows 8 - я пока не в восторге от metro, но смотрю на то как масса людей пользуется телефонами с metro UI, считают его удобным, интуитивным, то я начинаю думать что восприятие ПО тоже не стоит на месте и классическое окно скоро станет вызывать больше вопросов чем нестандартный metro

    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!

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

    DreamSpark Premium User

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


    DreamSpark Premium User

    Windows 8 стоит рассматривать как мост между миром настольных ПК и миром планшетов, поэтому эта версия останется гибридной. Вот когда рынок планшетов начнет вытеснять рынок настольных ПК, тогда скорее всего и появятся две редакции ОС ориентированных на разные нужды.

    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!

    Отвечающий
  • Я пытался обратить внимание на несколько важных пунктов:

        Скорость интерфейса.
        Возможность настройки интерфейса.
        Удобство и лаконичность языка разметки.

    Рад, что хотя бы по первому пункту удалось достучаться до сознания, и фанаты WPF признали, что эта технология менее производительна.

    Господи, ну как можно делать такие выводы, являясь настолько не компетентным в вопросе?
    1. Скорость интерфейса

    По примеру Algol36, я написал говнокод. В 2012 году от рождества Христова, я отказался от возможностей предоставляемых DependencyObject и DependencyProperty, заменив всю их мощь на обычные объекты и свойства. Вы таки знаете, WinForms идет в лес стройными редами:

    Кстаи, я говорил: "скорость работы производит весьма приятное впечатление". Не WinForms быстрее, а есть люди, которые могут на WinForms написать приложение работающее так же быстро как WPF. Вам моя позиция понятна?

    2.  Возможность настройки интерфейса

    Вы действительно не понимаете, что Algol36 использовал рисование, а не стандартные компоненты? Вы дейстивтельно не понимаете, что при смене темы Windows именно его приложение поведет себя неадекватно? Не понимаете? Давайте покажу:

    Вот, кстати почитайте, там есть пример, как легко написать свои темы, которые будут автоматически применяться, при смене темы в Windows. Может заодно покажете, как такое можно сделать стандартными средствами Framework 2.0?

    3. Удобство и лаконичность языка разметки

    Вы действительно считаете, что Binding вот такокго вида:

    final DoubleBinding db = scene.widthProperty().subtract(150);
        db.addListener(new javafx.beans.value.ChangeListener<  Number>() {
            public void changed(ObservableValue<? extends Number> ov, Number t, Number t1) {
            btn.setLayoutX(db.getValue());
            }
        });

    Лаконичнее вот такого:

    <Rectangle Width="{Binding ElementName=slider1,Path=Value}" ...

    Вот, собственно и все, я то я вам хотел сказать. А, нет, не все. Раз мое приложение не запускается на вашей раритете, то поставьте туда FrameWork 4 (не Client Profile) и закачивайте заниматься ерундой.

    Ну, а для того, чтобы мы могли с вами продолжать беседу не с позиций программиста и троля, напишите свою версию означенного приложения, со:

    1. скоростью работы выше и затратами памяти меньше чем мое или Algol36

    2. с поддержкой тем как у меня

    3. время разработки (ну вы же используете более лаконичные средства разметки чем я) должно быть меньше 1 часа.

    Спасибо, жду вашу версию приложения, а вот версия с говнокодом по примеру Algol36.


    Отвечающий
  • Так может сделают две редакции ОС? Для девелоперов, с привычным оконным интерфейсом и с возможностью запускать метро приложения, и для народных масс (с дефолтным Metro), которым вовсе не нужны все эти окошечки, реестры и всё остальное.

    Уже достаточно давно на моем рабочем ноуте стоит Windows 8. Никаких проблем с запуском оконных и Metro приложений не наблюдаю. Если вы запускаете "старое" приложение, то открывается рабочий стол и на нем вы работает как в старые добрые времена. Если вы запускаете Metro приложение, то оно запускается в полноэкранном режиме и вы работаете с ним, как с приложением Metro.

    И то, и другое работает быстро и удобно.

    Отвечающий
  • Уже достаточно давно на моем рабочем ноуте стоит Windows 8. Никаких проблем с запуском оконных и Metro приложений не наблюдаю. Если вы запускаете "старое" приложение, то открывается рабочий стол и на нем вы работает как в старые добрые времена. Если вы запускаете Metro приложение, то оно запускается в полноэкранном режиме и вы работаете с ним, как с приложением Metro.

    И то, и другое работает быстро и удобно.

    Проблем с запуском я тоже не наблюдал, но всё таки метро мне не нравится. Метро хорошо на мультиметийные станции, но никак не на рабочий десктоп. И хочу стандартный пуск, а то его вообще насмерть выпилили из W8. =(

    DreamSpark Premium User


  • Проблем с запуском я тоже не наблюдал, но всё таки метро мне не нравится. Метро хорошо на мультиметийные станции, но никак не на рабочий десктоп. И хочу стандартный пуск, а то его вообще насмерть выпилили из W8. =(

    DreamSpark Premium User

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

    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!

    Отвечающий
  • PashaPash: "Фанаты" WPF признали, что действительно подтормаживает 5000000 элементах без без виртуализации. Не надо обобщать ;)

    Я как раз и делал упор на то, что разрабы WPF забивают на производительность. Ибо дизайнеры, а не программеры. И то, что можно сделать быстрым, они делают тормозным. У меня претензии не к технологии, а тем, кто её использует.

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

    PashaPash: Да, в винформах стандартное шаблонное приложение на аналогичном железе будет работать чуть-чуть-чуть быстрее.

    Об этом и речь.

    PashaPash: Зато на построение удобного UI с нормальными transition-ами уйдут недели. А не дни, как в случае с wpf.

    И с этим я не спорю. Я сам предлагаю новичкам начинать с WPF.

    PashaPash: Синтаксический шум в xaml? Загляните в form.designer.cs, сравните уровень шума! Вы же не руками xaml пишете, надеюсь? Научитесь работать в бленде.

    Я же писал: "Только не надо придираться к тому коду, что генерируется автоматически". designer.cs - это сгенерированный код. Написанный вручную чист как слеза.

    PashaPash: После этого я совсем не понимаю, почему вы к xaml придираетесь.

    Потому что он громоздок. И пишется вручную! К сгерерированному - претензий нет.

    PashaPash: Вот вещи, которые в WPF сделаны лучше:
    4. Возможность отдать верстку и логику UI разным людям.
    Вот это - огромный плюс. Но опять же (я уже писал раньше): мои претензии именно к дизайнерам, которые клепают формочки, забивая на производительность и на привычность для большинства пользователей.

    PashaPash: Нет, вы просто приводили аргументы, не имеющие особого смысла.

    Ещё как имеют. Ведь все обратили на них внимание, и стали разбираться, что к чему. Моя цель выполнена.

    PashaPash: Да, и на последок - создателей хрома, IE, офиса, zune, и win 8 надо отлучить от компов, потому что "не похоже на windows xp"?

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

  • LXGDARK: а чем так сильно отличается XAML от любимого вами XML?

    Да ничем. Оба одинаково громоздки и ужасны.

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

    Но я предпочёл бы работать, например, с YAML.

    LXGDARK: Смотрим дальше - продажи Windows 7 бьют все рекорды но вы все равно продолжаете убеждать нас, что блестяшки и красоты интересуют узкий круг людей.

    Ещё раз, по буквам: для пользователя главное - привычность и единообразие. Приложения на XP должны выглядеть одинаково. Те же приложения на Win8 тоже должны выглядеть одинаково.

    Я вынужден повторить не в первый раз: половина виденных мной приложений WPF выглядят непохоже ни на что. Это сильно затрудняет начало работы с ними.

    Ещё раз повторю: мои претензии в этом вопросе не к технологии, а к дизайнерам!

  • Black-millenium, аппаратное ускорение в WPF есть. Но видеокарты имеют не так уж много возможностей помочь именно в отрисовке GUI. На игровых микрокомпьютерах двадцатилетней давности были некоторые возможности, которых нет в нынешних видеокартах. Скажем, аппаратные проверки коллизий спрайтов и т. п. Кое-что из того могло бы пригодиться и сейчас. Но сейчас проще и дешевле возложить это на центральный процессор.
  • По примеру Algol36, я написал говнокод.

    Кстати, да, забыл поблагодрить за оценку. Благодраю :)
    Отвечающий
  • Алексей Лосев: Вы таки знаете, WinForms идет в лес стройными редами

    Идёт, конечно же идёт! Повторяю в стопицотый раз: миграция на WPF неумолима. Я сам обеими руками за эту технологию. Однако это не мешает обращать внимание на её недостатки.

    Алексей Лосев: Вы действительно не понимаете, что Algol36 использовал рисование, а не стандартные компоненты?

    Прекрасно понимаю. Ещё не заглядывая в его код, я знал, что так оно и будет. Я имел честь знакомиться с приложениями Алгола раньше.

    Алексей Лосев: Вот, кстати почитайте, там есть пример, как легко написать свои темы, которые будут автоматически применяться, при смене темы в Windows.

    Я рад, что вы это почитали. Теперь есть шанс, что ваши приложения всегда будут подстраиваться под темы ОС.
    Моя цель выполнена.

    Алексей Лосев: Вы действительно считаете, что Binding вот такокго вида <skip> Лаконичнее вот такого <skip>.

    Язык разметки и язык привязки - разные вещи! Я об этом писал: "Причём внутри него существует ещё один язык специально для байндинга". Поймите: в Microsoft были вынуждены ввести в XAML ещё один внутренний язык для описания привязок!

    Поясняю: вместо XAML'а был бы лучше другой язык разметки, более лаконичный. А вот язык байндинга - его в любом случае можно (и нужно) разработать специальный. Я упоминал, что поклонник DSL. Именно предметно-ориентированные языки позволяют в разы сокращать код. Язык байндинга в XAML - тоже DSL. И я рад, что его сделали.

    Алексей Лосев: Раз мое приложение не запускается на вашей раритете, то поставьте туда FrameWork 4 (не Client Profile) и закачивайте заниматься ерундой.

    Таких "раритетов" в мире большинство. Вы же не думаете, что люди каждый год покупают новый компьютер, а старый выкидывают?
    Фреймворки у меня стоят все. Дело не в них, а в OutOfMemory.
    Однако, вынужден повторить: серьёзные приложения - серьёзным компьютерам (см. выше). И я не считаю недостатком данного приложения, что гига оперативы ему не хватило. Просто рабочий момент.

    Алексей Лосев: ну вы же используете более лаконичные средства разметки чем я

    Не использую. Я не дизайнер.

    Алексей Лосев: Ну, а для того, чтобы мы могли с вами продолжать беседу не с позиций программиста

    Неа. Я программист. С других позиций не хочу общаться.


  • Алексей Лосев: Вот, кстати почитайте, там есть пример, как легко написать свои темы, которые будут автоматически применяться, при смене темы в Windows.

    Я рад, что вы это почитали. Теперь есть шанс, что ваши приложения всегда будут подстраиваться под темы ОС.
    Моя цель выполнена.

    Э... Вы что, считаете, что я делал какие то дополнительные настройки в моем приложении? Хм. Это еще один повод игнорировать вас в данном споре, т.к. про WPF вы вообще ничего не знаете. Специально для вас поясняю: "WPF авотматически применяет темы из виндовс. Все, кроме стандартной Aero, в ней он заменяет цвет фона на белый". В указанной статье, есть пример, как своими темами заменять стандартные темы Windows. Т.е. если я сделаю полупрозрачные круглые кнопки, я смогу добиться их правильного отображения во всех темах Windows. А если я использую стандартные компоненты, то мне об этом даже задумываться не надо.

    P.s. Я все еще жду пример вашего приложения.


    Отвечающий
  • Кстати, да, забыл поблагодрить за оценку. Благодраю :)

    Извините, если я был слишком резок. Но да, если у меня кто-то из программистов будет использовать для классов модели, которые должны отображаться в пользовательский интерфейс обычные свойства, не уведомляющие о своем изменении, то я его буду тыкать в эту мерзость. И объяснять, почему в 2012 году необходимо по возможности использовать потомков DependencyObject, а там где это совсем нельзя (например унаследованный код или приложение с 5000000 записей), то хотя бы INotifyPropertyChanged.

    Еще раз прошу прощения. Как я уже сказал выше, я вас считаю высококласным техническим специалистом, и вы, видимо, просто поленились тратить на это время (час ночи, или во сколько вы начали...). Так что ни по вашему коду, ни по предоставленному примеру у меня претензий нет.


    Отвечающий
  • Ну и по поводу того, что XAML ужасен.

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

    В современном мире, если вы программист, для вас в процессе разработки есть только одна цель: поставить как можно раньше работающее ПО. А добиться этого можно только если вы пишите:

    1. Быстро

    2. Сопровождаемо

    3. Расширяемо

    4. Производительно

    5 и т.д.

    Но 1 и 2, как это для некоторых не печально, в настоящее время являются наиболее приоритетными.

    Отвечающий
  • Но да, если у меня кто-то из программистов будет использовать для классов модели, которые должны отображаться в пользовательский интерфейс обычные свойства, не уведомляющие о своем изменении, то я его буду тыкать в эту мерзость.

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

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

    Видимо, я за восьмимесячное отсутствие педогогической практики, совсем потярял навыки донесения своих мыслей. Есть технологии, которые ускоряют разработку приложений. Если вы ими не пользуетесь, то это ваше право. Есть замечательная технология Code First. Почему нет? Ну подумаешь, сопровождать код будет чуть посложнее, ну при добавлении сущности придеться писть не только класс сущности, но и не забывать добавлять код в DbContext, ну не будет работать Binding из WPF на всю свою мощь (я же все равно вас не убедил перейти с лошадиных упряжек на современные автомобили, ведь там гадкое машинное масло, бензин и все такое). Мы используем для моделирования предметной области инструментальные средства с графическим дизайном (да, это инструментальное средство Visual Studio), и код, котрый они генерят, уже потдерживает DependencyProperty. А вот для небольших проектов, где не будет базы данных, лучше написать модель, зная про новые возможности .Net Framework, чтобы получить все те плюсы, которые эти возможности дают. Но все, разговор перестает быть конструктивным, поэтому излагаю мысль максимально доступно:

    "Переходить на WPF надо не потому, что за эту технологию Microsoft (зеленые человечки или еще кто то, или она типа "стандарт индустрии"), а потому, что нет ни одного достоинства WinForms, которого не было бы в WPF, но в WPF есть достоинства, которых нет в WinForms".


    Отвечающий
  • Алексей Лосев, Извините за непонятливость, но не увидел в вашем спиче ответа на свой вопрос (да, я туповат..).
    Отвечающий
  • "Переходить на WPF надо не потому, что за эту технологию Microsoft (зеленые человечки или еще кто то, или она типа "стандарт индустрии"), а потому, что нет ни одного достоинства WinForms, которого не было бы в WPF, но в WPF есть достоинства, которых нет в WinForms".

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

    Думаю, те кто будут стоять перед выбором платформы смогут правильно понять доводы каждой стороны и принять информированное решение.


    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!

    Отвечающий
  • Здравствуйте. А не могли бы вы выложить примерчик на WPF, в котором в dtagrid с помощью запроса открывается простенькая таблица dbf или Access (2-3 произвольных поля). При этом, чтобы можно было редактировать данные прямо в datagrid и, при переходе на другую строку, автоматически записывались в БД.

    Я начал изучать WPF, прочитал книжку. Нашел, как сделать что-то подобное для MSSQL (через LINQ SQL), но для других типов баз данных методами, описанными в книге, сделать тоже самое оказалось не возможно (не поддерживается, так и пишет).

    В Делфи такой примерчик можно сделать за 5 минут (для dbf или mdb файлов, например - создал файл бд, в Делфи накидал компонентов, связал их между собой и готово), в VS WinForms делается дольше, но я разобрался как, а можно ли в VS WPF решать такие задачи относительно простым способом (т.е. без синхронизации данных в БД с изменениями в datagrid «вручную»)?

    Этот вопрос лучше задать в новой теме. Так и шанс ответа больше и отвечающим удобнее следить за ходом тем.

    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!

    2 января 2013 г. 10:33
    Отвечающий