Thanks for your feedback.
I have identified that the problem is due to the EDBG chip (usb-serial bridge) which requires DTR signal to enable the serial port RXD and TXD pins.
Including the line of code "serial->setDataTerminalReady(true);" after opening the serial port, the serial port application is now working fine. I guess this is automatically carried out on hyper-terminal software and tera-term software.
Whether the communication uses the flow control or not,some of the hardware bridge requires the flow control signals to be set for the first time after power ON.
@raven-worx Yes, this is the code. I also did separate new code QNAM()->PUT(request,QFile*) & QNAM()->POST(request,QFile*) on my QT 5.4.1 setup. Everytime after executing the request application memory goes on increasing till it is equivalent to given file size(here I used 1GB file & memory increased by 1GB).
You're calling QDialog::exec which is for modal-only dialogs, and Qt::Popup isn't for dialogs, leave the window flags be. If you prepare a MWE (the download-and-build type) I can test on Linux (I have no Mac, sorry). Also you might consider filing a bug report if everything else fails.
difference between exec() and show(),
Only QDialog have exec() Qwidgets have show.
When you call show on a Dialog, it becomes visible but do not
wait for input.
MyDialog *dia=new MyDialog(this);
int a=0; // this code is run the moment dialog is shown on screen,
int a=0; // this code is run only after dialog is dismissed.
The version of dialog where u call show() could be called floating so when user click ok
it should emit signal that something should happen. ( to maiwindow )
The exec() version will report back the result ok/cancel/closed at once.
learn when to use QObject, QWidget, QFrame
QWidget is often used if making own widget. QFrame is used if you just need something to draw
a frame. If you use Designer you can check out the Widgets that are available.
QDialog is useful for any type of windows that pop ups up or open via a menu.
I have to set anything inside Register.
Yes, Register should be able to give the data back.
the widgets inside are private so you need a function to return the data.
You might also need to call http://doc.qt.io/qt-5/qdialog.html#accept
in your Register buttons clicked slot.
I am not sure whether WiFi Direct is among the supported APIs which can be co-used for classic apps. But usually you need to take care of a couple of things.
Most promintently you will need to link against runtimeobject.lib to find Activation symbols.
I just pushed a change for positioning to showcase, how a "generic" porting from WinRT to classic apps can work. See https://codereview.qt-project.org/#/c/159330/ for some details.
Please have some patience, this forum is community driven and not all users live in the same timezone as you.
The picture you are linking to doesn't show a hovered button but a checked button. You will have that visual effect if you set the checkable property of the action to corresponding to the button as true and you check it.
As far as I know, using Desktop widgets in ios is not an option.
QML is meant for mobile development and for application where the user interface is not the good old desktop program but more like apps as seen on phone and tablets. It gives far more control over the look and and function (out of the box) than using Widgets.
@JKSH there might be a slight difference in my case actually:
I'm not trying to embed a window from another application, but a HWND created by my own.
Does it makes a difference, or the problem is the same?
Same problems. By "external", I meant "not made by Qt Widgets".
The goal is to combine/use existing C++ libraries (photo/image processing) from other projects as part of the business layer in combination with databases.
Since you're going to write lots of C++ code, go with Widgets. Integration will be much easier.
What's with performance, future Qt development etc.?
Widgets have great performance for desktop-style GUIs. Qt Quick's performance shines when you want to do very fancy things like particle animations.
As for the future, Qt Quick is receiving lots of attention, but it cannot fully replace Qt Widgets yet. Widgets will be around for many years to come.
Is the "Widget-way" still actual for desktop or slowly dying?
It's not dying. :) (you'll hear some people say that it's dying because it's not receiving as much attention compared to Qt Quick, but you need to remember that Qt Widgets is a very mature product, that's why it doesn't need as much attention)