Совет по дизайну. Две модели для данных

[vizir.vs]

Модель ни чего не знает о количестве столбцов, будет ли это таблица, или график, или еще что-нибудь. У нее есть данные, а вьювер эти данные уже отображает. В твоем случае, например, у тебя есть массив из 32 чисел. Хекс должен этот массив интерпретировать как таблица из 16 столбоцов, а бин - как таблица из 8 столбцов. Модель на таблицу ни как не влияет. Может ты захочешь сделать еще один вьювер хекс-бин, который будет отображать в виде графика.

Ну так вот этот-то метод в модели http://qt-project.org/doc/qt-4.8/qabstractitemmodel.html#columnCount , а не во view.
Можно немного поподробнее, пжлста, как мне объединить эти 2 модели в одну.

Храни в моделях указатель на данные.

[UVV]

Ну так вот этот-то метод в модели http://qt-project.org/doc/qt-4.8/qabstractitemmodel.html#columnCount , а не во view.
Можно немного поподробнее, пжлста, как мне объединить эти 2 модели в одну.

Храни в моделях указатель на данные.

Спасибо, кэп. Я именно так и делаю, о чём написал уже выше по треду. Вопрос был в том, что если данные меняются в одной модели, как уведомить об этом другую модель? Если архитектура, как заметили выше, не совсем правильная, то как объединить эти две модели в одну, учитывая, что количество строк/столбцов разное?

[vizir.vs]

Вариант такой. Для функции data указывать роль. Создай две пользовательских роли hex и bin. В зависимости от роли будут и данные.

[UVV]

Вариант такой. Для функции data указывать роль. Создай две пользовательских роли hex и bin. В зависимости от роли будут и данные.

Окей, с data разобрались. Чё делать с row/columnCount?

[Bepec]

Делегат отрисовывает ВСЁ как хочет. И никто ему не указ. Вообще.

Если уж так хотите сделать всё в модели - тупо сделайте в ней 2 режима HEX и BIN.

[Old]

Делегат отрисовывает ВСЁ как хочет. И никто ему не указ. Вообще.

Если уж так хотите сделать всё в модели - тупо сделайте в ней 2 режима HEX и BIN.

А как все начиналось... "неправильная архитектура"... а закончилось все как всегда - сделайте тупо.

Вячеслав, все вы нормально делали, научите хранилище информировать модели о своем изменении (отсылкой сигнала), а в моделях ловите этот сигнал и обновляйте, только изменившиеся в хранилище данные.

[Bepec]

Old я не понял вас. Какой сигнал, какие изменения в хранилище

А делать "тупо" нужно всегда, когда нужно сделать быстро.

[Old]

Old я не понял вас. Какой сигнал, какие изменения в хранилище

Это потому, что вы ни секунды не думали над тем, о чем спрашивал ТС.

А делать "тупо" нужно всегда, когда нужно сделать быстро.

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

[m_ax]

А делать "тупо" нужно всегда, когда нужно сделать быстро.

Аха..) Вот после таких заявления, я начинаю лучше понимать пословицы типа:
"Я не настолько богат, чтобы тратить деньги на дещёвые вещи")

[Bepec]

Главная мудрость пословиц - они друг другу противоречат, если не знали Ибо нет золотой середины.

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

Я подумал. И вижу что у вас появилось хранилище. Откуда - я хз У ТСса 2 модели. Мб сначала предложить создать отдельное хранилище? А то вы как фокусник - создали хранилище из ниоткуда

Вы предлагаете вынести хранилище из модели. НО... Но модель это и есть хранилище. Вынести функционал - это тоже костыль

А так то, для внимательных - я предложил 2 варианта. Красиво и медленно или тупо и быстро.

[Old]

2Верес. Перечитайте первое сообщение. У ТС есть хранилище (данные) и есть две модели.
Может вы и подумали, только вряд ли поняли. Зато постов важных написали не мало.

[Bepec]

Почитайте сами. У него есть ДАННЫЕ. Над которыми 2(две) модели.
Нет у него хранилища. У него сырые данные. Было бы хранилище, вот тогда он бы поступил по вашему совету

[Old]

QByteArray это простое хранилище данных, к нему легко можно добавить сигнал о модификации.

[m_ax]

Главная мудрость пословиц - они друг другу противоречат, если не знали Ибо нет золотой середины.

Что там друг-другу противоречит?
Я уж молчу о том, что ситуации, когда "пятки горят" и надо за один день сделать абы как - это подход реальных "find/replace/if-else/case" профессионалов) Это, конечно, к крайностям не относится)     

[Bepec]

Давайте реализуйте мне за день программу сложности "я нихрена в этом не разбираюсь в первый раз вижу но делать надо". Я посмотрю на вашу архитектуру
Архитектура в первую очередь строится на знании предмета. А когда форс мажор, тут какие знания - тут лишь бы работало и быстрее.

PS футуристичные рассказы как люди писали программы с превосходной архитектурой за день можете не приводить - единственный в них смысл в том, что эти люди знали предмет и имели заготовки по нему