Я кстати постом ниже написал что о Delphi не берусь судить вообще в силу своей не компетентности.
А от чего торчат?... Ну например в WPF любой компонет можно разобрать или сделать практически с нуля так как мне только надо (в голову прийдет). Ну и многое другое, тотже биндинг.   

К вопросу о RAD, буквально вчерашнее из аськи:

Beltar а в чем собственно проблема, у нехочется лезть в XAML код руками, так не лезем. Закрываем окно с ним и ничего о нем не знаем. Но зато если надо чего то, что стандартный контрол не предусматривает, берем и при условии определенных знаний легко доделываем.
Например хочется внутри техтбохов меленькие, серинькие иконки - поиск, редактирование, ридонли. Коротые исчезнут при наборе текста. Хочется, зделаем. И при этом ненужно лезть в какие-то супер дебри. И т.п.

Это сообщение отредактировал(а) SKrivosein - 6.4.2013, 14:04

Точно, именно это самое главное и есть 

Хмл-подобный?  XAML - это и есть XML вообще-то, во всяком случае один из словарей.

Я думаю, что твоя( как и многих дельфистов впрочем) проблема в том, что ты сравниваешь неизвестные тебе технологии с тем, что есть в дельфах и не задумываешься о том, что там может быть что-то, чему в дельфах просто нет аналога. Почему в майкрософте отказались от развития винформ? Да потому что они просто устарели и морально и технологически. Как оказалось, создать что-то, учитывающее современные требования к гую, поверх виндоус-контролов из библиотеки юзверь32 оказалось практически невозможно, вот и был создан впф, где просто все взяли и отрисовали с нуля. 
Относительно создания интерфейса так же, как и до появления... - тоже ерунда полная. Я очень сомневаюсь, что ты не понимаешь разницы между программным кодом и кодом на структурном языке. В первом случае ты описываешь действия по созданию всех элементов и добавлению их куда надо, во втором - код декларативно описыает структуру интерфейса. Если все же непонятно, то возьми к примеру ту страницу, которую ты сейчас читаешь и попробуй описать процесс ее создания на дельфе той же или к примеру яваскрипте, но только без использования таких свойств, как innerHTML и пр. Думаю разница сразу станет ясна.
Ну и наконец, в XAML можно создавать не только визуальные элементы, но там можно описывать привязку данных к свойсвам(там привязывать можно вообще все ко всему), триггеры, анимацию, стили шаблоны и даже действия (например созданные в дизайнере рабочих процессов). 
В качестве примера того, что такое шаблон, можно привести вот такую штюку
http://www.codeproject.com/Articles/17025/...w-Layout-in-WPF
в двух словах опишу: это обычная тривьюшка, для которой автор статьи просто написал небольшой шаблончик (причем заметь: никакого наследования и создания собственного контрола) и благодаря этому шаблончику контрол, выглядящий стандартно преображается до неузнаваемости, сохраяняя при этом свою функциональность(разворачивание узлов и прочее). Шаблон можно заменить даже в рантайме и дерево станет выглядеть как прежде. Дельфийские контролы могут предложить что-нибудь подобное? А ведь это только один небольшой пример, коих тыщи.

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

Дяд Вов, да им не понять.  Я когда то давно, когда в первый раз видел WPF, тоже сам себе сказал: " что это за родобие HTML?" Но потом когда поработал... Одна компоновка чего стоит, не зависящая от размеров окна, dpi монитора.... нечего умнее я не знаю. 

Да, пожалуй  

На самом деле в впф много идей взято из HTM. XUL и т. п. Просто там этим дело не ограничивается, а с первого взгляда да - выглядит все именно так.

Добавлено через 2 минуты и 21 секунду
И кстати, вот в этой статье
http://ru.wikipedia.org/wiki/Visual_Basic
написано, что в бейсике визуальный дизайнер появился в 91-м году. Неужели в дельфах раньше? 

Вообще мне на WPF было как-то пофигу, но запустил посмотреть, и имею право высказать свои впечатления.



Вот в этом-то и проблема, что в MS, похоже забыли уже, что же именно главное.



В Delphi, начиная с 4-ой версии, структура формы описывается банальным текстовым файлом определенной структуры. Ну так вот, мне 99.9% времени глубоко и искренне пофигу как оно там написано (я просто знаю, что могу залезть и что-то подправить, если нужно). Если в след версии Codegear с дуру заменит его на XML, то не получит ничего, кроме матюгов, т. к. проекты в старых версиях будет не открыть. При этом существующий текстовый формат не мешал добавлять самые разные фичи, от поддержки жестов, то технологоий живого связывания в XE2. Самое смешное, что если в XE2 было просто связывание, то в XE3 уже визуальный дизайнер. И ты мне рассказываешь про связывание посредством XML-файла?? Ну смешно же.
И как после этого я должен уверовать, что это такая прогрессивная технология? Почему я не должен вообще принимать всерьез такой реликт викторианской эпохи?
Кстати, вектора векторами, но значительная часть интерфейса вполне себе битовая и если я хочу, чтобы моя иконка выглядела нормально при любом размере мне ее надо увеличивать с приличным запасом, а если я сам что-то рисую...



Ну круто конечно, хотя ту же тривьюшку на Delphi можно самостоятельно перерисовать, примеров, правда, не видел. Только опять, причем тут XML?



Меня на C++ Builder не пересадишь даже под дулом пистолета, опыт общения с C++ этому противится. Что же касается Windows Forms, то нафига дельфисту куда-то переходить, когда у него и так все это есть?
Впрочем зачем что-то объяснять человеку который никак не может понять, что возможность кидать контролы на формочку это обязательно для любой среды разработки, сейчас ведь не 80-ые, но ничего серьезного ты компонентокиданием не создашь, оно просто позволяет сделать за час работу на которую надо 50 часов.

ВБ появился раньше. И в вижуал фокспро - раньше. Это было очень круто, но до тех лишь пор, покуда тебе не надо было добиться от визуального контролла чего-то чуть больше, чем он умеет. Умели стандартные контроллы, откровенно мало. Если тебе вдру оказывается нужно что-то больше - в руки MSVC+MFC и херачь OCХ, который тягай еще за собой.

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

Когда я говорил об вау, эффекте, я упоминал, что это было как ВБ, ВФП, но только с полиморфизмом и исходным кодом визуальных контроллов.

Добавлено через 4 минуты и 16 секунд

Я, лично, в делфисрачах занимаю исключительно оборонительную позицию. Все мои броски - ответны. 

Вот здесь как раз я вообще перестал понимать. Какая значительная часть растровая? У меня весь WPF интерфейс векторный. А вот иконки можно запихнуть битмап. Но зачем если можно их описать прямо в XAML?

А что главное?   

Здесь мы помоему вообще перестали себя понимать. А XAML чем не стандартезованый текстовый файл? И он нечего не связывает, а только описывает какие классы будут задействованы при работе программы.

Это сообщение отредактировал(а) SKrivosein - 6.4.2013, 21:40

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

Если ты этого не понял, то это еще не значит, что не знают они. На XAML можно сваять и под винформы и отлично будет работать и ради этого вообще смысла не было создавать WPF.

По-моему в старом бейсике это уже было. Давно съедено и высрано. Уже объяснил, что не только в расположении контролов дело.

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


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


Во-первых, ты просто даже не понял о чем я тебе хочу сказать. Где я говорил о связывании посредством хмл?  Я сказал, что в впф связывается все со всем. Это позволяет свести напсание программного кода к минимуму, а в некоторых случаях и вовсе без него обойтись. Это было сказано в процессе перечисления фич, которые куда важнее хамла, который ты назвал главной фичей этой технологии. 
Еще раз: ты говоришь, что там главное хамл, а я тебе отвечаю, что там куча всего, о чем ты не знаешь, в том числе упоминаю связывание и в результате оказывается, что я рассказал тебе о связывании посредством хмл. Нормально?  

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

Вставишь растровое изображение.

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

И опять ни при чем. Объяснение того, чем хмл лучше текстового файла для описания структур данных выходит очень далеко за пределы этой темы. Просто в силу некоторых преимуществ этого формата использовали именно его. Что ты имеешь против? Это ты решил, что хмл главная фича впф и теперь эту мысль упорно приписываешь мне.

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

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

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

И что из этого сейчас отсутствует в других технологиях, включая дотнет?

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

Если ты художнег, то можно  

Делаю так, да я немного художнег, но можно стыреть готовых вагон! А вон товарещь тоже художнег, он на несколько размеров больший свой растр рисует.  
А ещё Blend радостно переводит несколько векторных форматов в мини XAML!   

Это сообщение отредактировал(а) SKrivosein - 6.4.2013, 22:07

  Пожалуй, что дизайн основанный на Windows контролах действительно негибок. Собсно я продолжаю юзать VCL лабуду, но после каждой новой версии делфей тихо фигею объему кода, который используется для работы с винконтролами. Намного проще было нарисовать все это самому, чем виртуозно-монструзно использовать это все. 
  Правда нужно отдать должное, делфи тоже не стоит на месте и новая библиотека FireMonkey уже принципиально другая. Сильно не изучал ее, но по описанию тянет на WPF . Вместо иксов используют OpenGL для переносимости и наконец своя отрисовка всего. Тоже есть векторные и 3D интерфейсы. Она, конечно, еще молодая, но задатки серьезные. Опять же декларируют отделение бизнес логики от вида.
  

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



Поток GUI обычно простаивает, вот его и нагружают, при этом можно вызвать Application.ProcessMessages. Вряд ли создание отдельного потока на каждый чих оправдано, особенно если этот чих предполагает доступ к GUI. А типовые ситуации, когда поток нужен (таймер тот же), сам бог велел оборачивать так чтобы свести сложности в использовании к минимуму. Да и когда VCL писали, ее на многопроцессорные системы не рассчитывали.

Вау-эффект же.
Тогда это была бомба. Что есть бомба сейчас? WPF? 


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


Это сообщение отредактировал(а) Zloxa - 6.4.2013, 22:30

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