qextserialport / qextserialport Goto Github PK

Hi,
I understand that the patch presented in issue #7 implements event driven
read in Linux. I use the latest cvs version on Kubuntu 9.10. 
How do I apply the patch? Which file do I patch? are there more recent
additions/modifications?

Thanks,

Muz

The (third) dwShareMode parameter of the winAPIs createfile call should be
zero when using Communications Resources, see
http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx in paragraph
'Communications Resources' in the last third of the article. The example
in http://msdn.microsoft.com/en-us/library/aa363201(VS.85).aspx shows the
same usage.

I don't know if this has a great affect nor if the msdn advice is even
misleading.

Hi..I'm new to Qt, but i need to communicate from serial port of my
PC(Windows XP).Can anyone suggest me what to do now. Which source code to
download and how to compile it(If any changes for Windows XP).I need a
great help its urgent for me. Plz kindly who has worked on this plz suggest
me. Thanks in advance.

I've added readyReady() support to the the POSIX implementation. It looks
like someone already took care of the Win32 side. Here is the patch. 

It's pretty simple. I just used a QSocketNotifier on the file descriptor
and a SIGNAL-SIGNAL connenction to proxy QSocketNotifier::activated(int) to
QextSerialPort::readRead()

--Justin Noel (ICS)

I use OSX 10.6.2
Downloaded project 20091223.
qmake to create qextserialport.xcodeproj
Build.
I get

Build libqextserialportd of project qextserialportd with configuration Debug

Ld build/Debug/libqextserialportd.dylib normal i386
cd /Users/bnilsson/Documents/Programming/Active/Qt/qextserialport-
mercurial/qextserialport-20091223
setenv MACOSX_DEPLOYMENT_TARGET 10.4
/Developer/usr/bin/g++-4.2 -arch i386 -dynamiclib -
L/Users/bnilsson/Documents/Programming/Active/Qt/qextserialport-mercurial/qextse
rialport-
20091223/build/Debug -L/Library/Frameworks -L/System/Library/Frameworks -
F/Users/bnilsson/Documents/Programming/Active/Qt/qextserialport-mercurial/qextse
rialport-
20091223/build/Debug -filelist 
/Users/bnilsson/Documents/Programming/Active/Qt/qextserialport-mercurial/qextser
ialport-
20091223/build/obj/qextserialportd.build/Debug/libqextserialportd.build/Objects-
normal/i386/libqextserialportd.LinkFileList -install_name 
/libqextserialportd.dylib -mmacosx-
version-min=10.4 -headerpad_max_install_names -single_module -dynamiclib -
L/Library/Frameworks -F/Library/Frameworks -framework IOKit -framework QtCore -
single_module -compatibility_version 1.2 -current_version 1.2.0 -o 
/Users/bnilsson/Documents/Programming/Active/Qt/qextserialport-mercurial/qextser
ialport-
20091223/build/Debug/libqextserialportd.dylib

Undefined symbols:
  "_CFStringGetCString", referenced from:
      QextSerialEnumerator::getServiceDetailsOSX(unsigned int, QextPortInfo*)in 
qextserialenumerator.o
      QextSerialEnumerator::getServiceDetailsOSX(unsigned int, QextPortInfo*)in 
qextserialenumerator.o
  "_CFNumberGetValue", referenced from:
      QextSerialEnumerator::getServiceDetailsOSX(unsigned int, QextPortInfo*)in 
qextserialenumerator.o
      QextSerialEnumerator::getServiceDetailsOSX(unsigned int, QextPortInfo*)in 
qextserialenumerator.o
  "_CFDictionarySetValue", referenced from:
      QextSerialEnumerator::setUpNotificationOSX()       in qextserialenumerator.o
  "_kCFAllocatorDefault", referenced from:
      _kCFAllocatorDefault$non_lazy_ptr in qextserialenumerator.o
  "_CFRunLoopGetCurrent", referenced from:
      QextSerialEnumerator::setUpNotificationOSX()       in qextserialenumerator.o
  "___CFConstantStringClassReference", referenced from:
      cfstring=IOCalloutDevice in qextserialenumerator.o
      cfstring=Product Name in qextserialenumerator.o
      cfstring=idVendor in qextserialenumerator.o
      cfstring=idProduct in qextserialenumerator.o
      cfstring=IOSerialStream in qextserialenumerator.o
      cfstring=IOSerialBSDClientType in qextserialenumerator.o
  "_CFDictionaryAddValue", referenced from:
      QextSerialEnumerator::scanPortsOSX(QList<QextPortInfo>&)         in qextserialenumerator.o
  "_kCFRunLoopDefaultMode", referenced from:
      _kCFRunLoopDefaultMode$non_lazy_ptr in qextserialenumerator.o
  "_CFRelease", referenced from:
      QextSerialEnumerator::getServiceDetailsOSX(unsigned int, QextPortInfo*)in 
qextserialenumerator.o
      QextSerialEnumerator::getServiceDetailsOSX(unsigned int, QextPortInfo*)in 
qextserialenumerator.o
      QextSerialEnumerator::getServiceDetailsOSX(unsigned int, QextPortInfo*)in 
qextserialenumerator.o
      QextSerialEnumerator::getServiceDetailsOSX(unsigned int, QextPortInfo*)in 
qextserialenumerator.o
  "_CFRetain", referenced from:
      QextSerialEnumerator::setUpNotificationOSX()       in qextserialenumerator.o
      QextSerialEnumerator::setUpNotificationOSX()       in qextserialenumerator.o
  "_CFRunLoopAddSource", referenced from:
      QextSerialEnumerator::setUpNotificationOSX()       in qextserialenumerator.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

Hello all,

I have made a little patch to the pro file to make it installable with a
simple make install. It installs only the libraries, and the headers. I
think the best way to deploy the help files is creating qch, and qhc files
from it. If you agree, I will do it.

Maybe a bit off topic, but I would recommend the following:

Include to the source an QextSerialPort and a QextSerialEnumerator file
which is the contains th convinent #include <???.h>.

Overloaded QextSerialPort constructors are providing two ambigious
function pairs:

1. QextSerialPort() and QextSerialPort(QueryMode mode = EventDriven)
2. QextSerialPort(const QString & name) / QextSerialPort(const QString &
name, QueryMode mode = EventDriven)

My way so solve this problem was to remove (comment out for this time) the
first ones respectively, because I think they are somhow redundant.

What steps will reproduce the problem?
1.Download the source from here
2.Compile the project tree.
3.

What is the expected output? 
Example application should link against the qextserialport DLL/lib.


What do you see instead?
Applications can't link with the DLL/lib


What version of the product are you using? 
I am not sure, the doxygen docs say 1.2 beta.

On what operating system?
Windows XP

Please provide any additional information below.
The reason for the above is a lack of exports, which I find very strange.
As a result, no DLL and lib files are generated.
They (the exports) must have been there before, otherwise it would not be
possible to link against the lib.
Attached is my own fix which works well.

(qint64)((DWORD)-1) != -1.

DWORD DWORD - unsigned - unsigned

http://msdn.microsoft.com/en-us/library/cc230318%28PROT.10%29.aspx

I have implemented the readAll() function because when I have tried to use
it on Linux, and blocked. According to the QIODevice documentation it
should not. 
Patch attached. 

Use: fresh checked out version.
Perform: qmake -tp vc in all required directories

The generated file qextserialportd.vcproj contains the lines

OutputFile="build\qextserialportd1.dll
OutputFile="build\qextserialport1.dll

The generated resource files *.rc contain the line

VALUE "OriginalFilename", "qextserialportd1.dll\0"
VALUE "OriginalFilename", "qextserialport1.dll\0"

Don't know, what strange behaviour shows Microsoft here. The problem: the 
automated build process will hang here on searching for the wrong libs 
(e.g. qextserialportd)

What steps will reproduce the problem?
1. I just scan for com ports:
    comboBox->clear();
    QList<QextPortInfo> ports = QextSerialEnumerator::getPorts();
    if (ports.size()!=0){
        pushButton_OpenPorts->setEnabled(TRUE);
        comboBox->setEnabled(TRUE);
        for (int i = 0; i < ports.size(); i++) {
            if (ports.at(i).portName.toLocal8Bit().contains("COM")){

comboBox->addItem(ports.at(i).portName.toLocal8Bit().constData(),0);
            }
       }
    } else {
        pushButton_OpenPorts->setEnabled(FALSE);
        comboBox->clear();
        comboBox->setEnabled(FALSE);
    }

2. Open the port with 
    if (comboBox->count()!=0){
        port = new QextSerialPort(comboBox->currentText());
        port->setBaudRate(BAUD9600);
        port->setFlowControl(FLOW_OFF);
        port->setDataBits(DATA_8);
        port->setParity(PAR_NONE);
        port->setStopBits(STOP_1);
        port->setTimeout(500);
        port->open(QIODevice::ReadWrite | QIODevice::Unbuffered);
        port->setBaudRate(BAUD9600);    // just do it twice
        port->setFlowControl(FLOW_OFF);
        port->setDataBits(DATA_8);
        port->setParity(PAR_NONE);
        port->setStopBits(STOP_1);
        port->setTimeout(500);

        if (port->isOpen()) { ....
3. and then close the port with
    port->close();

What is the expected output? What do you see instead?
Program seems not to get WindowsMessages properly and remains in the system
memory (and process context) after a system close(); - with the "old" win
1.2 version I don't see this "wrong" behavior. 

What version of the product are you using? On what operating system?
Latest hg version on WinXP 32 and 64

Please provide any additional information below.

What steps will reproduce the problem?
1. Clone the repository
2. Try to compile it under linux

What is the expected output? What do you see instead?
Lots of compilation issues.

What version of the product are you using? On what operating system?
Cloned the repository today. Ubuntu 9.04.

Please provide any additional information below.
I've fixed the compilation issues and attached the diff. Basically the
previous commit to the enumerator wasn't completed properly. Bad variable
names, ifdefs and includes (as seen in diff). 

I haven't actually looked at the logic of the code yet, if I encounter any
more issues while using this I will flag another issue. Will also include a
diff if I have fixed it.

First I compile the src.pro. I get some dynamic library. Then I tried to
compile the examples. But at the runtime I get: dyld: Library not loaded:
libqextserialportd.1.dylib.

When I link the src with CONFIG += staticlib it is the same issue.

The documentation for this project in terms of which signals are available
are very sparse. The code is also written such that it is hard to find what
you're looking for: the signals are not all listed in the header files but
emitted dynamically in the system-specific .cpp files as an example.

It would be nice if the documentation touched on the following in a clear
manner:
 - Signals and ports used
 - How threading is utilized by async I/O (do we need to create a separate
thread or is that handled automatically?)

I will try to attach a patch once I figure out some more things. If someone
can chip in with more information here I can write up a patch for it as I
would like to contribute.

I'm running Mac 10.6.2 and trying to enumerate serial devices on the system
with the enumerator example using the latest code from the site.

Running it I see the list of devices on my system: found_devices.txt

The friendly name is missing for the two bluetooth devices on the system.
But when I go to the System Profiler and look at all my network devices,
these two show up with names. The highlighted device is the one detected
correctly in serial_devices.png.

Questions:
Can I use qextserialport in a commercial product?
If yes, how?
Compile it in? I guess no.
If I can use it as a library, how should the README be formulated?
Is the "MIT license" from 2008 appropriate?

Bengt Nilson

I needed to convert the serial parameters into values that can be
stored in human readable form with QSettings, so I implemented
conversion methods to and from the parameter enums and would like so
see that code in the package.
At the same time I was unhappy to be forced to provide the platform
dependent interface name, and moved the already implemented code into
another method which constructs the port name from an interface/port
index. Here the device name templates for the several Unix flavours
need to be reviewed, as I'm not familiar enough with most of them.
Also the coding style may need adaption to the projects standards, if there
are any.

What steps will reproduce the problem?
1. execute a getChar()
2.
3.

What is the expected output? What do you see instead?
Expected behavior should be: block execution flow until a new char is 
received or a timeout is reached. 

What version of the product are you using? On what operating system?
1.2 beta

Please provide any additional information below.
typical expected output: "$GPGSA,A,1,02,,,,,,,,,,,,,,*1C"
actual output: "$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
$GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGPPPPPPPPP"

Hey all.

Is the event driven serial port i/f for qextserialport using interrupts to 
work? If not, how can you tell data has been received without polling?

I have a controller I'm trying to talk to and I seem to get multiple 
signals back for what I thought would qualify as one response from the 
device.

For instance a response looks like "0001 ABCD", but my function, which is 
connected to the serial port object's 'readyRead()' signal runs multiple 
times, indicating that readyRead() was emitted more than once. All my 
function does is print out what the response is and then prints out a new 
line.

So if my expected device response is "0001 ABCD", I get anything from
------------
0001 A\n
BCD
------------
------------
0001 ABC\n
D
------------
------------
0001 AB\n
CD
------------

... and so on, with every 'new line \n' being an instance where the 
function was called again. Is the device response just not continuous? I'd 
like to understand how EventDriven communication is implemented in 
QextSerialPort so I can understand exactly what is happening.

-Preet

Has anyone noticed that on the event driven example, every call to
port->write increases the process handle count by 1 or 2.
Could this be a memory leak?

Do a 

1. QIODevice * dev = new QExtSerialPort();
2. dev->bytesAvailable();

only the QIODevice's bytesAvailable will be called since QExtSerialPort:
    virtual qint64 bytesAvailable();
vs. QIODevice:
    virtual qint64 bytesAvailable() const;


Saw this in v1.0 with VisualC++ but should exist in other versions and 
with other compilers as well.

Regards, Ulrich

What steps will reproduce the problem?
1. Compile qextserialport-1.2win-alpha (from sourceforge) and
examples/enumerator
2. Compile the latest tree version (25.10.2009) and enumerator
3. compare running both

What is the expected output? What do you see instead?

I operate with many bluetooth devices that appear as serial port under windows.
qextserialport-1.2win-alpha lists me all these mapped devices.


Here is a console dump running enumerator of qextserialport-1.2:


List of ports:
port name: COM17
friendly name: Standard Serial over Bluetooth link (COM17)
physical name: \Device\BthModem7
enumerator name: BTHENUM
===================================

port name: COM18
friendly name: Standard Serial over Bluetooth link (COM18)
physical name: \Device\BthModem8
enumerator name: BTHENUM
===================================

port name: COM22
friendly name: Standard Serial over Bluetooth link (COM22)
physical name: \Device\BthModem9
enumerator name: BTHENUM
===================================

port name: COM25
friendly name: Standard Serial over Bluetooth link (COM25)
physical name: \Device\BthModem10
enumerator name: BTHENUM
===================================

port name: COM26
friendly name: Standard Serial over Bluetooth link (COM26)
physical name: \Device\BthModem6
enumerator name: BTHENUM
===================================

port name: COM28
friendly name: Standard Serial over Bluetooth link (COM28)
physical name: \Device\BthModem11


Running the same with the last tree version gives:
List of ports:

(and no ports are listed)

We have support now for event-driven (non-polling) notifications on Windows & 
OS X for device 
discovery / removal.  It would be great to determine how best to support this 
on the various *nix 
platforms.

If you have any experience with this, please chime in with what technology 
might work best and 
especially with any patches!

What steps will reproduce the problem?
1.List all the Supplied Ports on system.
QList<QextPortInfo> ports = QextSerialEnumerator::getPorts();

    QStringList strPortList;
    printf("List of ports:\n");
    for (int i = 0; i < ports.size(); i++) {

        strPortList << ports.at(i).portName.toLocal8Bit().constData();

        printf("port name: %s\n",
ports.at(i).portName.toLocal8Bit().constData());
        printf("friendly name: %s\n",
ports.at(i).friendName.toLocal8Bit().constData());
        printf("physical name: %s\n",
ports.at(i).physName.toLocal8Bit().constData());
        printf("enumerator name: %s\n",
ports.at(i).enumName.toLocal8Bit().constData());
        printf("===================================\n\n");
}

2. On first place i find the LPT1 Port.
(My PC has one LPT1 port)

What is the expected output? What do you see instead?
Expected: i will see only ComX ports. I see instea: My LPT1 port and all
ComX ports on my system.

What version of the product are you using? On what operating system?
Yestarday cheked out. Windows XP SP3.

Please provide any additional information below.
I have use 1.2 alpha before. allt works very well.
I found some changes, waht could produce the new behawiour.
In File qextserialenumerator_winn.cpp Line 34:
 DEFINE_GUID(GUID_DEVCLASS_PORTS, 0x4D36E978, 0xE325, 0x11CE, 0xBF, 0xC1,
0x08, 0x00, 0x2B, 0xE1, 0x03, 0x18 );
Should it be like in older revision, File Qextserialenumerator.cpp Line 16:
        DEFINE_GUID(GUID_CLASS_COMPORT, 0x86e0d1e0L, 0x8089, 0x11d0, 0x9c, 0xe4,
0x08, 0x00, 0x3e, 0x30, 0x1f, 0x73);
?

Here 
http://msdn.microsoft.com/en-us/library/ms791134.aspx
you can read:
"This class includes serial and parallel port devices. See also the
MultiportSerial class."
But we need only serialport, right?
Haw can we fix it?

Hi everybody,

Well i have been using the old qextserialpor that is in the SF site...

I just want to ask something: Why are you using a mutex in some function of
the Win_QextSerialPort class and in the  Win_QextSerialThread class that is
the thread that can access to variables that are critical it has no mutex?.
I see that the mutex for the _BytesToWrite variable is added but for the
rest variables no, e.g. Win_Handle.

One more thing, In the version that i am using(i know is old, but i have
made some changes), when i call the delete qextserialport object usually a
deadlock appear.

By the way Thanks for such as nice lib

I have implemented the following things:
- event driven mode for POSIX systems (tested on Linux only). 
- implemented the errorString() function.
- qextserialenumerator is working on Linux
- Created a small dialog which is useful for port selecting andd settings
modify. 

Well, i tried and tried, but there is no way to get it working... I mean
only about readyRead() signal, it does not work... Also the example, event,
doesnt work.

I'm running linux, ubuntu.

Hope anybody reads this and help me with this.

Thanks

There is another problem with the QextSerialPort() constructor and I'm not
sure if the QextSerialPort(const QString & name) constructor is also
affected:

At least one value, the _querymode value is left uninitialized, but used
in the open function, I think that never lead to a problem, because it is
just tested to be the second value of the QueryMode enum and probably
mostly is not, but I think this is a bug.

What steps will reproduce the problem?
This code:
#define _TTY_WIN_
#include <qextserialport.h>
int main()
{
    int test = 3 + 5;

  QextSerialPort mySP("COM3");

  return 0;
}

causes an immediate crash under vista on my machine. If I comment out the
"QextSerialPort mySP("COM3");" it all works. Interestingly, if I leave the
"QextSerialPort mySP("COM3");" line uncommented but set a breakpoint at the
"int test = 3+5" the debugger never reaches the breakpoint but rather
crashes as before.

What is the expected output? What do you see instead?
I would expect the program to not crash

What version of the product are you using? On what operating system?
latest qextserialportfrom hg on Vista on latest QT4.5.3 Note that problem
also occurs with the 1.1 version from sourceforge

Please provide any additional information below.
new user to qt so don't know how to show a trace or more information

What new feature(s) would you like to see included?

I am using a usb-to-serial multiplexer card and try to open the ports one
at a time. Due to driver issues, that is not always possible, and as such
may fail.

Is there a way to timeout the open method? The current behavior is that the
process is marked "uninterruptible" and eventually locks up the system. If
the device does not respond within due time (I don't know what would be
appropriate), couldn't the open just throw an exception and terminate?

On the Checkout version 20090616

# qmake created the qextserialportd.xcodeproj

Build produced the following:
Building target “libqextserialportd” of project “qextserialportd” with 
configuration “Debug” — (10 
errors)
......
/Users/bnilsson/Documents/Programming/Active/Qt/qextserialport-
mercurial/qextserialport/qextserialenumerator.h:66: error: expected class-name 
before '{' token

and more. This could be fixed by adding
#include <QObject> to qextserialportenumerator.h

Building again:
    /Users/bnilsson/Documents/Programming/Active/Qt/qextserialport-
mercurial/qextserialport/qextserialenumerator.cpp:552: error: 'win' was not 
declared in this 
scope

Commenting out (void)win; as below removed the last error.

void QextSerialEnumerator::setUpNotifications( )
{
#ifdef _TTY_WIN_
    setUpNotificationWin( );
#endif

#ifdef _TTY_POSIX_
#ifdef Q_OS_MAC
   // (void)win;
    setUpNotificationOSX( );
#else
    qCritical("Notifications for *Nix/FreeBSD are not implemented yet");
#endif // Q_OS_MAC
#endif // _TTY_POSIX_
}

Finally, It was necessary to add IOKit to the xcode project make it link.
If I changed the project to "static" this was not necessary.
I have built it as described above, tested it (only in my own polling app) and 
it seems to work.

Adding #include <QObject > to qextserialportenumerator.h did NOT make the 
Windows build to 
fail, using VS2008.

BN

What steps will reproduce the problem?
1. Use QextSerialPort in Event mode

What is the expected output? What do you see instead?
The expected dataReady() signal behavior is to emit one
signal on data arrival. Signal is emited continuously if
there is any data left in the buffer. QIODevice API documentation
explicitly prohibits this behavior.

What version of the product are you using? On what operating system?
Source snapshot. 18 Jan 2010. Debian GNU/Linux (Squeeze)

Please provide any additional information below.
There should be separate signal for signalling data in the buffer. Current
behavior breaks expected QIODevice behavior.

What steps will reproduce the problem?
1. Execute the following code (the last line is the important one, you can
change other settings as you want)
    QextSerialPort port = new QextSerialPort("/dev/ttyUSB0",
QextSerialPort::EventDriven);
    port->setBaudRate(BAUD115200);
    port->setFlowControl(FLOW_OFF);
    port->setParity(PAR_NONE);
    port->setDataBits(DATA_8);
    port->setStopBits(STOP_2);
    port->open(QIODevice::ReadWrite);
2. Watch as your program segfaults
3. ???
4. PROFIT!

What is the expected output? What do you see instead?
I expect my program to run and display an image constructed with serial
data. It works intermittently.

What version of the product are you using? On what operating system?
Latest hg on kubuntu 8.04 with Qt 4.4

Please provide any additional information below.
The library worked very nicely for a fairly long stretch of time, I don't
know if anything was different. I've unplugged and replugged my USB adapter
several times. Nothing was being transmitted when I started the program.
Backtrace:
#0  0xb74ce69d in QObject::thread () from /usr/lib/libQtCore.so.4
#1  0xb74da31f in QSocketNotifier::QSocketNotifier () from
/usr/lib/libQtCore.so.4
#2  0x0804f94a in QextSerialPort::open ()
#3  0x0804bac0 in cameraviewer (this=0x8093618) at cameraviewer.cpp:42
#4  0x0804c5cd in main (argc=1, argv=0xbfd81aa4) at main.cpp:29

Multiple issue, done with my patch, but I had found issue if configuration
under windows is done before open().

What steps will reproduce the problem?

- use a virtual COM port (attached is an USB device)
- call setUpNotifications() and connect deviceDiscovered and deviceRemoved 
to custom slots
- connect and disconnect the USB device


What is the expected output? What do you see instead?

- deviceDiscovered / deviceRemoved from QextSerialEnumerator should be 
triggered


What version of the product are you using? On what operating system?

- checked out version from 02/02/2010
- operating system is Windows Vista


Please provide any additional information below.

Have checked the method QextSerialEnumerator::onDeviceChangeWin. The 
parameter wParam isn't DBT_DEVICEARRIVAL nor DBT_DEVICEREMOVECOMPLETE, but 
instead was DBT_DEVNODES_CHANGED nevertheless of a connect or disconnect.
Can add a separate signal to notify, that something occured and reparse the  
ports everytime again, but maybe I'm missing something?

Use Windows Vista. Port is open, reads data (event driven) from the device. 
If I disconnect / connect the device again, I have no chance to get the port 
working again, nevertheless I close the port, create a new port or something 
else.

Working under Windows Vista. Sometimes the port opens normally, but doesn't 
read data, until another program opens the port too, closes it afterwards. A 
new program start, and the port is running is required. One strange behaviour 
in this context: The port doesn't read any data, but it seems to accept data, 
because when I open the other program like mentioned, I get some answers from 
the connected device, which were requested from my own program before!?

What steps will reproduce the problem?
1. download the ef4af2a2ee revision that introduced the 
qextserialport_global.h file
2. change to static compilation
3. the examples do not compile
4. if QEXTSERIALPORT_EXPORT is removed from the headers, then everything is 
fine

I have added the the error reporting of the missing serial port file on
Posix systems. Patch attached.

What is the status of lastError()?
I always get E_NO_ERROR even if the line s disconnected, timeout, etc., same on 
Mac or 
Windows. On Windows I have regular COM ports, on Mac I have a UC-232A serial 
converter.

I use do like this:
void 
SerialPort::PortWrite(char *message)
{
    port->write(message,3);
    lasterror = port->lastError();

}

char
SerialPort::PortRead(char *Buffer)
{
    int BytesRead = 0;
    char buf[128]="";
    Buffer[0] = Buffer[1] = NULL;
    buf[0] = buf[1] = NULL;
    do
    {
        BytesRead = port->read(buf,1);
        lasterror = port->lastError();
        if(BytesRead) {
            if(buf[0] == 0x0a) break;
            else if(buf[0] != 0x0d) strcat(Buffer, buf);
        }
    }while(BytesRead > 0);
    return *Buffer;
}

Right or wrong?

Hi everybody i have been looking on the actual code, and i try to compile
and i saw that the strcut are define twice in the qextserialbase.h and in
the qextserialport.h have anybody else notice about this. 


I try to checkout the repo but is timing out, so i copy and paste from
browse source the code for each file.

We don't have a good way to extract device details on *nix platforms, such as 
vendor/product ID, 
manufacturer name, product name etc.  So even if we use some of the hack-ish 
ways to determine 
whether there are connected devices in /dev we never know much about them 
before opening them 
up and seeing if they respond to a particular protocol.  

If anybody has any suggestions on how to obtain device specific details like 
this, please chime in!

What steps will reproduce the problem?
1. Install the latest Qt version, got local copy qextserialport.
2. Try to build qextserialport project, I had a few errors like:
   collect2: ld returned 1 exit status
   since:
   real library names: qextserialport1.dll & qextserialportd1.dll
   expected library names: qextserialport.dll & qextserialportd.dll
   so I have changed library names to real in event.pro & enumerator.pro
3. After that please try to run any example (for example - 'event'). 
   I have exit code -1073741515  immediately after run (no output in cmd.exe)

WBR, Anton

What steps will reproduce the problem?
1. Linking against the library
2.
3.

What is the expected output?
Being able to write to the serial device

What do you see instead?
With Polling:
in QextSerialPort::writeData():
WriteFile() returns 'true' (success) after several seconds, but 0 bytes
have been written.
The buffer is legal, and is 35 bytes long.

With EventDriven:
the execution goes in to the "ERROR_IO_PENDING" section, which is ok,
exists the function, and thats it.
No events are being caught (or sent) to the onWinEvent() method.

What version of the product are you using? 
The hg change set number is 105.

On what operating system?
Windows 7


Please provide any additional information below.
Hardware two various USB-Serail converters.
They both work with other software, so its not a hardware/driver issue.

A good way to test (also for other issues) would be if you supplied a test
program that also does writing.

What new feature(s) would you like to see included?
I would much appreciate a function that blocks execution until a new char 
is received.

the idea is:

read thread::
for(;;){
...
do {
  qextserialport->read(&charBuffer);
  myBuffer[index] = charBuffer;
  index++;
} while (charBuffer != '\n');
send(myBuffer);
...
}

this would send a string finished with a '\n'

I think we need some improvement for addressing this case:

CreateFile("\\\\.\\COM10",...)

What steps will reproduce the problem?
1. use lastError() method in my code
2. Compile& Build

What is the expected output? What do you see instead?
Successful build expected.
lastError not found during link

What version of the product are you using? On what operating system?
1.2.0
MacOSX 10.6.2

Please provide any additional information below.

Looking in the code, I see no implementation of the method lastError();
It is in the headers under section public, so it compiles but it does not link.
It's been a while since I updated to latest version, but it did work before.
Having said that, I am not sure how well it WORKED on Mac, but it did build.

BN

We have some devices that use a USB serial port driver.  The driver inf is
attached.  When you plug the device in, it shows up under Ports in the
Device Manager (something like Communications Port (COM3)).

However, this port will not appear when using
QextSerialEnumerator::getPorts().  The list contains only the fixed COM
ports on the computer.  

What steps will reproduce the problem?
1.  Connect device using attached driver (custom hardware) 
2.  Verify that the port shows up in Device Manager
3.  Call getPorts(). 

What is the expected output? What do you see instead?
The port should be listed, it is not.


What version of the product are you using? On what operating system?
Subversion from mid-July 2009.  Windows XP SP3.

I think Q_OS_* definitions are enough to seperate codes for platforms. So why 
do we need these definitions? Also with these, main project needs these 
definitions.

I've created a patch for this issue. It's attached. It also contains a basic 
device enumeration code for Linux.