> > Многие говорят 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 он нарушает???
Привет всем!
Есть 6 функций, обработчиков ON_BN_CLICKED. Юмор в том, что выполняют они идентичные действия для разных полей и следовательно код у них отличается минимально. Если точнее то так:
> Народ, а что сабжу пофигу находится ли он в блоке 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.
Ты уже свой ответ дал - зачем же его повторять.
Мне же был задан вопрос, я ответил.
Что же касается наезда на ClassWizard - можешь сам удалять руками то, что он тебе уже прописал в код. А я потом посмотрю на глюки с твоим проектом. Закон: то что создано ClassWizard им и должно удаляться.
Вот теперь это уже больше похоже на спор... причем ни о чём.
Да не было тут спора, пока ты не появился ;)12.11.02 17:45 Автор: dl <Dmitry Leonov> Отредактировано 12.11.02 17:50 Количество правок: 1
> Ты уже свой ответ дал - зачем же его повторять. > Мне же был задан вопрос, я ответил. > Что же касается наезда на ClassWizard - можешь сам удалять > руками то, что он тебе уже прописал в код. А я потом > посмотрю на глюки с твоим проектом. Закон: то что создано > ClassWizard им и должно удаляться.
Да я посто зашел и увидел, что после меня успели и про MFC suxx рассказать, и с макросами поиграть, и про WM_COMMAND вспомнить :)
Глюков же после удаления ClassWizard'овских вставок нет никаких - надо просто четко представлять, что и куда он вставляет.
Многие говорят MFC - дерьмо, но как правило это люди,
реально не юзающие его!!
А что прикажите большие проги писать на чистом Win32???
Уж в принципе не намного дольше и на ассемблере!!!
Кроме того, MFC - средство, позволяющее в будущем осуществить легкую
портацию на прог на другую платформу...
ИМХО ООП -- рулитттт!!!
А я за WTL !19.11.02 20:26 Автор: Green Статус: Незарегистрированный пользователь
> Многие говорят MFC - дерьмо, но как правило это люди, > реально не юзающие его!! > А что прикажите большие проги писать на чистом Win32??? > Уж в принципе не намного дольше и на ассемблере!!! > Кроме того, MFC - средство, позволяющее в будущем > осуществить легкую > портацию на прог на другую платформу... > ИМХО ООП -- рулитттт!!!
Понимаю, что борода не совсем об этом, но...
WTL достойная замена MFC.
> Многие говорят MFC - дерьмо, но как правило это люди, > реально не юзающие его!! Potomu i ne usauchie ego.
> А что прикажите большие проги писать на чистом Win32??? WTL/ ATL
> Уж в принципе не намного дольше и на ассемблере!!! > Кроме того, MFC - средство, позволяющее в будущем > осуществить легкую > портацию на прог на другую платформу... Kakuu takua druguu platformu? (V chem legkost` zakluchaetsia?)
> ИМХО ООП -- рулитттт!!! MFC ochen` daleko do OOP
> > Многие говорят 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 - дерьмо, но как правило это > люди, > > > реально не юзающие его!! > > 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 - дерьмо, но как правило это люди, > реально не юзающие его!! было бы странно, если бы говорили, что дерьмо и юзали :)
многие юзающие его, реально не понимают, что творится под этими красивыми классами
> А что прикажите большие проги писать на чистом Win32??? в winapi есть куча всего
там чуть ли не весь run-time
большая часть mfc отличается от winapi только тем, что работает с this, а не с хэндлами
с сответствующими накладными расходами на преобразование
> Уж в принципе не намного дольше и на ассемблере!!! намного
языки - это отдельный спор
можно новую ветку начать :)
> Кроме того, MFC - средство, позволяющее в будущем > осуществить легкую > портацию на прог на другую платформу... winapi имеет все возможности для перевода проги на 64-бит винды
стоит только макроопределения поменять
> ИМХО ООП -- рулитттт!!! согласен
но это не заслуга mfc
никто не мешает использрвать классы с winapi
причём свои классы, наиболее подходящие для данного проекта, а не навязанные дядей Биллом
Уж слишком он напоминает динозавра. Да и отладка свитчей - дело куда более приятное, чем путешествие по вложенным виртуальным функциям. Более того - хорошая практика линковать мфц статически для релиз-версии. А это еще больше увеличивает код и без того перегруженный разными ненужными вызовами.
Когда что-то не предусмотрено мфц-ой - заставить его это сделать - то еще удовольствие, даже если я точно знаю как это делается в plain api.
> Уж слишком он напоминает динозавра. Да и отладка свитчей - > дело куда более приятное, чем путешествие по вложенным > виртуальным функциям. Дык нафиг отлаживать саму МФС???
Её ребята дадя Билли давно отладили уже!
>Более того - хорошая практика
> линковать мфц статически для релиз-версии. А это еще больше > увеличивает код и без того перегруженный разными ненужными > вызовами. Согласен - при статическом линке код немного велик.....
Но это единственный минус
> Когда что-то не предусмотрено мфц-ой - заставить его это > сделать - то еще удовольствие, даже если я точно знаю как > это делается в plain api. На ней написаны очень большие и солидные проги -- еси чо-то не знаешь,
это не значит что там такого нет :)))
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
