General and Desktop

I'm using the latest PySide2 package available through pip: https://pypi.org/project/PySide2 which is currently PySide2 5.15.2.

@JonB, later after a break, I'll try with a global QSqlQuery* again and will try to use that in other view, where I've used QSqlQueryModel testModel (in previous post), to execute multiple statements AND instead of db.isOpen(), I'll use my global isConnected to see whether it crashes with that or not.

@Maluna34 I don't see why you/one would use inheritance between your pages. Not doing so would avoid the issue.

That's great, thanks for the response. Yes, it looks like QGraphicsScene is the way to go- I'll have a look.

@jsulm & @J-Hilk Thank you so much. You´re my Heroes :D Everyday something new to learn :)

Thanks Guys.. helped me out alot :D

@Publicnamer said in Does Qt not have a switch widgets?: I'm trying to avoid adding layers of bloat You don't have to add it, but you can check how they implemented this control...

@SGaist can you help me? Thanks very much!

No idea how it's fixed automatically! In the original posit I'd this if(model->lastError().type() != QSqlError::NoError) instead of ... testModel.lastError().type() ... and emit ... QString::number(model->rowCount()) + " row(s)"); due to copy/paste BUT those were changed long before and the private model/QTableView on the right pane kept getting cleared even after correction! After a break, I just hit Ctrl+R and executed same set of statements and the private model/QTableView doesn't get cleared anymore even if I have those copy/paste errors in my code.

To decrease the size of QCalendarWidget you have to find the QTableView inside QCalendarWidget and then set the headers size to zero (or any size you want). You can also set the font size to a small (but visible) value. In the following code cal is a pointer to QCalendarWidget QTableView* calendarView = 0; for(auto i : qAsConst(cal->children())) { calendarView = dynamic_cast<QTableView*>(i); if(calendarView) { qDebug() << "View Found"; QHeaderView* hh = calendarView->horizontalHeader(); QHeaderView* vh = calendarView->verticalHeader(); QFont font = calendarView->font(); font.setPointSize(8); calendarView->setFont(font); hh->setMinimumSectionSize(0); vh->setMinimumSectionSize(0); } }

[image: c0670d4c-398a-4e4c-98ed-7d1cd88a046e.png] This is the main part of my code. I want to use drawline in Qpainter to draw the semi-transparent line, but it does not give me the correct effect.

I guess the problem is that rather than putting the Qt6 include locations first (specified by Qt Creator), it puts the Qt5 ones first (specified by a separate include folder of vcpkg that also has QtCore(qt5) as well as the library I actually want to include (zeromq). This is causing Qmake to find the Qt5 files first on things that are not included in the .pro file. By that I mean things like QtGui and Qt Widgets end up coming from Qt6, and other things inluded by QtWidgets end up coming from the Qt5 (obviously not desired). This is fixed if I manually change the order of INCPATH in the makefile.debug. If QMake instead put it's own includes first, or at least in the order they appear in the .pro file, then there would not be a problem. Does this make sense? As it is now, it appears that QMake put's things like the include directory for QtCore (-IC:\Qt\6.2.1\msvc2019_64\include\QtCore in my case) at the END of the includes, even if I explicitly include it at the beginning of my .pro file.

It's doesn't change the fact that you need an iOS build of Qt.

Thanks, you actually helped me resolve the issue. I created a signal/slot when the tab is selected which now shows the view. At that point I get the coordinates and they show properly.

It depends on the performance you are after but I would say it's likely the better approach.

Hi, The simplest is to do it in two steps: Qt 3 to 4 porting which may or may not massive depending on your use of qt3support. Qt 4 to 5 porting which should be way simpler especially if you take proper time to not use any feature deprecated in Qt 5.

@mchinand, in this case it'll be complicated. 2 separate main views (widgets in the stacked widget) rely on that signal. In between child widgets inside QueryWidget, that's ok. TableWidget, which is not a child of QueryWidget, also relies on this signal and in the MainWindow, I instantiate QueryWidget and TableWidget. In this case, I either have to make the child widget of the QueryWidget, that emits the signal, public (or can make it more complex by creating a getter) or create another signal in QueryWidget to connect to the slot of TableWidget. So, to me, the best approach is to make a signal in QueryWidget and let it be used by every other widgets that needs it, be it child or sibling.