General and Desktop

@MyNameIsQt var i = 0; window.addEventListener('resize', function(){ //++i; drawCanvas(++i); }); [image: 209e53c6-b290-46a4-aac5-a26bec773de0.JPG] As shown in the picture below, the function called within the js file works exactly. However, when the drawCanvas function is called from cpp, the 'canvas' screen is not updated even if the correct data value is passed.

To solve this problem do sudo apt-get install libmd4c* Full code here.

@jeremy_k Thanks for super()...It's been a while since I've had to program and had not considered that the super needed to be called as a function. That solved my hanging problem. keyboard events are not an issue now since I can properly trap the right-click now with mouseReleaseEvent()

@g1ennr What is actually in your .../Qt/5.15.2/mingw_64/bin/qt.conf?

@clarify Sorry, don't see how that has anything to do with a QDate. A QDate is "defined" as a date with no time of day. If you want to deal with a datetime, use a QDateTime.

@JoeCFD You can see it in the code source directly as well as the CMakeLists.txt files of the module.

The style always wins as written here: https://doc.qt.io/qt-6/stylesheet.html#overview "Style sheets are applied on top of the current widget style,"

Working on same course, had same mac issue. Note: "quit" is not visible - by design - on a Mac. After a lot of searching, here is fix that works on both Linux and Mac: ``` // declare actions from .h act_quit = new QAction("quit"); act_stop = new QAction("Stop"); // connect actions QObject::connect(act_quit,&QAction::triggered,this, [=](){QApplication::quit(); }); QObject::connect(act_stop,&QAction::triggered,this, [=](){QApplication::quit(); }); // add menus QMenu *filemenu = menuBar()->addMenu("File"); filemenu->addAction(act_quit); filemenu->addAction(act_stop); QMenu *mnu_other = menuBar()->addMenu("Other"); mnu_other->addAction(act_quit); mnu_other->addAction(act_stop); QMenu *mnu_three = menuBar()->addMenu("hello"); mnu_three->addAction(act_quit); mnu_three->addAction(act_stop);

@ChrisW67 I could also switch to MINGW instead. I 'd rather not use an older Microsoft dev kit.

@Christian-Ehrlicher I was gonna use them in a language switching mechanism, where I provided several QTranslators to that would then have been installed dynamically if they matched the desired language. Never mind, I will prime the translators with a prebuilt set of qm files, that give them the initial language and then adding my testing strings separately. Those test qm files do not need to contain the actual strings. The language information is sufficient. My language switcher can then determine the language from that and still use the custom translate method.

Hi, just a guess but maybe you need to enable the aarch64 architecture if you're crosscompiling, something like this: sudo dpkg --add-architecture arm64 sudo apt install libc6:arm64

@micha_eleric I had not noticed, but as @J-Hilk has said 400,000,000 is a lot of items to draw ;-) Not to mention, this is a lot for the user to look at/I'm not sure there are even that many pixels on the screen! But I guess you will see this is just a test. If you have a "lot" of add/move/delete operations to perform, you must either (a) do the operations in batches on a timer from a "queue" (at least conceptually), presumably from the UI thread, so that the UI has time to render them and remains responsive, or (b) if @SimonSchroeder's principle of "double-buffering"/mutexing works from a thread you would have to release the mutex periodically after batches performed so that the UI thread gets some time to process the updates without blocking on a mutex for too long.

@mdrost And a DirectConnection is by definition always blocking.

@Christian-Ehrlicher the user will not see well the button because they will have the finger on top of it blocking visibility.

Thank you all. I think ill be able to achieve this now. Also thanks for the suggestion I will dig deeper into that stuff.