View available com-port list

Hello everyone,

can somebody help me to get me a dialog with a dropdown for available com-ports?

even better only every outgoing com-ports or with specific device name.

Thanks for ANY help in advance!

There's no official way to get all COM ports:

One thing to note about port names is that traditionally they have been COM1, COM2, COM3, or COM4. The Windows API does not provide any mechanism for determining what ports exist on a system. Some systems even have more ports than the traditional maximum of four. Hardware vendors and serial-device-driver writers are free to name the ports anything they like. For this reason, it is best that users have the ability to specify the port name they want to use. If a port does not exist, an error will occur (ERROR_FILE_NOT_FOUND) after attempting to open the port, and the user should be notified that the port isn't available.

Nonetheless, QueryDosDevice() might be the closest to what you want. You could try something like:
http://pastie.org/private/vwa4ibszmkndl2lyrfv3pw

BTW: I have no idea what an "outgoing" COM port is. COM ports are full duplex, i.e. ports can send and receive (at the same time).

Is this for an application/plugin you're making and you want the installer to assist the user in making a selection for the default COM port during the install?

I've always been a believer in making the application you're creating an install for to do the application specific install parameters. For example, I used NSIS to create the installer for my socket policy server service but let the service executable register (and unregister for uninstalls) itself after the file extract-copy operation by running it with parameters to trigger self (un)registration in the system services table from the installer. This has a number of advantages, especially with installs and uninstalls with updates and overly complicated installs. Since it's conceivable that the next version of your application or plugin may not install/uninstall the same way (or to the same location/name) then making your application do the application specific install modifications means that when it's time to uninstall, your new code doesn't have to know how to uninstall all the previous versions, it just has to invoke the previous version's uninstall functions. It also has the advantage that you don't have to duplicate the same potentially complicated code in the installer. That usually saves such a large number of headaches itself that it's usually justification for allowing the exe/dll to do the application specific installation stuff on it's own merits.

If however, none of this applies to you, nevermind...

thank you for your help.
ill try and report my success!