информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Портрет посетителяСтрашный баг в WindowsSpanning Tree Protocol: недокументированное применение
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Microsoft сообщила о 44 миллионах... 
 Множественные уязвимости в VNC 
 Шестой Perl превратится в Raku,... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Вообще-то для обработки нескольких контролов в mfc существует макрос on_control_range, о чем я написал в самом первом ответе этой нитки, так что не совсем понимаю, о чем тут продолжается спор :) 12.11.02 15:51  Число просмотров: 973
Автор: Dr. Nebula Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Ну да, в ClassWizard'е его нет, но можно ведь иногда и
> ручками попрограммировать :)
Уже воспользовался им, спасибо... :) просто теперь вопрос как в зависимости от nID выполнять операции над разными контролами. Типа
nID = 1000 значит DirPath1.SetReadOnly();
nID = 1001 DirPath2.SetReadOnly() и тд.
Просто не хочется загонять один и тот же код в блоки типа if или свитч - ведь имена даже переменных отличаются только последним символом - цифрой...
<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.
На ней написаны очень большие и солидные проги -- еси чо-то не знаешь,
это не значит что там такого нет :)))
1  |  2 >>  »  






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2019 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach