General and Desktop

you can manually create and send events using "sendEvent()":http://qt-project.org/doc/qt-4.8/qcoreapplication.html#sendEvent or "postEvent()":http://qt-project.org/doc/qt-4.8/qcoreapplication.html#postEvent alternatively, you could reimplement said events on your view and manually check whether the mouse has entered one of your invisible items, since afaik any item that is set to invisible won't receive any events.

[quote author="kevin_wmy" date="1336355175"]this code is copy from qt example [quote author="Soumitra" date="1335953992"]Hi, Kindly use the code formatter so that your code is readable. You can edit your post and add @ tags for the code. [/quote] [/quote] Yes, I was just saying about using the code formatter i.e @-tags around your code so that it can be readable. You can check your first post, the @-tags have been added by Volker. BTW did you get the solution ? Thanks :)

Try this: @QRgb nil=image.pixel(x,y); int r,g,b; r = qRed (nil); g = qGreen (nil); b = qBlue ( nil);@

Solved! Know why I couldn't find a bug in my painter code? There wasn't one. :/ What the problem was is that I had declared a large static array elsewhere - nothing even to do with this class - about 16 megabytes - and it would appear that this interacts with the amount of stack space the app gets. Got my clue by cross-compiling for Windows, and it crashed the same way, but it crashed so early -- before main -- that I knew it had to be something with size / static allocation. The Mac apparently has enough room to do what I wanted, but just barely, and still affects the total stack space. So, resolution, changed the static declaration to a calloc(etc,etc), and the problem went away immediately on both platforms -- the windows version runs fine, and the Mac version now draws text and does everything else, too. My supposition here is that Lion does more, goes deeper into the stack, than does Leopard and Snow Leopard, hence ran me out of whatever space had remained. One of the things I had noticed was that the call stack at the crash point was really deep, too, but I didn't catch the hint at the time, since it looked like it was where it ought to be... didn't occur to me that I'd made it dangerous to go there, though. Something to keep in mind: large static allocations, no good. [knocks self on head]

Well, you can't register classes having no public default constructor either ;-)

Apart from redesign issues: your code exits on line 7 (8 actually) because that is where your main() ends - so it should not surprise you. In Qt, we usually use "QApplication":http://qt-project.org/doc/qt-4.8/QApplication.html or "QCoreApplication":http://qt-project.org/doc/qt-4.8/qcoreapplication.html, esp. their exec() methods. Take a look at some examples to get to know how to use them, or look how Qt Creator auto-generates code there.

I'm not exactly sure what you mean, but QSet and QHash are "unordered" containers. (They don't retain a specific order of the elements. Instead they provide fast hash-based lookup)

[quote author="MuldeR" date="1336253569"] Sure that contains() is correct here? [/quote] ;-) Yes, I don't think this logic is reasonable. As I said above, I could not figure out what he want to achieve. but all he trying to implement is that. And we know that, If he using a QMap instead of two QList s, Code will be more reasonable and shorter.

My first thought about it was to change all the code related to the problem from QPixmap to QImage, but after several days studying the code, I realized that it would take several weeks of hard work to redefine the whole service (weeks that I don't have). Looking for an alternative solution, I decided to try this resource: http://en.wikipedia.org/wiki/Xvfb using these commands: % /usr/bin/Xvfb :0 -screen 0 1600x1200x24 & % export DISPLAY=localhost:0.0 % xhost localhost % /usr/bin/myservice & Additionally, I added a rule into my firewall to avoid external connections to the X11 port (6000). And that's it. The service is running and working pretty well :)

Thank you for your reply, stima_ua. It seems that my thread works now, but nevertheless my QGLWidgets "stops" in intervalls. So it seems that the general structure of my program might be wrong... :o( Is it generally possible to render multiple QGLWidgets simultaneously/in realtime? Or do I have to use multiple GL-contexts? Or should the Widgets itselfs run in different threads? Is it better to let the Widgets fetch the Images or to deliver them from a "ImageContoller", as I did?

[quote author="NameZero912" date="1336228968"]Thanks for the fast response. Well, in my case I'm connecting the slider's valueChanged(int) signal to the label's setNum() slot in the QtDesigner (consequently, the generated cpp files have this connect(...) statement), but then in my own code I also connect the slider's valueChanged(int) signal to my own slot (in which I take the new value and do something else with it). I was looking for a way to have both slots (my own, and labe's setNum()) to be triggered on start-up of the application.[/quote] This can be done, for example, by adding a suitable signal to your own class. Then you can connect the signal of your own class to the QLabel's signals. Qt can connect signals to signals! Then emitting your own signal will trigger the signal that it is connected to (e.g. the signal of the QLabel). The QLabel's signal in turn will trigger all slots connected to it - as you desire. Look at the code of my previous posting for an example... Of course you may simply call all slot's you want to trigger directly ;-) [quote author="NameZero912" date="1336228968"]From reading your code samples, it occurred to me that it's probably not a good approach to set the default value in the QtDesigner, trying to "push" this default value into the slots connected to slider's valueChanged(int). Instead I should simply have something that is not the default value in QtDesigner, and set the default value in code instead, i.e. @someSlider->setValue(initialValue);@[/quote] After all it may be desirable to "remember" the last value in an INI file and load it from there at the next application startup. If you do this, you will have to overwrite the value somewhere in your own initialization code anyway. Nonetheless you can keep the "initial" value from QDesigner with code like this: someLabel->setNum(someSlider->value()); someOtherSlotThatNeedsInitialization(someSlider->value()); someSlider->value() will initially contain the value you have set in QDesigner, given that setupUi() has been called.

bq. Veeraps wrote: I would suggest you to add dummy PARAM in the list (even if it is not used at the missing indices). Yes as of now I am filling all the parameters, even if it is not required...

Hi tim Thanks for the clarifications. I ended up overriding QStyledItemDelegate::editorEvent() and connect the appropriate 'value is edited' signal (signal name, as you also note, depends on the editor widget) with my startEdit() signal. This works nicely if the editor widget is a QLineEdit as this has a signal textEdited(const QString&). For all other widgets, my views notably also use comboboxes, startEdit() is already emitted when the editor is loaded with the current value, i.e., before the user actually has modified the value. Thus, in my application the close button of the dialog is disabled too early and the Cancel and the Save buttons are enabled too early (i.e., even if the user only attempts to edit but eventually decides to keep the value as is). Below my code in case someone has a similar need. (Ignore the paint function: my delegate does also something completely unrelated; it crosses out deleted items that are not yet committed to the model) Best Al_ header file @#ifndef QXCROSSOUTDELEGATE_H #define QXCROSSOUTDELEGATE_H #include <QStyledItemDelegate> class QXCrossoutDelegate : public QStyledItemDelegate{ Q_OBJECT public: explicit QXCrossoutDelegate(QObject parent = 0); virtual void paint (QPainter painter, const QStyleOptionViewItem& option, const QModelIndex& index ) const; virtual QWidget* createEditor(QWidget* parent, const QStyleOptionViewItem& option, const QModelIndex& index) const; signals: void startEdit() const;}; #endif // QXCROSSOUTDELEGATE_H@ implementation file @#include <QLineEdit> #include <QDateTimeEdit> #include <QDoubleSpinBox> #include <QSpinBox> #include <QComboBox> #include "qxcrossoutdelegate.h" QXCrossoutDelegate::QXCrossoutDelegate(QObject *parent) : QStyledItemDelegate(parent){} void QXCrossoutDelegate::paint(QPainter* painter, const QStyleOptionViewItem& option, const QModelIndex& index) const { QStyleOptionViewItem newOption(option); if (index.model()->headerData(index.row(), Qt::Vertical, Qt::DisplayRole).toString() == QLatin1String("!")) newOption.font.setStrikeOut(true); QStyledItemDelegate::paint(painter, newOption, index);} QWidget* QXCrossoutDelegate::createEditor(QWidget* parent, const QStyleOptionViewItem& option, const QModelIndex& index) const { QWidget* editorWidget = QStyledItemDelegate::createEditor(parent, option, index); bool ok(true); if (const QLineEdit* editorWidget_1 = qobject_cast<const QLineEdit*>(editorWidget)) ok = connect(editorWidget_1, SIGNAL(textEdited(const QString&)), this, SIGNAL(startEdit())); /* The following widgets have no signal emitted only upon user change of value. As setEditorData will be called even before the user actually modifies the value, we can as well emit startEdit() already now else if (const QDateTimeEdit* editorWidget_1 = qobject_cast<const QDateTimeEdit*>(editorWidget)) ok = connect(editorWidget_1, SIGNAL(dateTimeChanged(QDateTime)), this, SIGNAL(startEdit())); else if (const QDoubleSpinBox* editorWidget_1 = qobject_cast<const QDoubleSpinBox*>(editorWidget)) ok = connect(editorWidget_1, SIGNAL(valueChanged(double)), this, SIGNAL(startEdit())); else if (const QSpinBox* editorWidget_1 = qobject_cast<const QSpinBox*>(editorWidget)) ok = connect(editorWidget_1, SIGNAL(valueChanged(int)), this, SIGNAL(startEdit())); else if (const QComboBox* editorWidget_1 = qobject_cast<const QComboBox*>(editorWidget)) ok = connect(editorWidget_1, SIGNAL(currentIndexChanged(int)), this, SIGNAL(startEdit())); */ else emit startEdit(); // unknown editor widget, emit startEdit now: better too early than never Q_ASSERT(ok); return editorWidget;} @

If you want to make that pointer accessible by other classes of your project you need to either create a function in MainWindow that returns that pointer or to pass the pointer to the classes (by constructor using a setter function) that shall use it. This seems to be a reoccurring problem for beginners I guess. Take a look a this "thread":http://qt-project.org/forums/viewthread/16852/#84756 as the original poster struggles with the same problem only for a GLWindow instead of a QTcpSocket.

Hi Massinissa, Welcome to the forum. I'm not familiar with Itk, but there are some posts on this subject already: "Link to topics tagged with itk":http://qt-project.org/search/tag/itk You can find them easily by clicking on the itk tag on the right of your screen. Hope these help to get you going.

So after some tinkering and conferring with our UI designer, really what I want is to have a window with tabs, and to be able to rip any given tab out into its own window, and to later be able to drag that window over the tabbed window and have it rejoin as its own tab again. I've started tinkering with a QWidget that has a QTabBar and a QStackedWidget, and I'm going to see if I can programmatically switch an existing QWidget from being part of the stacked widget to being its own window (and back again). If that all works, then I'll see if I can get some sort of drag visuals to convey to the user what is happening as they drag the windows/tabs around. I'm just winging it here, and would love to hear from anyone who may have tried something similar.