информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Где водятся OGRыСетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
On_control_range 10.11.02 19:58  Число просмотров: 1379
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
<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-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach