RFCOMM issues
|
From: Brian S on 14 Oct 2005 14:50 I'm trying to add a bit of Bluetooth support to a program that already does serial printing, using the CreateFile/WriteFile/CloseHandle routine, and it works... the first time. The second time, though, everything appears to succeed according to the function calls, but the data apparently doesn't get to the printer. Shutting down and restarting the app causes it to work again... but only once. Closing down the app is apparently cleaning up something, but I can't tell what. I know of the RegisterDevice/DeregisterDevice, but that doesn't do a bit of good on a device that is missing the btd.dll file but still seems to manage doing RFCOMM. Any ideas? It appears that I'm not cleaning up something that I should be, but can't figure out what and there's nothing usable in the docs about that. -- ----------------------------------------------------------------------- Brian Smith // avalon73 at caerleon dot us // http://www.caerleon.us/ Software Developer // Gamer // Webmaster // System Administrator Politically, I'm neither left wing nor right wing... I sit inside the plane, like a normal person.
From: Ginny Caughey [MVP] on 14 Oct 2005 16:50 Brian, If you call GetLastError after CreateFile fails, what is the error? -- Ginny Caughey ..NET Compact Framework MVP "Brian S" <avalon(a)caerleon.su> wrote in message news:1129315939.97d1d37511b13d196b73fec047a14a66(a)teranews... > I'm trying to add a bit of Bluetooth support to a program that already > does serial printing, using the CreateFile/WriteFile/CloseHandle routine, > and it works... the first time. The second time, though, everything > appears to succeed according to the function calls, but the data > apparently doesn't get to the printer. Shutting down and restarting the > app causes it to work again... but only once. > > Closing down the app is apparently cleaning up something, but I can't tell > what. I know of the RegisterDevice/DeregisterDevice, but that doesn't do > a bit of good on a device that is missing the btd.dll file but still seems > to manage doing RFCOMM. > > Any ideas? It appears that I'm not cleaning up something that I should > be, but can't figure out what and there's nothing usable in the docs about > that. > > -- > ----------------------------------------------------------------------- > Brian Smith // avalon73 at caerleon dot us // http://www.caerleon.us/ > Software Developer // Gamer // Webmaster // System Administrator > Politically, I'm neither left wing nor right wing... I sit inside the > plane, like a normal person.
From: Brian S on 20 Oct 2005 13:42 Ginny Caughey [MVP] <ginny.caughey.online(a)wasteworks.com> supposedly said: > If you call GetLastError after CreateFile fails, what is the error? That's just it... it doesn't return an error. None of the functions return anything other than success for both print attempts while the program is running, but only the first print attempt actually works (as in, the printer actually gets the data). -- ----------------------------------------------------------------------- Brian Smith // avalon73 at caerleon dot us // http://www.caerleon.us/ Software Developer // Gamer // Webmaster // System Administrator "Does anybody really know what time it is? Does anybody really care?" -- Chicago Transit Authority
From: Ginny Caughey [MVP] on 20 Oct 2005 13:56 Brian, Is it possible that you have overrun the printer's buffer with data? My standard printing routines have Sleep(100) after each line to prevent that. It would be nice if you could use something other than the printer as the target of the serial output so you could see what is actually going on. -- Ginny Caughey ..NET Compact Framework MVP "Brian S" <avalon(a)caerleon.su> wrote in message news:1129830459.f7bce8e16154509dd000b19debdd2c6a(a)teranews... > Ginny Caughey [MVP] <ginny.caughey.online(a)wasteworks.com> supposedly said: > >> If you call GetLastError after CreateFile fails, what is the error? > > That's just it... it doesn't return an error. None of the functions > return anything other than success for both print attempts while the > program is running, but only the first print attempt actually works (as > in, the printer actually gets the data). > > -- > ----------------------------------------------------------------------- > Brian Smith // avalon73 at caerleon dot us // http://www.caerleon.us/ > Software Developer // Gamer // Webmaster // System Administrator > "Does anybody really know what time it is? Does anybody really care?" > -- Chicago Transit Authority
From: Brian S on 24 Oct 2005 12:10 Ginny Caughey [MVP] <ginny.caughey.online(a)wasteworks.com> supposedly said: > Is it possible that you have overrun the printer's buffer with data? My > standard printing routines have Sleep(100) after each line to prevent that. Good idea, but the results of some testing today don't seem to support it. The data going to the printer in this case isn't split into lines, so I ended up sending chunks of 100, 50 and 10 bytes at a time, with a 100ms sleep in between. Before and after explicitly setting the serial buffer sizes to 1024 bytes, it's still only printing the first time and not the second. Any other ideas? > It would be nice if you could use something other than the printer as the > target of the serial output so you could see what is actually going on. I agree... not something we have lying around here, though, that I know of. The odd thing is that a test app that our hardware guy has can print repeatedly all day long with no problems, so the hardware isn't at fault. I only wish that I could get my hands on the source for that... -- ----------------------------------------------------------------------- Brian Smith // avalon73 at caerleon dot us // http://www.caerleon.us/ Software Developer // Gamer // Webmaster // System Administrator "Being famous is great. You get to meet lots of people and go to places overseas, like Canada." -- Britney Spears
|
Pages: 1 Prev: Welcome.not is not working Next: Ask me your codesigning questions |