General and Desktop

@Pl45m4 Thx, fixed :)

As stated above, if you are using designer correctly (and to a larger extend OOP) then you can make your changes in designer and update the class that you use to encapsulate the interface in. You should be either subclassing the generated UI class or instantiating it and using ui.setupUi(self) in another qwidget derived class.

@drmhkelley You can't know for sure, unless you write perfect code in the first place. Depends on the code and what the messages are. Find the message text, track it down.

@bogong I'm a slow typer I guess :) Good for you.

@magicstar said in How to play Gif with QToolTip: How to use QMovie with QToolTip? You can't. You have to do it on your own with window flag Qt::Tool

So the main window is blocked. Hold on a sec. Lets be clear here. Local event loop started by exec() does not block event processing in main window or any other parts of your app. Main window can't get focus, but that's because you set your dialog to be modal, not because of a local event loop. All events are processed as usual, no matter how deep on an event loop stack you are. It's just that you don't leave the scope the loop is running in. The way I see this is that if for example I would like to open 2 or more dialogs at the same time, I should find another way to show them by not blocking the main loop. Just use show() in that case, like you did. Just don't use a smart pointer on it so it doesn't delete your instances when you leave the scope. I guess if I want to use the app in this way, I should just declare the pointer to ConvertDialog as member variable and get done with it. If you need to have some sort of access to your dialog when it's shown then that's one way to do it, but if it's a standalone thing you don't need to keep any pointer to it. You can use the Qt::WA_DeleteOnClose attribute I mentioned so it deletes itself when it's closed or you can manually call deleteLater() in its close event handler. I mean how bloated can we allow a class to become? There's simply no one answer to that. From technical standpoint you can stuff your class as much as fits in the memory. A pointer or two is not a lot when you think how much RAM a random computer has. You could have no classes at all for all CPU cares. It's all just bytes and addresses to it anyway. The other consideration though is readability and maintainability of your code. Smaller classes compose better and are easier to understand, refactor and maintain. Things like dialogs or message boxes are temporary in nature so it's a bit silly to keep a pointer to one around when most of the time it's null, but sometimes it's just the most convenient thing to do. All in all it's the beautiful dance of balancing those different concerns we programmers deal with every day :)

@mrjj Ohhhh yes! Thank you man!!! Now console window opens! Thank you!

@Christian-Ehrlicher Ho thanks I will try this widget. It look like is what I need at firt sight.

I use the boost::intrusive_ptr because the VC com smart pointer CComPtr ist not available in mingw (at least I did not find a header, but maybe missed it) and a sort of smart pointer seems to be needed with com. I choose intrusive_ptr because COM already counts the references internally. Here you will find some explanation: https://dieboostcppbibliotheken.de/boost.smartpointers-spezielle-smartpointer -> it is german, but maybe you can translate it. Do you know where I can find CComPtr in mingw? //----------------------------------------------------------------- Here is my workaround/solution for the initial topic (The skipped event interface) for others who have this problem. I recognized that I can connect a generic signal handler to the com component (QAxObject) which contains the skipped event interface and can catch the events there. Something like this: connect( m_qaxobject, SIGNAL(signal(const QString&, int, void*)), this, SLOT(eventSink(const QString&, int, void*)) ); void AClass::eventSink( const QString & name, int argc, void * argv ) { // See what events fired qDebug() << "Event: " << name << "argc:" << argc; if( name == "EventInterfaceEvent()" ) { ... } } I have another issue with the wrapper which the dumpp utility created, therefore I will open another topic.

@Christian-Ehrlicher said in How to access variable from one slot to another slot: You already explain why it does not work. You assign the pointer to a temporary which is not available later on. Ahh I got it. Thanks alot.

I don't know dbeaver but since it looks like it can open all kinds of databases it should also have a plugin for sqlcipher

@Ebrahim-Karimi Hi Yes, that is the normal way. Also so the Widget is owned and handled by the QListWidget like its items. I understand your rationale for then combining them into one class but if you then reuse the Widgets in another context, they are also half a QListWidgetItem and if you later wanted to use the View version of the List widget with a custom model, then the QListWidgetItem part is also not needed. Overall, in OOP we use inheritance when we have something we can say "is a" and i think what i find odd with it - is that we say the QListWidgetItem is now a QWidget which means it can no longer be copied and radically changed the expected contract of items. Like you could new a MyObjectWidget and place it on a form. But I dont think any part of Qt, include proxies will try to copy QListWidgetItems, so I dont think it will come back and haunt you :) So my comment was more out of o.O surprise of such a combination than out of fear or experience - that it will burn💥 later.

No, you are mixing Qt Creator and Qt itself again. These are two different things. Qt Creator is an IDE built with Qt. This is the list of plugins of Qt Creator. AFAIK, because it's mandatory for Qt Creator to work.

@Chris-Kawa said in Correct mode to draw UI: The last line is too long because you've set a 2 column span on the horizontal layout, Just remove it: Layout->addLayout(hl1, 3, 1); Yes, this solution works fine :) As for the widths - I don't know what SetWidgetWidth is, but you can remove it and just set some stretch factors, for example: hl1->setStretchFactor(leZip, 1); hl1->setStretchFactor(leCity, 10); hl1->setStretchFactor(leProv, 1); The 1,10,1 ratio is just an example. You can set it to be whatever you want. Alternatively you can fix the size of the side line edits and set the central one to expanding: SetWidgetWidth estimate width of widget about max string lenght. This is the function: void GenericDialog::SetWidgetWidth(QLineEdit *LineEdit, uint16_t len) { QString StrLen; for(uint16_t s = 0; s <= len; s++) StrLen += 48+s; QFontMetrics fm(LineEdit->fontMetrics()); LineEdit->setMinimumWidth(fm.horizontalAdvance(StrLen)); } I tried to use setStretchFactor, but leZip and leProv still too large. If I increase width of window, leZip, leCity and leProv increase his width in equal measure. leZip->setSizePolicy(QSizePolicy::Fixed, QSizePolicy::Fixed); leCity->setSizePolicy(QSizePolicy::Expanding, QSizePolicy::Fixed); leProv->setSizePolicy(QSizePolicy::Fixed, QSizePolicy::Fixed); With setSizePolicy (that I had already tried) leZip and leProv continue to still too large. It seems that under this measure they cannot be set. Also, just a side note: just as all indexing in C++, row numbers start at 0. You added widgets to rows 1, 2 and 3, so you have an empty row at the top of the layout. Yes, you are right, but the posted code is a small part of a larger function with other controls above.

Sorry, I haven't had any trouble building it here. macOS is 10.13.6 with Xcode 10 as well. Note that if you get the designer plugin, it means that the qwt.framework was created otherwise the plugin can be linked.

It was just a general statement. It happens from time to time that people try to use the proxy model as a standard model. This is indeed not your case :-) Sorry for the confusion !