[win32-gui] сравнение Qt и MFС
Если учесть, что MFC остановилась в своем развитии - лет 7 назад, то, конечно, прав.
гг, все и так давно знают, что MFC - невероятный отстой.
с Qt работал не очень много, но впечатления остались приятные
с Qt работал не очень много, но впечатления остались приятные
Ален Голуб в своей книге "правила программирования на C/C++" постоянно брал примеры из MFC (ранних версий, правда) как примеры того, как делать не надо.
Let's take the example of a dialog containing a CEdit control. You can not use the method GetWindowText on this field if you are not inside the DoModal method. It will fail miserablyДля модальных диалогов это так, поскольку окно модального диалога вне DoModal не создано (и window handle - HWND - 0 соответственно, о чем и пишут в документации поэтому только в DoModal.
Но там же можно и немодальные диалоги создавать. И уже по-другому.
template creates the view but it is not possible to access it.Плохо читать такое без конкретного примера, че и как у него не получилось. Там действительно неочевидно до View добраться бывает( сначала до текущего CFrameWnd и т.д., потом уже GetActiveView, есть и др. способы). Но не невозможно.
Короче, обсуждать статью без конкретных примеров, а тем более делать выводы какие-то, не очень разумно.
Я ничего и никого не защищаю, просто статья как-то, имхо, неудачно написана.
PS
Еще про non-resizable edits, buttons. Да, в чистой MFC, к сожалению, так. Но на тех же codeguru.com, codeproject.com полно бесплатных resizable - контролов, ну и советов, как более сложные свои делать. Так что можно взять либо готовый (есть даже бесплатные для коммерческого использования) CResizableEdit, либо по статьям и советам свой писать.
Некоторые библиотеки на основе MFC (Stingray Objective Toolkit, BCG) поддерживают что-то там resizable.
что MFC остановилась в своем развитии - лет 7 назад,А почему до сих пор пишут и поддерживают библиотеки на основе MFC?
Мне приходилось работать с BCG.
Стоит всего 300$, а функциональность очень хорошая.
В общем, местами он, конечно, гонит, но в целом да MFC - это весьма убого. Оценить его хвалебные отзывы о Qt нет возможности - под Qt не писал, но есть подозрение, что и в Qt далеко не все так шоколадно, как обещают.
+1
>Qt далеко не все так шоколадно, как обещают.
Как человек, который уже лет 5 пишет на QT, могу с уверенностью сказать что все именно так шоколадно
Единственное с чем не согласен - со словами про layout engine. Иногда его трудно заставить делать то что нужно.
Как человек, который уже лет 5 пишет на QT, могу с уверенностью сказать что все именно так шоколадно
Единственное с чем не согласен - со словами про layout engine. Иногда его трудно заставить делать то что нужно.> А почему до сих пор пишут и поддерживают библиотеки на основе MFC?
а почему до сих пор пишут и поддерживают библиотеки на Cobol-е, basic-е, fortran-е?
ps
Есть много кода, который использует MFC, есть много людей и компаний которые уже знают и используют MFC.
И только в основном поэтому MFC как-то держится.
а почему до сих пор пишут и поддерживают библиотеки на Cobol-е, basic-е, fortran-е?
ps
Есть много кода, который использует MFC, есть много людей и компаний которые уже знают и используют MFC.
И только в основном поэтому MFC как-то держится.
Ну если сравнивать Qt vs. MFC, то тогда наверное нужно рассказать о том, как легко и удобно работать через Qt с ActiveX/OLE, особенно писать ActiveX компоненты и OLE серверы. Расскажи, как у Qt с этим обстоят дела?
Великолепно обстоят дела. http://doc.trolltech.com/3.3/activeqt.html
То, что написано по твоей ссылке - это и какой-нибудь ATL-умеет.
Как быть, например, с OLE-серверами?
Как быть, например, с OLE-серверами?
Слушайте, ну чего вы ко мне прикопались? Я винды и ихний апи уже пять лет в глаза не видел 
Я правильно понимаю что ole и mfc ну никак не связаны? Тогда я думаю что писать оле сервер под Qt и под MFC примерно одинаково по сложности.
Я правильно понимаю что ole и mfc ну никак не связаны? Тогда я думаю что писать оле сервер под Qt и под MFC примерно одинаково по сложности.на сколько я помню, в MFC как раз входила поддержка разработки OLE-серверов.
Поддержка OLE-серверов в MFC входит, об этом уже написал. OLE и MFC очень даже связаны, в том плане, что в MFC для этого есть какой-никакой набор классов. А в Qt в этом плане нет ничего. Еще для разнообразия можно устроить benchmark на потребление памяти интерфейсом, и нагрузку на CPU, для одинакового интерфейса, реализованного на Qt и на MFC. Думаю, что для такого теста можно подобрать такие варианты, что будет рулить любой из наперед заданных GUI Toolkits.
Вообще, все сравнения у кого пися длиннее - у Qt или у MFC, или еще у кого - это такая глупость...
Вообще, все сравнения у кого пися длиннее - у Qt или у MFC, или еще у кого - это такая глупость...
Есть много кода, который использует MFC, есть много людей и компаний которые уже знают и используют MFC.Я, например, прямо сходу могу придумать задачу, которую можно сделать на MFC/Win32, но нельзя на Windows Forms.
И только в основном поэтому MFC как-то держится.
Самые красивые и удобные библиотеки начинают просасывать, когда требуются нестандартные решения.И какую же?
Есть MDI окно. В нём есть дочерние окна. Надо внутри дочерних окон сделать ещё любое количество дочерних окон, которые должны иметь тайтл бар, ресайзиться, и т.п.
MDI разве не умер? Photoshop не в счёт 
А что такое Windows Forms?
А что такое Windows Forms?
Термин MDI не в смысле MFC, он в смысле наличия дочерних и родительских окон особого типа.
Не могу себе представить задачу, зачем такое извращение надо?
Чем не устраивают перетаскивающееся контролы? Зачем их делать честными windows-окнами?
Чем не устраивают перетаскивающееся контролы? Зачем их делать честными windows-окнами?
Затем, что есть программа, в которой работают много модулей параллельно, и в этих модулях нужны окна, которые функционируют только внутри этих модулей и на них уже есть контролы и пр. Ну не буду я полностью проект описывать, просто это надо было сделать. На Windows Forms не получилось, а на MFC получилось.
Чем не устраивают перетаскивающееся контролы? Зачем их делать честными windows-окнами?
Сделать Custom control - у которого есть title, за который можно перетаскивать и все.
И работать будет быстрее, и выглядить будет лучше.
И работать будет быстрее, и выглядить будет лучше.
Тем, что они сами должны иметь на себе группы контролов. Слушай, не прикапывайся плиз к задаче. Она была, была реальной, и была сделана.
> Тем, что они сами должны иметь на себе группы контролов
и? что мешает контролу в себе содержать еще толпу контролов?
ps
Ты предложил задачу, я тебе предлагаю решение - причем более правильное, соответствующее лучшим рекомендациям от microsoft-а.
и мне не понятно - чем это решение тебе не нравиться...
и? что мешает контролу в себе содержать еще толпу контролов?
ps
Ты предложил задачу, я тебе предлагаю решение - причем более правильное, соответствующее лучшим рекомендациям от microsoft-а.
и мне не понятно - чем это решение тебе не нравиться...
И чем этот контрол будет отличаться от окна?.. Ну ты это можешь сделать на Windows Forms?
Политика же microsoft-а довольно четкая в этом плане.
Они говорят, что вставка одних top-левел окна в другие топ-левел окна (например, как в mdi) - это не правильно.
Что модель должна быть проще - есть топ-левел окна, и есть контролы, и другого не надо.
Они говорят, что вставка одних top-левел окна в другие топ-левел окна (например, как в mdi) - это не правильно.
Что модель должна быть проще - есть топ-левел окна, и есть контролы, и другого не надо.
Тем, что он будет контролом
public partial class Form1 : Form
{
public Form1
{
InitializeComponent;
}
private void Form1_Load(object sender, EventArgs e)
{
Control control = new Control;
control.Width = 40;
control.Height = 40;
control.BackColor = Color.Red;
this.Controls.Add(control);
Control control2 = new Control;
control2.Width = 20;
control2.Height = 20;
control2.BackColor = Color.Green;
control.Controls.Add(control2);
control.MouseDown += new MouseEventHandler(control_MouseDown);
control.MouseUp += new MouseEventHandler(control_MouseUp);
control.MouseMove += new MouseEventHandler(control_MouseMove);
}
void control_MouseMove(object sender, MouseEventArgs e)
{
if (isMove)
{
Control control = (Control)sender;
control.Location = new Point(startP.X + e.X - p.X,
startP.Y + e.Y - p.Y);
Console.WriteLine("{0}:{1},{2}", e.Button, e.X, e.Y);
}
}
void control_MouseUp(object sender, MouseEventArgs e)
{
if (isMove)
{
Control control = (Control)sender;
control.Location = new Point(startP.X + e.X - p.X,
startP.Y + e.Y - p.Y);
isMove = false;
}
}
bool isMove = false;
Point p;
Point startP;
void control_MouseDown(object sender, MouseEventArgs e)
{
if e.Button & MouseButtons.Left) == 0)
return;
isMove = true;
p = new Point(e.X, e.Y);
startP = Control)sender).Location;
}
}
Ну теперь ещё нужно туда прицепить тайтл бары, загнать внутрь другие контролы, добавить модальность (например, выполнение одного из этих окон модально в рамках MDI Child окна)... Что-то мне не кажется, что всё это так просто получится?..
> нужно туда прицепить тайтл бары
одна строчка при отрисовке
одна строчка при определении надо двигать или нет
> загнать внутрь другие контролы
уже в примере есть внутренние контролы
> добавить модальность
это еще пара строчек в wndProc-е
одна строчка при отрисовке
одна строчка при определении надо двигать или нет
> загнать внутрь другие контролы
уже в примере есть внутренние контролы
> добавить модальность
это еще пара строчек в wndProc-е
offtopic:
вообще, интересная тенденция. Последнее время любой спор "технология от MS" vs. что-либо еще заканчивается всегда однозначно: "А вот .NET лучше!".
вообще, интересная тенденция. Последнее время любой спор "технология от MS" vs. что-либо еще заканчивается всегда однозначно: "А вот .NET лучше!".
но .Net - действительно довольно красивая и удобная штука.
ps
Самое главное - что .Net является логическим продолжением технологий предыдущего поколения, поэтому и получается, что нафига сравнивать устаревшие технологии - если уже и активно используется более новая технология.
ps
Самое главное - что .Net является логическим продолжением технологий предыдущего поколения, поэтому и получается, что нафига сравнивать устаревшие технологии - если уже и активно используется более новая технология.
Да я ж не спорю, мне .NET нравится. Просто тенденция забавная.
Не знаю как у тебя, но у меня этот кусок кода работает странно. Контролы дёргаются пока кнопку мыши не отпустишь, не успевают за движением мыши. Ну ладно, допустим это всё можно подогнать. Плюс ко всему вышеперечисленному надо добавить z order (то есть отслеживать клики на любой даже внутренний контрол клиппинг отрисовки, tab order внутри контролов, хотя бы кнопочку закрытия окна справа сверху... Эти замечания только сходу придумались... Так мне кажется, я на Win32 API быстрее выполню эту задачу. Как я уже написал, любое нестандартное решение превращает красивый Windows Forms в кучу извращений, так что пока я мнения не изменил...
Хотя да, ты убедил меня, что на Windows Forms это теоретически можно сделать. Когда мы копались, то пытались найти способ создать окна, что невозможно.
вот что про MFC пишут сами буржуины.. http://msdn.microsoft.com/visualc/whidbey/mfc2005/default.aspx
статья полный чес - особенно прибил абзац про МСДН дальше даже читать не стал, и про Эдиты пример полностью бредовый.. сделал наследника и сделал все нужные методы безопасными для вызова после прибития окна.. все.. делов на копейку.с Qt не знаком, меня занесло прогать на MFC впечатление в целом терпимое, обертка вокруг апи нормальная, можно пользоваться этим самым апи напрямую или через врапперы, есть конечно минусы (Док-Вид это конечно страшный сон от которого нельзя проснуться) с удовольствием перешел бы на .NET, пока такого удоваольствия не предоставляется. вот может с выходом 2005
, обещают интеграцию и видимо в дальнейшем она углубится, инерция у MFC слишком большая, чтобы взять и выйти на ходу ...
статья полный чес - особенно прибил абзац про МСДН дальше даже читать не стал, и про Эдиты пример полностью бредовый.. сделал наследника и сделал все нужные методы безопасными для вызова после прибития окна.. все.. делов на копейку.с Qt не знаком, меня занесло прогать на MFC впечатление в целом терпимое, обертка вокруг апи нормальная, можно пользоваться этим самым апи напрямую или через врапперы, есть конечно минусы (Док-Вид это конечно страшный сон от которого нельзя проснуться) с удовольствием перешел бы на .NET, пока такого удоваольствия не предоставляется. вот может с выходом 2005
, обещают интеграцию и видимо в дальнейшем она углубится, инерция у MFC слишком большая, чтобы взять и выйти на ходу ...Оставить комментарий
Landstreicher
Господа! Кто имел опыт работы с MFC (я сам не имел)? Прокомментируйте, плз, статью http://phil.freehackers.org/kde/qt-vs-mfc.htmlДействительно, такие грабли имеются или же автор гонит?