Fix the waitForReadyRead() behavior on Windows

It is necessary to compare size of the readBuffer before and after
completion of each read operation. If size of readBuffer are equal
it means that are no more data available for reading. In this case
the method should returns true if an initial size of readBuffer is
not equal to the current size of readBuffer. Otherwise in all other
cases should be continue waiting until timeout has been expired.

Also must not to do check for the NoError code and to hope for valid
value of this code inside waitForReadyRead(). Because a last error
code do not clears automatically. It lead to false returns of this
method in case the error number is not equal to NoError (for example
it error remained after failed of any previous method). This check
should be implemented in a different way in case of need. But at
present this check is unnecessary because result of the waitAnyEvent()
cover it.

Task-number: QTBUG-33987
Change-Id: Ic8d8e3806fd4863c2720ffb83d5c19eae54d57f0
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Laszlo Papp <lpapp@kde.org>
Fix the broken handle() documentation

This is likely to be happening due to the mismatching function signature include
the return type between the header and source file. Two things are being fixed:

1) Dropped scope for the Handle just like with the winId case in QWidget.

2) "const" qualifier is now added for the method.

Here you can see the documentation that it is empty:
http://qt-project.org/doc/qt-5/qserialport.html#handle

Change-Id: I5e9e0732cfd746a863de523fe90e58eafa42c081
Reviewed-by: Alex Henrie <alexhenrie24@gmail.com>
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Martin Smith <martin.smith@digia.com>
Fix the creaderasync example name in the qdoc file

This change eliminates the following warnings when using "make docs":

/home/lpapp/Projects/qt/qt5/qtserialport/examples/serialport/doc/creaderasync.qdoc:28:
warning: Cannot find file 'creader/creader.pro' or 'creader/creader.qmlproject'

/home/lpapp/Projects/qt/qt5/qtserialport/examples/serialport/doc/creaderasync.qdoc:28:
warning:   EXAMPLE PATH DOES NOT EXIST: creader

It is also visible that the example is unreachable on the following
documentation page:

http://qt-project.org/doc/qt-5/examples.html

Change-Id: I09f1532fcff6b1f7bfc5c4857bd14252aceb2eb3
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Refactor the reference in the documentation for property setters/getters

The documentation contains broken links due to this, and it is also inconsistent
with the rest. Properties should be referred to as properties, not individual
methods like setter, getter, notified signal, etc.

The change is tested with "make docs" and the broken links are history.

Change-Id: Id94cba1f88503754318c865793229e3d3947bec6
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
Reviewed-by: Martin Smith <martin.smith@digia.com>
Obsolete the TxD/RxD signals

They are not much of use due to the low-level OS limitations as of now, hence
the obsolete proposal. It can be brought back to life at any point when we have
a more clear idea what to do with this API.

"faking" this signal as RealTterm probably does it, is not a nice impression
for the end users. That would be more like a software "signal" (which we
already have in place) rather than a real pinout hardware signal.

It is interesting why Windows, Linux, etc do not provide an option for this.
There must be some strong reason for it.

Change-Id: Ia065e2ee9226d16e724f5e2690b25b954329d78e
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Fix some typos in documentation.

Fix some spelling and grammatical errors in comments that show up in Qt documentation. No changes to code.

Change-Id: I185458e162d115eac25326d239b851b5e14ed5cf
Reviewed-by: Laszlo Papp <lpapp@kde.org>
Handle the ERROR_INVALID_NAME error code

If the user tries to open the serial port with empty
port name, Windows returns this error code.

The error will be exposed as
QSerialPort::DeviceNotFoundError from now.

Tested only on Windows 8 (32 bit) with on-board serial
port as well as an usb dongle (PL2303) using Qt4 and Qt5.

Change-Id: I9a56a7e51dbdab684b6d2a9fdf6398d8d5018e1c
Reviewed-by: Laszlo Papp <lpapp@kde.org>
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Optimize of writing sequence algorithm

* The writeSequenceStarted shall be set to true after a successful call
of WriteFile() and to be dropped to false in case of write completion.

* The method startAsyncWrite() shall not call WriteFile() if the
writeBuffer is empty or writing sequence is already started. Also now
there is no sense to check a validity of pointers on data in writeBuffer
before call of WriteFile() because writeBuffer can not be empty.

* It is also expedient to free the writeBuffer in _q_completeAsyncWrite()
method only if numberOfBytesTransferred is not zero.

Tested on Windows 8 with the on-board and the USB (PL2303) serial ports.

Change-Id: Ib70276705fcc3f2396bf7dd6cf6977b62382a64b
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Rewrite the short description of the handle() method

* handle() is duplicated since the description explains that method.

* It is pointless to put the "object" into the sentence.

* It is consistent to start the sentence with the "if".

Here goes a typical example that is worth following with consistency:

"If successful, returns true; otherwise returns false."

Change-Id: I1c7648237c75381b8452b8c47a59445fff58ad34
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Add listing of virtual ports from the "AGG Software"

The current algorithm takes a name of the serial port from
the PortName property which is in the Registry. This value is
filled out by the Ports class installer automatically:

http://msdn.microsoft.com/en-us/library/windows/hardware/ff546514%28v=vs.85%29.aspx

But at using the "AGG Software" software this property is
absent. Therefore the algorithm ignores these serial ports.

The simplest workaround is use of the PortNumber property
which identifies a port number for this software. In this
case a port name defines indirectly, by adding a port number
to the "COM" suffix.

This does not influence other serial ports which are defined
through PortName property.

Tested on Windows XP and Windows 8 with the cenumerator example.

Task-number: QTBUG-32774
Change-Id: I8cda3ed992ff80742511a2952d3fb7e8ac6edc81
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Use the ternary operator meant for this purpose rather than two returns

Change-Id: Ie6b17d95b83ad751130305a6d44cdead3cd46da6
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Add enumeration through the SERIALCOMM registry entry

When using some software that provide an virtual serial
ports functionality is impossible to use the Win32 SetupAPI
feature to enumerate these serial ports.

For example, such software is "Virtual Serial Ports Emulator"
from Eterlogic: http://www.eterlogic.com/Products.VSPE.html

The only possible simple way to detect these serial ports
it to read the registry key HARDWARE\\DEVICEMAP\\SERIALCOMM:

http://msdn.microsoft.com/en-us/library/windows/hardware/ff546502%28v=vs.85%29.aspx

In this case it is possible to get only a name of the serial
port without any additional information.

This method is simply addition to the main SetupAPI functionality.

Task-number: QTBUG-36526
Change-Id: Ib505aee66b74b6a8ebe16cf88c3060c8267397a0
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Add error handling to some missing functions

Change-Id: If8dee1819d493fa4b27eba99de611c61bfdfe7a3
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Remove the unused SystemIn/OutputQueue size methods

Change-Id: Iafab6ccc376da7a856b409017bbc42c36c016253
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Rename the "descriptor" to handle on Windows

* Windows uses the term handle instead of descriptor.

* It is also consistent with the rest how Qt manages it.

Conflicts:
	src/serialport/qserialport_win.cpp

Change-Id: I68a672ea2d8e88e26ad5d822b157ccab79a3d2d9
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Rename the writeSequenceStarted variable to writeStarted

Conflicts:
	src/serialport/qserialport_win.cpp

Change-Id: I786879a485e78e3637d8cb474f86e3bd406bd237
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Initialize the DCB structure before using it

Please refer to the MSDN documentation for details:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa363214%28v=vs.85%29.aspx

and

http://msdn.microsoft.com/en-us/library/windows/desktop/aa363201%28v=vs.85%29.aspx

Change-Id: Id60f6d1b4a9237c2ae74063ac52221f42761b004
Reviewed-by: Laszlo Papp <lpapp@kde.org>
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Keep the DTR line state at changing of DCB properties

Updating of the DCB structure (in case of setup of some
properties through setXX() methods) leads to reset of a
status of the DTR line to an initial state.

For example, after opening of port the DTR state was "high",
further the call of method setDataTerminalReady(false)
will drop the DTR to "low" state. But if now to change any
properties of the device (e.g. to setup a new baud rate),
the DTR will again be set to "high".

The reason of this behavior is the fDtrControl flag of
DCB structure:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363214%28v=vs.85%29.aspx

To control of DTR is used the EscapeCommFunction() function
which has no relation to the DCB structure. Therefore any
re-initialization of the DCB discard the results of the
EscapeCommFunction() function in case a state of the
fDtrControl flag not equal to the real DTR state.

Solution is change of a fDtrControl flag after successfully
call of the EscapeCommFunction() function. Then further change
of any property will be with a correct DCB.

Besides, it is necessary to drop the flag DTR_CONTROL_HANDSHAKE
at opening of device. Because in this mode the manual control
of the DTR line is forbidden.

Thanks to Dr. Alexander W. Lenhardt
Task-number: QTBUG-36490

Change-Id: I14b040761f7e28108db87e667eb76f559be436cb
Reviewed-by: Sergey Belyashov <Sergey.Belyashov@gmail.com>
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Merge remote-tracking branch 'origin/release' into stable

Conflicts:
	src/serialport/qserialport_win.cpp

Change-Id: Ib00a645c6660a3c81dbc9e159110f7bfc392ea36
Don't use cfmakeraw on SunOS

The cfmakeraw() function is an extension to POSIX and thus not fully
portable. It doesn't exist on Solaris and Illumos.
Source: http://www.perkin.org.uk/posts/solaris-portability-cfmakeraw.html

Change-Id: Icf514fe32c01e85baff2a0d49321e45a320703b7
Reviewed-by: Laszlo Papp <lpapp@kde.org>