port enumerator soes not get the portName if called with user rights

[GoogleCodeExporter]

What steps will reproduce the problem?
Using the qextserialportenumerator::getPorts() function in a program started 
with user rights.

What is the expected output? What do you see instead?
The expected output of PortInfo.portName is a name like COM1.
Instead it is empty and no error message is generated.

What version of the product are you using? On what operating system?
I am using the last repository version and tested it with an older, probably a 
half year old, one.
It was introduced on my platform (Windows XP Pro SP3) with one of the updates 
installed during the last half year.
For now I could not find any hints on the internet about this issue, but that 
is an intermittent problem.

Please provide any additional information below.
I'm not sure how to handle this, because the function QString 
QextSerialEnumerator::getRegKeyValue(HKEY key, LPCTSTR property) in file 
qextserialenumerator.cpp does not allow any error handling with return values.

It would be good to have some solution, because the user does not get any 
message or hint, he just cannot open any port. My workaround is extracting the 
name out of the friendly name as it contains the portName in paranthesis.

Original issue reported on code.google.com by ulrich.l...@hhi.fraunhofer.de on 8 Jul 2010 at 4:50

[GoogleCodeExporter]

Afaik this depends on the COM driver & the registry permissions.
I do have similar issues - but basically only if i execute the enumerator 
without administrative privileges.

What you can do - or at least try as ugly fix is:
###
* open regedit
* search for "SerialCOMM" & "COM1"/"COM3" and change the registry permissions 
to the related windows-user-account.

This works for me with most com-situations ...but its just a non-perfect 
workaround.

Original comment by elAndroi...@googlemail.com on 21 Apr 2011 at 9:09

[GoogleCodeExporter]

The problem is: 

the situation that the enumerator example might not work for all 
com-devices/drivers/windows-user-permissions ins somehow a critical one - as 
least if people rely on the 
enumerator function.

The question is:
Is there some kind of idea how to troubleshoot that area for the future?

Original comment by elAndroi...@googlemail.com on 3 May 2011 at 10:52

[GoogleCodeExporter]

Original comment by dbzhang...@gmail.com on 16 Mar 2012 at 8:34

• Changed state: Accepted