Еще switch

[Igors]

Добрый день

Вот еще больший switch в неск др ситуации

Код

C++ (Qt)
bool MyWindow::ControlChanged( int id )
{
  switch (id) {
    case ID_AMOUNT:
     {
         float newVal, oldVal = mObject.amount;  // текущее значение параметра amount (в данных)
 
// проверяем что новое значение в UI валидно и не равно старому
         if (Editor::AcceptFloat(this, ID_AMOUNT, minAmount, maxAmount, oldVal, &newVal)) {
 
// запоминаем старое значение для undo
            SaveUndo(mObject, ID_AMOUNT);
 
// устанавливаем новое значение
            mObject.setAmount(newVal);
 
// обновляем UI 
            UpdateUI();
         }
         break;
     } 
  // и.т.д.
} 

Ну и так для каждого контрола. Когда я портировал это на Qt - конечно подумал о слот-сигнал. Мне кажется в данном случае он ничего особенного не дает. Где помещать слот? В самом MyWindow - ну записали каждую ветку switch в видк ф-ции слота, не вижу чем это лучше. А в самой структуре данных (mObject) - тогда тянем туда  ф-ционал UI, это явно плохо. Кстати большинство структур совсем не нуждаются в QObject/Q_OBJECT

Хотелось бы создать класс(ы) который знает и UI айтем и поле данных куда читать/писать, а потом на этом классе уже что-то варить. Но как это лучше сделать?

Спасибо

[Igors]

А все-таки как быстро гаснет энтузиазм когда нет быстрого ответа 

Во всех сотнях веток свитча схема совершенно одинакова:

- принимаем значение из UI и валидируем его
- запоминаем текущие данные для undo
- замещаем их на интерфейсные
- обновляем что-то в UI

В других свитчах схема чуть другая - но она тоже неизменно повторяется в каждой ветке. При пополнении свитча новый код часто совпадает почти полностью с какими-то имеющимися ветками, отличаясь лишь полем данных и 1-2 константами. Но выделять какие-то общие ф-ции как-то не очень получается. Либо они покрывает лишь некоторые ветки, либо разрастаются в монстряку "на все случаи жизни" - а потом это еще и не так.

Ну и конечно оправдания типа "нет времени, надо поднимать проект!" всегда найдутся, поэтому копи/паста. по 2-3 минуты на параметр Как бы мне если не убрать свитч, то сделать его "более цивильным" что ли, а то copy/paste цветет таким пышным цветом..

[Bepec]

Прежде чем что то переписывать нужно подумать - а оно нужно?
Вместо упрощения вы можете получить десятки багов, сложную архитектуру и гибкость.

PS каждый случай надо рассматривать раздельно, а тут вы со своими динамически изменяемыми условиями, вот народ и уходит из ваших тем...

[Igors]

вы можете получить десятки багов, сложную архитектуру и гибкость.

Совсем неплохо сказано (пусть и случайно  )

а тут вы со своими динамически изменяемыми условиями,

А Вы? У Вас нет undo - ну допустим. Но остальное-то есть. Или Вы вообще далеки от UI и занимаетесь только (сложными) расчетами? 

[kuzulis]

У Вас нет undo - ну допустим.

А это http://qt-project.org/doc/qt-4.8/qundo.html не?

[Igors]

У Вас нет undo - ну допустим.

А это http://qt-project.org/doc/qt-4.8/qundo.html не?

Увидел знакомое слово - на всякий случай тыц ссылкой, и пошел дальше портам хвосты крутить Имелось ввиду что Вересовские приложения могут и не поддерживать undo

[Bepec]

Моим и не надо. У меня большей частью написание клиентов. А ундо на независимом от тебя сервере сделать - это надо очень постараться.

А сказано не случайно. Именно это я и имел в виду.

PS вы опять меняете условия Каждая новая задача - это тема для отдельного обсуждения. Нельзя писать что то и менять архитектуру раз в день

PPS точнее можно, но вот получится из этого гарантированный труп.

[m_ax]

Нельзя писать что то и менять архитектуру раз в день 

Так в том то и дело, что нет никакой архитектуры) И не было)
Вообще это слово здесь лучше не произносить)

[Bepec]

Одной затухшей темой Igors больше, одной меньше - никакой разницы

[Igors]

PS вы опять меняете условия Каждая новая задача - это тема для отдельного обсуждения.

Не понял, что я поменял-то? 

Так в том то и дело, что нет никакой архитектуры) И не было)

Совершенно верно, эти свитчи писал простой парень лет 20 назад (да больше). И вот они все еще работают - и даже расширяются! Правда не все так хорошо как хотелось бы. Вот и предложите "архитектуру" - ну или хотя бы "как лучше". В конце-концов должен же быть какой-то прогресс за истекшие 20 лет 

Пожалуйста, критикуйте. "Вот это сделано плохо, потому что <>. А лучше было <>". Или скажите честно "лучше оставить как есть, ничего лучшего не вижу". А то морщить носик с видом знатока всякий может 

[Пантер]

Igors, давай ты предложишь свою замену этому свичу, а мы уж покритикуем.

[Igors]

Igors, давай ты предложишь свою замену этому свичу, а мы уж покритикуем.

Ну а почему Вы думаете что я "знаю правельный ответ"? Не знаю, правда. И почему никто не рассказал как он делает - ведь UI почти всегда есть и принимать из него данные надо. Чего стесняться? 

У меня многие данные не "числа" а анимация, грубо говоря, "графики во времени", есть "текущее время" (глобальная переменная). Параметр есть еще одно ID анимационной кривой. Как ни странно, анимация обобщается гораздо легче. Выглядит примерно так

Код

C++ (Qt)
switch (controlID) {
 case ID_ENABLED:
  UpdateAnimCheckbox(controlID, ANIM_ENABLED_ID, updateUI = true); 
  break;
 
 case ID_AMOUNT:
  UpdateAnimFloatRange(controlID, ANIM_AMOUNT_ID, 0.0, 1.0); 
  break;
...
}

Свой метод для каждого типа контрола, их не так уж много. Эти методы легко иметь в базовом классе. Если какой-то специфичный UodateUI, то не упорствую в обобщении, а просто в том же свитче, напр

Код

C++ (Qt)
 case ID_COUT:
  if (UpdateAnimInt(controlID, ANIM_COUNT_ID)) {
   ... // update specific UI
  } 
  break;
 

Ну типа - если оно "specific", то один раз и будет.

Почему "тут хорошо обобщается, а там нет". Возможно причина в том что для анимационных кривых SaveUndo выписано в общем виде - правда ценой свитчей в др местах.