Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | |
MFC - rulezzz :)) 18.11.02 22:54 Число просмотров: 1306
Автор: + <Mikhail> Статус: Elderman
|
> Многие говорят MFC - дерьмо, но как правило это люди,
> реально не юзающие его!!
Potomu i ne usauchie ego.
> А что прикажите большие проги писать на чистом Win32???
WTL/ ATL
> Уж в принципе не намного дольше и на ассемблере!!!
> Кроме того, MFC - средство, позволяющее в будущем
> осуществить легкую
> портацию на прог на другую платформу...
Kakuu takua druguu platformu? (V chem legkost` zakluchaetsia?)
> ИМХО ООП -- рулитттт!!!
MFC ochen` daleko do OOP
|
|
<programming>
|
[C++] Оптимизация кода 10.11.02 19:50
Автор: Dr. Nebula Статус: Незарегистрированный пользователь
|
Привет всем!
Есть 6 функций, обработчиков ON_BN_CLICKED. Юмор в том, что выполняют они идентичные действия для разных полей и следовательно код у них отличается минимально. Если точнее то так:
...::OnBnClickedActive1()
{
DirPath1.SetReadOnly();
....
}
...::OnBnClickedActive1()
{
DirPath2.SetReadOnly();
...
}
и тд.
У меня есть такое ощущение, что все это можно сделать одним обработчиком... но как? Или я ошибаюсь?
Заранее спасибо
|
|
[C++] #define ??? 12.11.02 11:46
Автор: Dr. Nebula Статус: Незарегистрированный пользователь
|
Народ, а что сабжу пофигу находится ли он в блоке if или нет? Просто при обработке следующего кода всегда отдефинивается последнее значение...
if(nID == 1001)
{
#define Active Active1
#define DirPath DirPath1
}
else if(nID == 1007)
{
#define Active Active2
#define DirPath DirPath2
}
|
| |
Конечно пофигу. 12.11.02 12:04
Автор: PS <PS> Статус: Elderman
|
> Народ, а что сабжу пофигу находится ли он в блоке if или
> нет? Просто при обработке следующего кода всегда
> отдефинивается последнее значение...
>
> if(nID == 1001)
> {
> #define Active Active1
> #define DirPath DirPath1
> }
> else if(nID == 1007)
> {
> #define Active Active2
> #define DirPath DirPath2
> }
#define отрабатывется препроцессором до компиляции. Препроцессор же ничего не знает об if, ect...
Например код
#define a 5
printf( "%ld", a );
#define a 6
printf( "%ld", a );
Перед компиляцией (но после препроцессора) будет выглядеть так:
printf( "%ld", 5 );
printf( "%ld", 6 );
В твоем примере, если ты постевишь printf в if - то увидишь первое значение, если в else - то второе, а если после if/else - то тоже второе (последнее т.е.)
Кстати тебе компилятор никакого warning не выдал на счет редифинишена макроса ?
|
| | |
Конечно пофигу. 12.11.02 12:40
Автор: Dr. Nebula Статус: Незарегистрированный пользователь
|
> #define отрабатывется препроцессором до компиляции.
> Препроцессор же ничего не знает об if, ect...
> В твоем примере, если ты постевишь printf в if - то увидишь
> первое значение, если в else - то второе, а если после
> if/else - то тоже второе (последнее т.е.)
>
> Кстати тебе компилятор никакого warning не выдал на счет
> редифинишена макроса ?
неа, молчал как раба об лед :)
Слушай, а может тогда подскажешь как быть? См. первое сообщение и "Опечатку"...
|
| | | |
Не много не понятно, что ты хочешь оптимизировать ;) 12.11.02 13:40
Автор: PS <PS> Статус: Elderman
|
> Слушай, а может тогда подскажешь как быть? См. первое
> сообщение и "Опечатку"...
Если просто хочешь избавиться от "лишних" функций, то сделать это можно пожертвовав прозрачностью кода.
Если я не ошибся ты пользуешся MFC ?
1.Тогда зайди в View -> ClassWizard
2.В ClassName выбери свой класс.
3.В Object IDs выбери ID контролов (кнопок) (что то типа IDC_..)
4.В Messages BN_CLICKED.
5.Кнопка Delete Function
С п.3 повторить для всех контролов.
Теперь из .cpp сам удали тела функций.
Вернись в ClassWizard
Выбери свой класс.
В Object IDs имя класса.
В Messages выбери OnCommand
Кнопка Add Function.
Теперь в ф-ии OnCommand у тебя есть параметр wParam (первый из двух).
В нем ID контрола.
Можешь поставить по нему switch.
Можешь сделать еще так:
Как я понял у тебя под EditBox'ы (которые используются для ввода какого-то пути) заведенны объекты.
Положи указатели на эти объекты в массив (сам сделай массив указателей на эти объекты). Это лучше сделать в OnInitDialog.
Положи их так, что бы твой Path0 лежал по нулевому индексу, Path1 по первому и т.д.
Таким образом, в OnCommand ты сможешь избавиться от switch.
Только не забудь wParam привести к 0,1,...
Это делается легко. Допустим IDC_BUTTON1 определен:
#define IDC_BUTTON1 1000
тогда в OnCommand пишишь int inx = wParam - IDC_BUTTON1;
set[inx]->SerReadOnly();
Только убедись в том, что IDC кнопок идут по порядку.
|
| | | | |
Вообще-то для обработки нескольких контролов в mfc существует макрос on_control_range, о чем я написал в самом первом ответе этой нитки, так что не совсем понимаю, о чем тут продолжается спор :) 12.11.02 14:47
Автор: dl <Dmitry Leonov>
Отредактировано 12.11.02 14:48 Количество правок: 1
|
|
Ну да, в ClassWizard'е его нет, но можно ведь иногда и ручками попрограммировать :)
|
| | | | | |
Вообще-то для обработки нескольких контролов в mfc существует макрос on_control_range, о чем я написал в самом первом ответе этой нитки, так что не совсем понимаю, о чем тут продолжается спор :) 12.11.02 15:51
Автор: Dr. Nebula Статус: Незарегистрированный пользователь
|
> Ну да, в ClassWizard'е его нет, но можно ведь иногда и
> ручками попрограммировать :)
Уже воспользовался им, спасибо... :) просто теперь вопрос как в зависимости от nID выполнять операции над разными контролами. Типа
nID = 1000 значит DirPath1.SetReadOnly();
nID = 1001 DirPath2.SetReadOnly() и тд.
Просто не хочется загонять один и тот же код в блоки типа if или свитч - ведь имена даже переменных отличаются только последним символом - цифрой...
|
| | | | | | |
Вообще-то для обработки нескольких контролов в mfc существует макрос on_control_range, о чем я написал в самом первом ответе этой нитки, так что не совсем понимаю, о чем тут продолжается спор :) 12.11.02 17:49
Автор: dl <Dmitry Leonov>
|
> > Ну да, в ClassWizard'е его нет, но можно ведь иногда и
> > ручками попрограммировать :)
> Уже воспользовался им, спасибо... :) просто теперь вопрос
> как в зависимости от nID выполнять операции над разными
> контролами. Типа
> nID = 1000 значит DirPath1.SetReadOnly();
> nID = 1001 DirPath2.SetReadOnly() и тд.
> Просто не хочется загонять один и тот же код в блоки типа
> if или свитч - ведь имена даже переменных отличаются только
> последним символом - цифрой...
Умгум, спросонья не разобрался :) Тут уже дали два хороших ответа - загонять указатели на объекты в массив (если идентификаторы идут не подряд, можно в map), если жалко заводить еще один массив указателей, можно сразу вместо нескольких полей объявить один массив, подредактировав соответственно DoDataExchange. Ну или GetDlgItem.
|
| | | | | | |
On_control_range + ((cedit*)getdlgitem(nid))->setreadonly() 12.11.02 17:23
Автор: ukv Статус: Незарегистрированный пользователь
Отредактировано 12.11.02 17:38 Количество правок: 1
|
В таком случае применяем макрос ON_CONTROL_RANGE, а в его обработчике -
((CEdit*)GetDlgItem(nID))->SetReadOnly()или что-нибудь в этом роде.
|
| | | | | |
Да не было тут спора, пока ты не появился ;) 12.11.02 15:20
Автор: PS <PS> Статус: Elderman
|
Ты уже свой ответ дал - зачем же его повторять.
Мне же был задан вопрос, я ответил.
Что же касается наезда на ClassWizard - можешь сам удалять руками то, что он тебе уже прописал в код. А я потом посмотрю на глюки с твоим проектом. Закон: то что создано ClassWizard им и должно удаляться.
Вот теперь это уже больше похоже на спор... причем ни о чём.
|
| | | | | | |
Да не было тут спора, пока ты не появился ;) 12.11.02 17:45
Автор: dl <Dmitry Leonov>
Отредактировано 12.11.02 17:50 Количество правок: 1
|
> Ты уже свой ответ дал - зачем же его повторять.
> Мне же был задан вопрос, я ответил.
> Что же касается наезда на ClassWizard - можешь сам удалять
> руками то, что он тебе уже прописал в код. А я потом
> посмотрю на глюки с твоим проектом. Закон: то что создано
> ClassWizard им и должно удаляться.
Да я посто зашел и увидел, что после меня успели и про MFC suxx рассказать, и с макросами поиграть, и про WM_COMMAND вспомнить :)
Глюков же после удаления ClassWizard'овских вставок нет никаких - надо просто четко представлять, что и куда он вставляет.
|
|
MFC - suxx :)) 10.11.02 20:48
Автор: ggg <ggg> Статус: Elderman
|
|
ещё один спор на религиозную тему :)
|
| |
MFC - rulezzz :)) 17.11.02 11:47
Автор: Sidor Статус: Незарегистрированный пользователь
|
Многие говорят MFC - дерьмо, но как правило это люди,
реально не юзающие его!!
А что прикажите большие проги писать на чистом Win32???
Уж в принципе не намного дольше и на ассемблере!!!
Кроме того, MFC - средство, позволяющее в будущем осуществить легкую
портацию на прог на другую платформу...
ИМХО ООП -- рулитттт!!!
|
| | |
А я за WTL ! 19.11.02 20:26
Автор: Green Статус: Незарегистрированный пользователь
|
> Многие говорят MFC - дерьмо, но как правило это люди,
> реально не юзающие его!!
> А что прикажите большие проги писать на чистом Win32???
> Уж в принципе не намного дольше и на ассемблере!!!
> Кроме того, MFC - средство, позволяющее в будущем
> осуществить легкую
> портацию на прог на другую платформу...
> ИМХО ООП -- рулитттт!!!
Понимаю, что борода не совсем об этом, но...
WTL достойная замена MFC.
|
| | |
MFC - rulezzz :)) 18.11.02 22:54
Автор: + <Mikhail> Статус: Elderman
|
> Многие говорят MFC - дерьмо, но как правило это люди,
> реально не юзающие его!!
Potomu i ne usauchie ego.
> А что прикажите большие проги писать на чистом Win32???
WTL/ ATL
> Уж в принципе не намного дольше и на ассемблере!!!
> Кроме того, MFC - средство, позволяющее в будущем
> осуществить легкую
> портацию на прог на другую платформу...
Kakuu takua druguu platformu? (V chem legkost` zakluchaetsia?)
> ИМХО ООП -- рулитттт!!!
MFC ochen` daleko do OOP
|
| | | |
MFC - rulezzz :)) 20.11.02 23:40
Автор: Sidor Статус: Незарегистрированный пользователь
|
> > Многие говорят MFC - дерьмо, но как правило это люди,
> > реально не юзающие его!!
> Potomu i ne usauchie ego.
Я имел ввиду, что многие глянули, подумали -- дерьмо и
сложили субьективное мнение!
Надо было побольше поразбираться.....
> > А что прикажите большие проги писать на чистом
> Win32???
> WTL/ ATL
>
> > Уж в принципе не намного дольше и на ассемблере!!!
> > Кроме того, MFC - средство, позволяющее в будущем
> > осуществить легкую
> > портацию на прог на другую платформу...
> Kakuu takua druguu platformu? (V chem legkost`
> zakluchaetsia?)
Я имею в виду на другую платформу ваще...ну в Юникс например!
переписал MFC там, перекомпил - и готово..
> > ИМХО ООП -- рулитттт!!!
> MFC ochen` daleko do OOP
И какую ж из парадигм OOP он нарушает???
|
| | | | |
MFC - rulezzz :)) 21.11.02 01:28
Автор: + <Mikhail> Статус: Elderman
|
> > > Многие говорят MFC - дерьмо, но как правило это
> люди,
> > > реально не юзающие его!!
> > Potomu i ne usauchie ego.
> Я имел ввиду, что многие глянули, подумали -- дерьмо и
> сложили субьективное мнение!
> Надо было побольше поразбираться.....
>
> > > А что прикажите большие проги писать на чистом
> > Win32???
> > WTL/ ATL
> >
> > > Уж в принципе не намного дольше и на
> ассемблере!!!
> > > Кроме того, MFC - средство, позволяющее в будущем
> > > осуществить легкую
> > > портацию на прог на другую платформу...
> > Kakuu takua druguu platformu? (V chem legkost`
> > zakluchaetsia?)
> Я имею в виду на другую платформу ваще...ну в Юникс
> например!
> переписал MFC там, перекомпил - и готово..
Posmotrel by I na tebia kak ty budesh perepisyvat`, GUI v osobennosti.
>
> > > ИМХО ООП -- рулитттт!!!
> > MFC ochen` daleko do OOP
> И какую ж из парадигм OOP он нарушает???
Naprimer: direct access member variables , static member functions, static member variables, ispolzovanie structur with out member functions, global variables, mnogo regular functions, MFC does not have namespace . . .
|
| | |
MFC - suxx :)) 17.11.02 14:18
Автор: ggg <ggg> Статус: Elderman
Отредактировано 17.11.02 14:22 Количество правок: 2
|
> Многие говорят MFC - дерьмо, но как правило это люди,
> реально не юзающие его!!
было бы странно, если бы говорили, что дерьмо и юзали :)
многие юзающие его, реально не понимают, что творится под этими красивыми классами
> А что прикажите большие проги писать на чистом Win32???
в winapi есть куча всего
там чуть ли не весь run-time
большая часть mfc отличается от winapi только тем, что работает с this, а не с хэндлами
с сответствующими накладными расходами на преобразование
> Уж в принципе не намного дольше и на ассемблере!!!
намного
языки - это отдельный спор
можно новую ветку начать :)
> Кроме того, MFC - средство, позволяющее в будущем
> осуществить легкую
> портацию на прог на другую платформу...
winapi имеет все возможности для перевода проги на 64-бит винды
стоит только макроопределения поменять
> ИМХО ООП -- рулитттт!!!
согласен
но это не заслуга mfc
никто не мешает использрвать классы с winapi
причём свои классы, наиболее подходящие для данного проекта, а не навязанные дядей Биллом
|
| | | |
MFC - suxx :)) 20.11.02 15:31
Автор: amirul <Serge> Статус: The Elderman
|
Уж слишком он напоминает динозавра. Да и отладка свитчей - дело куда более приятное, чем путешествие по вложенным виртуальным функциям. Более того - хорошая практика линковать мфц статически для релиз-версии. А это еще больше увеличивает код и без того перегруженный разными ненужными вызовами.
Когда что-то не предусмотрено мфц-ой - заставить его это сделать - то еще удовольствие, даже если я точно знаю как это делается в plain api.
|
| | | | |
MFC - suxx :)) 20.11.02 23:32
Автор: Sidor Статус: Незарегистрированный пользователь
|
> Уж слишком он напоминает динозавра. Да и отладка свитчей -
> дело куда более приятное, чем путешествие по вложенным
> виртуальным функциям.
Дык нафиг отлаживать саму МФС???
Её ребята дадя Билли давно отладили уже!
>Более того - хорошая практика
> линковать мфц статически для релиз-версии. А это еще больше
> увеличивает код и без того перегруженный разными ненужными
> вызовами.
Согласен - при статическом линке код немного велик.....
Но это единственный минус
> Когда что-то не предусмотрено мфц-ой - заставить его это
> сделать - то еще удовольствие, даже если я точно знаю как
> это делается в plain api.
На ней написаны очень большие и солидные проги -- еси чо-то не знаешь,
это не значит что там такого нет :)))
|
|
|
подробно о проекте
Анализ криптографических сетевых...
