c# - Releasing a unplugged virtual Serial Port -
i got little problem usb barcode scanner. using scanner "serialport" class:
this._barcodescanner = new serialport(comport, 9600, parity.none, 8, stopbits.one) { handshake = handshake.none, readtimeout = 500, writetimeout = 500 }; this._barcodescanner.open(); this._barcodescanner.datareceived += barcodescannercallback;
if unplug usb device while it´s opened via "serialport" class, can´t close software , virtual port stays open eternity or till reboot whole computer.
so question is, there way close virtual port after unplugged device via c# code?
greetings
[edit #1]
alrighty, more code:
this way checking every 10 seconds if device plugged in:
private bool checkusbdeviceavailability() { managementobjectsearcher searcher = new managementobjectsearcher("root\\wmi", "select * msserial_portname portname = '" + this.portname + "'"); if (searcher.get().count > 0) return true; return false; }
thats callback-event of serial port:
void barcodescannercallback(object sender, serialdatareceivedeventargs e) { thread.sleep(500); string data = this._barcodescanner.readexisting().replace(convert.tochar(2), convert.tochar(32)).trim(); if (data.startswith("ax")) { string[] arrdata = data.split('\n'); this._barcodescanner.stopavailabilitythread(); barcode code = new barcode(arrdata[0].replace("\r", "")); if (checkifbarcodeexists(code)) this.updatebarcodenode(code); else this.createbarcodenode(code); barcodescannercallbackevent(sender, e, code); this._barcodescanner.startavailabilitythread(); } this._barcodescanner.comdevicepluggedin = scannerdevice.comavailabilitystate.available; }
if doesnt answer anymore fire "devicenotavailableevent()":
void barcodescannerdevicenotavailableevent() { this._barcodescanner.close(); this._barcodescanner.dispose(); }
i have overriden dispose event of "serialport" class it´s going abort thread:
protected override void dispose(bool isdisposing) { if (isdisposing) { this._deviceavailablethread.abort(); } base.dispose(isdisposing); }
serial ports date stone age of computing. that's plugged in asr-33 teletype start typing in fortran program. electrical interface simple. windows api use serial port own code. practically runtime environment supports them.
usb has replaced serial port hardware completely. has more advanced logical interface machine, supporting many different type of devices. , supports plug , play, allowing operating system detect when device attached or removed automatically installing device driver, etcetera.
this flexibility comes @ price however, usb device needs device driver become usable. device drivers not created equal. different drivers require different ways talk device. done through deviceiocontrol() or read/writefile() opaque api functions. in days of usb, device manufacturers supply dll provided rich api hide implementation details.
that did not work well, manufacturers not @ writing apis , sure don't support them. solution support standard api, 1 that's available on machine, supported runtime, documented , maintained else. serial port api.
that did not work well, manufacturers not @ writing device drivers emulate serial ports. biggest hang-up api doesn't have support plug , play. core support missing, after serial port hardware doesn't have logical interface support it. there some support detecting device attached through dtr hardware handshake line, no support whatsoever detecting port no longer there.
detaching usb device problem. in ideal world, emulator built device driver pretend serial port still there until last handle on device closed. logical implementation, given there's no way trigger plug , play event. strange reason seems difficult implement. usb drivers take crummy shortcut, make device disappear even while in use.
this plays havoc on user mode code uses device. typically written assume real serial port , real serial ports don't disappear. @ least not without drawing bright blue spark. goes wrong pretty unpredictable because depends on how driver responds requests on device that's no longer there. uncatchable exception in worker thread started serialport common mishap. sounds driver gets wrong, generates error return code on mj_close driver request. kind of logical thing driver, after device isn't there anymore, quite unsolvable end. have handle , can't close it. that's creek no paddle.
every major release of .net had small patch serialport classes try minimize misery bit. there's limited amount microsoft can do, catching errors , pretending didn't happen leads class provides no diagnostic anymore, driver.
so practical approaches are:
- always use remove hardware safely tray icon in windows
- use latest version of .net
- contact vendor , ask driver update
- ditch vendors supply lousy drivers
- tell users that, because only thing can usb device, unplugging doesn't solve problems
- make closing port easy , accessible in ui
- glue usb connector port can't removed
the 5th bullet gets programmers in trouble. writing serial port code isn't easy, heavily asynchronous , threadpool thread runs datareceived event difficult deal with. when can't diagnose software problem tend blame hardware. there's little can do hardware unplug it. bad idea. have 2 problems.
Comments
Post a Comment