Создание неограниченного количества элементов Опции

[RazrFalcon]

Алексей1153, что значит показать, у меня обычно они так видны (все что я таким способом создавал), а при setVisible/show просто отдельный виджет появляется с graphicsViev. Циклом твои тоже ничего не видно, хотя компилит. Спасибо за цикл кстати.
Litkevich Yuriy, ну их создается ровно столько сколько нужно, циклом, так что лишних нет.
я же писал, что то типа раскадровки гиф/видео, там же их будет 1000-чи...

Сообщение отредактировал RazrFalcon - 12.8.2010, 22:33

[Алексей1153]

RazrFalcon, ну, предположим, он видим. Но ты указатель на родительский виджет не передаёшь

new QGraphicsView();

может, тут сябака порылась? )

что то типа раскадровки гиф/видео, там же их будет 1000-чи...

достаточно столько вьюх, сколько влезет на экран. Остальное - организовать "логическое окно" просмотра (вроде как цепь протягивают в трубе, а в трубе есть 5 отверстий - видно одновременно 5 кадров-звеньев)

[RazrFalcon]

Алексей1153, спасибо за идею попробую ограничится только влезшими на экран.
Спасибо всем, все работает.
Создаем:

    QList<QGraphicsView *> list;
    for(int i=0;i<10;i++)
    {
       list.append(new QGraphicsView(this));
    }

Изменяем:

int x=0, y=0;
   for (int i=0; i<list.count();i++)
   {
      list[i]->setGeometry(x,y,50,50);
      x+=51;
      y+=51;
    }

PS (this) помог, я как то раньше не обращал внимания.
PSS еще б с этим разобраться =)

Сообщение отредактировал RazrFalcon - 12.8.2010, 23:18

[Алексей1153]

RazrFalcon, ещё два момента:

1) поскольку QList<QGraphicsView *> list предположительно - член класса, то перед циклом заполнения не забывай проверить, сколько элементов уже есть в списке. Не забывай также удалить через delete (как вариант, можно сделать оболочку для указателя, чтобы не приходилось вызывать delete вручную - щас приведу ниже)

Раскрывающийся текст

//вумный указатель для хранения в векторе и иже с ним
    template<typename T>
    struct s_VectorPtr
    {
        T* m_p;

        s_VectorPtr()
        {
            m_p=0;
        }

        s_VectorPtr(const s_VectorPtr& o2)
        {
            m_p=0;
            (*this)=o2;
        }

        void createIfNotYet()
        {
            if(!m_p)
            {
                m_p=new T;
            }
        }

        ~s_VectorPtr()
        {
            if(m_p)
            {
                delete m_p;
                m_p=0;
            }
        }

        void operator=(const s_VectorPtr& o2)
        {
            if(m_p)
            {
                delete m_p;
                m_p=0;
            }

            T* p=o2.m_p;
            ((s_VectorPtr&)o2).m_p=0;
            m_p=p;
        }

        T* operator ->()
        {
            return m_p;
        }
    };


//обявление теперь выглядит так
QList< s_VectorPtr<QGraphicsView> > list;//тут "*" не надо!

теперь, если изменение размера вектора влечёт за собой удаление элементов, delete вызовется автоматом


2)число 10 - это от балды. Тут следует сделать динамическую прикидку количества вьюх

Сообщение отредактировал Алексей1153 - 13.8.2010, 20:32

[BRE]

Алексей1153, для чего столько всего в деструкторе?

    ~s_VectorPtr()
    {
        if(m_p)
        {
            delete m_p;
            m_p=0;
        }
    }

достаточно просто:

    ~s_VectorPtr()
    {
        delete m_p;
    }

По стандарту delete умеет работать с 0-указателями, он их проверяет и ничего не удаляет.
Зануление указателя в деструкторе тоже бессмыслено, сразу после этого объект все равно разрушиться.

[Алексей1153]

BRE, проверка if(m_p) здесь обязательна: смотри работу operator= Стандарт стандартом, но грабли потом искать не хочется, если что

ну а обнуление висячего указателя - это просто полезная привычка

Сообщение отредактировал Алексей1153 - 13.8.2010, 8:06

[BRE]

BRE, проверка if(m_p) здесь обязательна: смотри работу operator=

В деструкторе, перед delete?
А для чего?

ну а обнуление висячего указателя - это просто полезная привычка

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

[Алексей1153]

перед delete

именно перед ним Про грабли я уже сказал, а ещё, бывает, люди переопределяют delete. Автоматизмом тут не пахнет

Ну а думать - это всегда пожалуйста, работа такая )) Но некоторые вещи отработаны до автоматизЬма - это экономит время и сокращает глюки (и колическтво разъярённых клиентов)

Поэтому, если так сильно хочется, можно и удалить "лишний код", но это бессмысленно - на быстродействии это не скажется всё равно

[BRE]

именно перед ним Про грабли я уже сказал, а ещё, бывает, люди переопределяют delete. Автоматизмом тут не пахнет

Именно перед ним эта проверка абсолютно бессмысленна.
Какие грабли?
А если люди переопределяют delete, то делают эту проверку первой. Как-то странно забыть ее сделать в delete и не забывать ее делать во всех остальных местах.

[Алексей1153]

Хорошо, пусть будет так:

    ~s_VectorPtr()
    {
#ifdef BRE
        delete m_p;
#else
        if(m_p)
        {
            delete m_p;
            m_p=0;
        }
#endif
    }