DotNetNewsgroup.com  
web access to complete list of Microsoft.NET newsgroups
   home   |   control panel login   |   archive  |  
 
  carried group
academic
adonet
aspnet
aspnet.announcements
aspnet.buildingcontrols
aspnet.caching
aspnet.datagridcontrol
aspnet.mobile
aspnet.security
aspnet.webcontrols
aspnet.webservices
assignment_manager
datatools
dotnet.distributed_apps
dotnet.general
dotnet.myservices
dotnet.nternationalization
dotnet.scripting
dotnet.security
dotnet.vjsharp
dotnet.vsa
dotnet.xml
dotnetfaqs
framework
framework.clr
framework.compactframework
framework.component_services
framework.controls
framework.databinding
framework.drawing
framework.enhancements
framework.interop
framework.odbcnet
framework.performance
framework.remoting
framework.sdk
framework.setup
framework.webservices
framework.windowsforms
framework.wmi
frwk.windowsforms.designtime
lang.csharp
lang.jscript
lang.vb
lang.vb.controls
lang.vb.data
lang.vb.upgrade
lang.vc
lang.vc.libraries
  
 
start date: Thu, 09 Aug 2007 04:51:54 -0000,    posted on: microsoft.public.dotnet.framework.compactframework        back       

Thread Index
  1    silverfox
          2    Daniel Strigl
          3    Dick Grier dick_grierNOSPAM@.msn.com
          4    silverfox
          5    silverfox
          6    silverfox
          7    silverfox
                 8    ctacke/ ctacke[at]opennetcf[dot]com
                        9    ctacke/ ctacke[at]opennetcf[dot]com
                               10    Paul G. Tobey [eMVP] p space tobey no spam AT no instrument no spam DOT com
                                      11    Paul G. Tobey [eMVP] p space tobey no spam AT no instrument no spam DOT com
                                      12    Paul G. Tobey [eMVP] p space tobey no spam AT no instrument no spam DOT com
                               13    ctacke/ ctacke[at]opennetcf[dot]com
                                      14    ctacke/ ctacke[at]opennetcf[dot]com
                 15    Dick Grier dick_grierNOSPAM@.msn.com
          16    silverfox
          17    silverfox
                 18    ctacke/ ctacke[at]opennetcf[dot]com
          19    silverfox
          20    silverfox
          21    silverfox
                 22    ctacke/ ctacke[at]opennetcf[dot]com
                 23    Dick Grier dick_grierNOSPAM@.msn.com
          24    silverfox
          25    silverfox
          26    silverfox
          27    silverfox
                 28    Dick Grier dick_grierNOSPAM@.msn.com
          29    silverfox


Accessing the Bluetooth COM ports in VB   
I have been trying to write a VB program to use Bluetooth to
communicate between a PDA running Windows CE 4.2 and another BT
device.  I found this article that got me started:
http://www.devx.com/wireless/Article/11511

Using the technique in this article, I can successfully transmit data
but the receive part fails.  In fact it slows the PDA to a crawl.
Does anyone have any ideas on how to modify the original program so
that the receive function will work?

BTW, I am using VS 2005 and the original program was for an earlier
version of VS.  I am not sure if this is relevant.

Here is the relevant section of the source from the article:

    Dim infileHandler As Long
    Dim outfileHandler As Long
    Dim numReadWrite As Integer
    Dim t1 As System.Threading.Thread
    Dim stopThread As Boolean = False

    Public Sub connect()
        '---port number for Bluetooth connection
        Dim inPort As Short = 8
        Dim outPort As Short = 6

        '---Opens the port for Bluetooth
        infileHandler = CreateFile("COM" & inPort & ":", _
                                    &HC0000000, 0, 0, 3, 0, 0)
        Application.DoEvents()
        outfileHandler = CreateFile("COM" & outPort & ":", _
                                    &HC0000000, 0, 0, 3, 0, 0)
        Application.DoEvents()

        '---invoke the thread to receive incoming messages
        stopThread = False
        t1 = New Threading.Thread(AddressOf receiveLoop)
        t1.Start()
    End Sub

    Public Sub disconnect()
        stopThread = True
        CloseHandle(infileHandler)
        CloseHandle(outfileHandler)
    End Sub

   <DllImport("coredll.dll")> _
    Private Shared Function CreateFile(ByVal lpFileName As String, _
                                       ByVal dwDesiredAccess As
Integer, _
                                       ByVal dwShareMode As Integer, _
                                       ByVal lpSecurityAttributes As
Integer, _
                                       ByVal dwCreationDisposition As
Integer, _
                                       ByVal dwFlagsAndAttributes As
Integer, _
                                       ByVal hTemplateFile As Integer)
As Integer
    End Function

    <DllImport("coredll.dll")> _
   Private Shared Function ReadFile(ByVal hFile As Integer, _
                                    ByVal Buffer() As Byte, _
                                    ByVal nNumberOfBytesToRead As
Integer, _
                                    ByRef lpNumberOfBytesRead As
Integer, _
                                    ByRef lpOverlapped As Integer) As
Integer
    End Function

    <DllImport("coredll.dll")> _
    Private Shared Function WriteFile(ByVal hFile As Integer, _
                                      ByVal Buffer() As Byte, _
                                      ByVal nNumberOfBytesToWrite As
Integer, _
                                      ByRef lpNumberOfBytesWritten As
Integer, _
                                      ByVal lpOverlapped As Integer)
As Boolean
    End Function

    <DllImport("coredll.dll")> _
    Private Shared Function CloseHandle(ByVal hObject As Integer) As
Integer
    End Function

    Public Function send(ByVal message As String) As Integer
        '---send the message through the serial port
        Dim value As String = message & vbCrLf
        Dim retCode As Integer = WriteFile(outfileHandler, _
                                           stringToByteArray(value), _
                                           value.Length(), _
                                           numReadWrite, _
                                           0)
        txtMessageLog.Text += value
        Return retCode
    End Function

    Public Sub receiveLoop()
        '---receive the message through the serial port
        Dim inbuff(300) As Byte
        Dim retCode As Integer = ReadFile(infileHandler, _
                                          inbuff, _
                                          inbuff.Length, _
                                          numReadWrite, _
                                          0)
        Application.DoEvents()
        While True
            If retCode = 0 Or stopThread Then
                'MsgBox("Error reading message.")
                Exit While
            Else
                Dim updateDelegate As New _
                    myDelegate(AddressOf updateMessageLog)

                updateDelegate.Invoke(byteArrayToString(inbuff))
                ReDim inbuff(300)
                retCode = ReadFile(infileHandler, _
                                   inbuff, _
                                   inbuff.Length, _
                                   numReadWrite, _
                                   0)
                Application.DoEvents()
            End If
        End While
    End Sub


    Public Delegate Sub myDelegate(ByVal str As String)

    Public Sub updateMessageLog(ByVal str As String)
        If str.Length > 0 Then
            txtMessageLog.Text += "-->" & str
        End If
    End Sub

The only thing I had to change was the port numbers to match the BT
COM ports on my PDA.  The Text box for receiving the incoming stream
immediately becomes filled with repeated instances of -->, as
updateMessageLog is apparently called repeatedly.  I hope that there
is a simple solution to this problem.
Date:Thu, 09 Aug 2007 04:51:54 -0000   Author:  

Re: Accessing the Bluetooth COM ports in VB   
silverfox schrieb:


>     Public Sub receiveLoop()
>         '---receive the message through the serial port
>         Dim inbuff(300) As Byte
>         Dim retCode As Integer = ReadFile(infileHandler, _
>                                           inbuff, _
>                                           inbuff.Length, _
>                                           numReadWrite, _
>                                           0)
>         Application.DoEvents()
>         While True
>             If retCode = 0 Or stopThread Then
>                 'MsgBox("Error reading message.")
>                 Exit While
>             Else
>                 Dim updateDelegate As New _
>                     myDelegate(AddressOf updateMessageLog)
> 
>                 updateDelegate.Invoke(byteArrayToString(inbuff))
>                 ReDim inbuff(300)
>                 retCode = ReadFile(infileHandler, _
>                                    inbuff, _
>                                    inbuff.Length, _
>                                    numReadWrite, _
>                                    0)
>                 Application.DoEvents()
>             End If
>         End While
>     End Sub
> 
> 
>     Public Delegate Sub myDelegate(ByVal str As String)
> 
>     Public Sub updateMessageLog(ByVal str As String)
>         If str.Length > 0 Then
>             txtMessageLog.Text += "-->" & str
>         End If
>     End Sub


Why do you invoke your "updateMessageLog" method before you read the 
data from the port?

Try to move the invoke after the "ReadFile" part.

-- 
Daniel Strigl [daniel.strigl@gmx.takethisout.at, remove 'takethisout.']
Web: http://www.hh-system.com/danielstrigl
Blog: http://geekswithblogs.net/dastblog
Date:Thu, 09 Aug 2007 09:17:33 +0200   Author:  

Re: Accessing the Bluetooth COM ports in VB   
Hi,

Since you are using VS2005, why not use the built-in SerialPort object (data 
are read in a background thread)?  In general, you will not need 
Application.DoEvents when using a thread, which will give you good overall 
performance -- and (IMO), you should buffer a reasonable amount of data 
before you log it.

I have a more complete source code example, that a number of people are 
using on Windows CE 4.2 systems in my book.  I show two different methods 
for reading data using a threaded model.  See below.

Dick

-- 
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth 
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March 
2006.
See www.hardandsoftware.net for details and contact information.
Date:Thu, 9 Aug 2007 10:04:22 -0600   Author:  

Re: Accessing the Bluetooth COM ports in VB   
On Aug 9, 12:17 am, Daniel Strigl 
wrote:

> silverfox schrieb:
>
>
>
> >     Public Sub receiveLoop()
> >         '---receive the message through the serial port
> >         Dim inbuff(300) As Byte
> >         Dim retCode As Integer = ReadFile(infileHandler, _
> >                                           inbuff, _
> >                                           inbuff.Length, _
> >                                           numReadWrite, _
> >                                           0)
> >         Application.DoEvents()
> >         While True
> >             If retCode = 0 Or stopThread Then
> >                 'MsgBox("Error reading message.")
> >                 Exit While
> >             Else
> >                 Dim updateDelegate As New _
> >                     myDelegate(AddressOf updateMessageLog)
>
> >                 updateDelegate.Invoke(byteArrayToString(inbuff))
> >                 ReDim inbuff(300)
> >                 retCode = ReadFile(infileHandler, _
> >                                    inbuff, _
> >                                    inbuff.Length, _
> >                                    numReadWrite, _
> >                                    0)
> >                 Application.DoEvents()
> >             End If
> >         End While
> >     End Sub
>
> >     Public Delegate Sub myDelegate(ByVal str As String)
>
> >     Public Sub updateMessageLog(ByVal str As String)
> >         If str.Length > 0 Then
> >             txtMessageLog.Text += "-->" & str
> >         End If
> >     End Sub
>
> Why do you invoke your "updateMessageLog" method before you read the
> data from the port?
>
> Try to move the invoke after the "ReadFile" part.
>
> --
> Daniel Strigl [daniel.str...@gmx.takethisout.at, remove 'takethisout.']
> Web:http://www.hh-system.com/danielstrigl
> Blog:http://geekswithblogs.net/dastblog


Well first, this is the code in the article, not mine. But if you look
at the code you see that he precedes the loop with a read, so there is
always a read preceding every call to updateMessageLog.
Date:Thu, 09 Aug 2007 19:55:59 -0000   Author:  

Re: Accessing the Bluetooth COM ports in VB   
On Aug 9, 9:04 am, "Dick Grier" <dick_grierNOSPAM@.msn.com> wrote:

> Hi,
>
> Since you are using VS2005, why not use the built-in SerialPort object (data
> are read in a background thread)?  In general, you will not need
> Application.DoEvents when using a thread, which will give you good overall
> performance -- and (IMO), you should buffer a reasonable amount of data
> before you log it.
>
> I have a more complete source code example, that a number of people are
> using on Windows CE 4.2 systems in my book.  I show two different methods
> for reading data using a threaded model.  See below.
>
> Dick
>
> --
> Richard Grier, MVP
> Hard & Software
> Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
> Edition,
> ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
> 2006.
> Seewww.hardandsoftware.netfor details and contact information.


Thanks, Dick.  I guess I should buy your book!
Date:Thu, 09 Aug 2007 21:55:37 -0000   Author:  

Re: Accessing the Bluetooth COM ports in VB   
On Aug 9, 9:04 am, "Dick Grier" <dick_grierNOSPAM@.msn.com> wrote:

> Hi,
>
> Since you are using VS2005, why not use the built-in SerialPort object (data
> are read in a background thread)?  In general, you will not need
> Application.DoEvents when using a thread, which will give you good overall
> performance -- and (IMO), you should buffer a reasonable amount of data
> before you log it.
>
> I have a more complete source code example, that a number of people are
> using on Windows CE 4.2 systems in my book.  I show two different methods
> for reading data using a threaded model.  See below.
>
> Dick
>
> --
> Richard Grier, MVP
> Hard & Software
> Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
> Edition,
> ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
> 2006.
> Seewww.hardandsoftware.netfor details and contact information.


Well, I haven't purchased your book yet, but in my first experiment
using a SerialPort object, I got an error on opening the output port.
The stack trace showed an IOException thrown at
SerialPort.open():SerialStream.setBufferSizes():SerialStream.checkResult():WinIOError()

The relevant code executed (in my prog) consists of only the following
two lines:

System.IO.Ports.SerialPort serialOutputPort = New
System.IO.Ports.SerialPort("COM8")
serialOutputPort.open()

-- don
Date:Thu, 09 Aug 2007 22:23:37 -0000   Author:  

Re: Accessing the Bluetooth COM ports in VB   
On Aug 9, 3:23 pm, silverfox  wrote:

> On Aug 9, 9:04 am, "Dick Grier" <dick_grierNOSPAM@.msn.com> wrote:
>
>
>
> > Hi,
>
> > Since you are using VS2005, why not use the built-in SerialPort object (data
> > are read in a background thread)?  In general, you will not need
> > Application.DoEvents when using a thread, which will give you good overall
> > performance -- and (IMO), you should buffer a reasonable amount of data
> > before you log it.
>
> > I have a more complete source code example, that a number of people are
> > using on Windows CE 4.2 systems in my book.  I show two different methods
> > for reading data using a threaded model.  See below.
>
> > Dick
>
> > --
> > Richard Grier, MVP
> > Hard & Software
> > Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
> > Edition,
> > ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
> > 2006.
> > Seewww.hardandsoftware.netfordetails and contact information.
>
> Well, I haven't purchased your book yet, but in my first experiment
> using a SerialPort object, I got an error on opening the output port.
> The stack trace showed an IOException thrown at
> SerialPort.open():SerialStream.setBufferSizes():SerialStream.checkResult():WinIOError()
>
> The relevant code executed (in my prog) consists of only the following
> two lines:
>
> System.IO.Ports.SerialPort serialOutputPort = New
> System.IO.Ports.SerialPort("COM8")
> serialOutputPort.open()
>
> -- don

Another interesting thing about this little exception is that the
program that caused it cannot be stopped.  Quit doesn't work and going
to Settings:System:Memory:Running Programs:Stop doesn't stop it
either.  Only a reset killed that program.   And this is when it is
sitting at the error display page! This has to be a Microsoft bug.
Date:Thu, 09 Aug 2007 23:09:43 -0000   Author:  

Re: Accessing the Bluetooth COM ports in VB   
I doubt it's a Microsoft bug.  It's pretty certain that MS tested such a 
simple scenario before releasing, and it's equally certain that the many 
people using the serial libraries would have found and reported this before 
you.

My bet is that it's a problem with the device's bluetooth driver.  It didn't 
implement something (or didn't implement it right) that the serial classes 
are trying to initialize.  The fact that your original test with what one 
would expect to be known-working code also exhibited strange behavior also 
points to this same thing.

Personally I'd try to set up a really simple C++ app that opens the driver 
and dumps incoming data to the console just to see if that works, thereby 
removing all managed code questions from the equation.  If that's not an 
option, then using classes that you have source for all the way down to the 
P/Invoke would be useful so you could trace it to the driver interface 
boundary, again removing the possibility that it's your code (or the managed 
port class) causing the issue.


-- 

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded World
www.OpenNETCF.com



"silverfox"  wrote in message 
news:1186700983.677404.298050@m37g2000prh.googlegroups.com...

> On Aug 9, 3:23 pm, silverfox  wrote:
>> On Aug 9, 9:04 am, "Dick Grier" <dick_grierNOSPAM@.msn.com> wrote:
>>
>>
>>
>> > Hi,
>>
>> > Since you are using VS2005, why not use the built-in SerialPort object 
>> > (data
>> > are read in a background thread)?  In general, you will not need
>> > Application.DoEvents when using a thread, which will give you good 
>> > overall
>> > performance -- and (IMO), you should buffer a reasonable amount of data
>> > before you log it.
>>
>> > I have a more complete source code example, that a number of people are
>> > using on Windows CE 4.2 systems in my book.  I show two different 
>> > methods
>> > for reading data using a threaded model.  See below.
>>
>> > Dick
>>
>> > --
>> > Richard Grier, MVP
>> > Hard & Software
>> > Author of Visual Basic Programmer's Guide to Serial Communications, 
>> > Fourth
>> > Edition,
>> > ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised 
>> > March
>> > 2006.
>> > Seewww.hardandsoftware.netfordetails and contact information.
>>
>> Well, I haven't purchased your book yet, but in my first experiment
>> using a SerialPort object, I got an error on opening the output port.
>> The stack trace showed an IOException thrown at
>> SerialPort.open():SerialStream.setBufferSizes():SerialStream.checkResult():WinIOError()
>>
>> The relevant code executed (in my prog) consists of only the following
>> two lines:
>>
>> System.IO.Ports.SerialPort serialOutputPort = New
>> System.IO.Ports.SerialPort("COM8")
>> serialOutputPort.open()
>>
>> -- don
> Another interesting thing about this little exception is that the
> program that caused it cannot be stopped.  Quit doesn't work and going
> to Settings:System:Memory:Running Programs:Stop doesn't stop it
> either.  Only a reset killed that program.   And this is when it is
> sitting at the error display page! This has to be a Microsoft bug.
> 
Date:Thu, 9 Aug 2007 21:42:35 -0500   Author:  

Re: Accessing the Bluetooth COM ports in VB   
On Aug 9, 7:42 pm, "<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote:

> I doubt it's a Microsoft bug.  It's pretty certain that MS tested such a
> simple scenario before releasing, and it's equally certain that the many
> people using the serial libraries would have found and reported this before
> you.
>
> My bet is that it's a problem with the device's bluetooth driver.  It didn't
> implement something (or didn't implement it right) that the serial classes
> are trying to initialize.  The fact that your original test with what one
> would expect to be known-working code also exhibited strange behavior also
> points to this same thing.
>
> Personally I'd try to set up a really simple C++ app that opens the driver
> and dumps incoming data to the console just to see if that works, thereby
> removing all managed code questions from the equation.  If that's not an
> option, then using classes that you have source for all the way down to the
> P/Invoke would be useful so you could trace it to the driver interface
> boundary, again removing the possibility that it's your code (or the managed
> port class) causing the issue.
>
> --
>
> Chris Tacke, Embedded MVP
> OpenNETCF Consulting
> Managed Code in an Embedded Worldwww.OpenNETCF.com
>
> "silverfox"  wrote in message
>
> news:1186700983.677404.298050@m37g2000prh.googlegroups.com...
>
> > On Aug 9, 3:23 pm, silverfox  wrote:
> >> On Aug 9, 9:04 am, "Dick Grier" <dick_grierNOSPAM@.msn.com> wrote:
>
> >> > Hi,
>
> >> > Since you are using VS2005, why not use the built-in SerialPort object
> >> > (data
> >> > are read in a background thread)?  In general, you will not need
> >> > Application.DoEvents when using a thread, which will give you good
> >> > overall
> >> > performance -- and (IMO), you should buffer a reasonable amount of data
> >> > before you log it.
>
> >> > I have a more complete source code example, that a number of people are
> >> > using on Windows CE 4.2 systems in my book.  I show two different
> >> > methods
> >> > for reading data using a threaded model.  See below.
>
> >> > Dick
>
> >> > --
> >> > Richard Grier, MVP
> >> > Hard & Software
> >> > Author of Visual Basic Programmer's Guide to Serial Communications,
> >> > Fourth
> >> > Edition,
> >> > ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised
> >> > March
> >> > 2006.
> >> > Seewww.hardandsoftware.netfordetailsand contact information.
>
> >> Well, I haven't purchased your book yet, but in my first experiment
> >> using a SerialPort object, I got an error on opening the output port.
> >> The stack trace showed an IOException thrown at
> >> SerialPort.open():SerialStream.setBufferSizes():SerialStream.checkResult():WinIOError()
>
> >> The relevant code executed (in my prog) consists of only the following
> >> two lines:
>
> >> System.IO.Ports.SerialPort serialOutputPort = New
> >> System.IO.Ports.SerialPort("COM8")
> >> serialOutputPort.open()
>
> >> -- don
> > Another interesting thing about this little exception is that the
> > program that caused it cannot be stopped.  Quit doesn't work and going
> > to Settings:System:Memory:Running Programs:Stop doesn't stop it
> > either.  Only a reset killed that program.   And this is when it is
> > sitting at the error display page! This has to be a Microsoft bug.


I haven't had a chance to do what you suggest and it will be more than
a short gentle curve for me to figure out how.  But are you saying
that you think that the problem is with the Widcomm stack that HP
ships with all its iPAQs?   Isn't that equally unlikely?
Date:Fri, 10 Aug 2007 04:26:50 -0000   Author:  

Re: Accessing the Bluetooth COM ports in VB   

> I haven't had a chance to do what you suggest and it will be more than
> a short gentle curve for me to figure out how.  But are you saying
> that you think that the problem is with the Widcomm stack that HP
> ships with all its iPAQs?   Isn't that equally unlikely?


Since I know how OEMs tend to test, it's not as unlikely no.  It's also 
possible that how they tested the ports differs from how you're trying to 
use them (I can pretty much guarantee they used native code to test).  My 
guess is that the serial classes are trying to set up some parameter that 
makes sense in a real serial connection, but HP didn't implement or 
implemented incorrectly that same parameter and never bothered to test what 
happens when you try to change it.  Good examples might be baud rate, flow 
control, parity, stop bits, timeouts, etc.


-- 

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded World
www.OpenNETCF.com
Date:Fri, 10 Aug 2007 07:29:01 -0500   Author:  

Re: Accessing the Bluetooth COM ports in VB   
I agree with Chris.  I haven't seen this on my units.

So... I suspect a driver problem.  These things are imposible for us as 
developers (from the outside looking in) to fiddle.  Does the SerialPort 
object in CF2 suffer the same problem?

-- 
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth 
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March 
2006.
See www.hardandsoftware.net for details and contact information.
Date:Fri, 10 Aug 2007 09:39:18 -0600   Author:  

Re: Accessing the Bluetooth COM ports in VB   
On Aug 10, 8:39 am, "Dick Grier" <dick_grierNOSPAM@.msn.com> wrote:

> I agree with Chris.  I haven't seen this on my units.
>
> So... I suspect a driver problem.  These things are imposible for us as
> developers (from the outside looking in) to fiddle.  Does the SerialPort
> object in CF2 suffer the same problem?
>
> --
> Richard Grier, MVP
> Hard & Software
> Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
> Edition,
> ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
> 2006.
> Seewww.hardandsoftware.netfor details and contact information.


I am sorry, Richard, I don't know what you mean by the SerialPort
object in CF2.  This is my first development project using Visual
Studio and the first for a Pocket PC so I am a little behind the
curve.  I searched the Object Browser for SerialPort and used the only
one I found, which is System.IO.Ports.SerialPort.
Date:Fri, 10 Aug 2007 16:31:45 -0000   Author:  

Re: Accessing the Bluetooth COM ports in VB   
On Aug 10, 5:29 am, "<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote:

> > I haven't had a chance to do what you suggest and it will be more than
> > a short gentle curve for me to figure out how.  But are you saying
> > that you think that the problem is with the Widcomm stack that HP
> > ships with all its iPAQs?   Isn't that equally unlikely?
>
> Since I know how OEMs tend to test, it's not as unlikely no.  It's also
> possible that how they tested the ports differs from how you're trying to
> use them (I can pretty much guarantee they used native code to test).  My
> guess is that the serial classes are trying to set up some parameter that
> makes sense in a real serial connection, but HP didn't implement or
> implemented incorrectly that same parameter and never bothered to test what
> happens when you try to change it.  Good examples might be baud rate, flow
> control, parity, stop bits, timeouts, etc.
>
> --
>
> Chris Tacke, Embedded MVP
> OpenNETCF Consulting
> Managed Code in an Embedded Worldwww.OpenNETCF.com


Actually, I was originally referring to the inability to stop the
program once the OS caught an IOException and reported the problem.  I
would have thought that the Quit button on the OS-generated dialog box
would have worked at that point regardless of any problem with the
driver.  And barring that, the STOP running program  in the
System>Memory Running Programs dialog should work regardless of a
problem with a third party driver.  And when both of those things fail
that seems like a bug in the OS to me.  But maybe that's just me.

So, is it your opinion that HP is at fault here for including a
BlueTooth stack that is incompatible with Windows CE, at least with
the SerialPort API?  The Widcomm stack is VERY widely used on PDAs
running Windows CE, by the way, and I would be surprised to find that
such an obvious application as serial communications was not tested at
least to the point to see that the Open method didn't fail every
time.  But again, maybe that's just me.
Date:Fri, 10 Aug 2007 16:46:33 -0000   Author:  

Re: Accessing the Bluetooth COM ports in VB   
You don't know much about operating systems.  What if the application isn't 
running application code at the time of the "stop"?  What if it's in the 
middle of a driver call?  Is the driver left in a bad state?  Can the OS 
terminate the driver, too?  What if another application is also in the 
middle of a call to that driver?  What if the driver is for the display? 
It's not so simple to 'just' terminate an application.

The most-likely place for the bug is your code.  I'm not convinced yet that 
you are the source of the problem.  The second most-likely is in the .NET 
CF, hence the suggestion that you take that out of the loop by using native 
code.  The third most-likely is the Bluetooth stack, as it was probably only 
tested for the standard communication tasks: headset, ActiveSync and maybe 
Bluetooth serial for GPS.  The lest-likely is the operating system itself. 
It's certainly not bug-free, but it gets used in a lot more different 
scenarios than any individual program, driver, or framework.

Paul T.

"silverfox"  wrote in message 
news:1186764393.411862.317820@d30g2000prg.googlegroups.com...

> On Aug 10, 5:29 am, "<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote:
>> > I haven't had a chance to do what you suggest and it will be more than
>> > a short gentle curve for me to figure out how.  But are you saying
>> > that you think that the problem is with the Widcomm stack that HP
>> > ships with all its iPAQs?   Isn't that equally unlikely?
>>
>> Since I know how OEMs tend to test, it's not as unlikely no.  It's also
>> possible that how they tested the ports differs from how you're trying to
>> use them (I can pretty much guarantee they used native code to test).  My
>> guess is that the serial classes are trying to set up some parameter that
>> makes sense in a real serial connection, but HP didn't implement or
>> implemented incorrectly that same parameter and never bothered to test 
>> what
>> happens when you try to change it.  Good examples might be baud rate, 
>> flow
>> control, parity, stop bits, timeouts, etc.
>>
>> --
>>
>> Chris Tacke, Embedded MVP
>> OpenNETCF Consulting
>> Managed Code in an Embedded Worldwww.OpenNETCF.com
>
> Actually, I was originally referring to the inability to stop the
> program once the OS caught an IOException and reported the problem.  I
> would have thought that the Quit button on the OS-generated dialog box
> would have worked at that point regardless of any problem with the
> driver.  And barring that, the STOP running program  in the
> System>Memory Running Programs dialog should work regardless of a
> problem with a third party driver.  And when both of those things fail
> that seems like a bug in the OS to me.  But maybe that's just me.
>
> So, is it your opinion that HP is at fault here for including a
> BlueTooth stack that is incompatible with Windows CE, at least with
> the SerialPort API?  The Widcomm stack is VERY widely used on PDAs
> running Windows CE, by the way, and I would be surprised to find that
> such an obvious application as serial communications was not tested at
> least to the point to see that the Open method didn't fail every
> time.  But again, maybe that's just me.
> 
Date:Fri, 10 Aug 2007 09:57:52 -0700   Author:  

Re: Accessing the Bluetooth COM ports in VB   

> I am sorry, Richard, I don't know what you mean by the SerialPort
> object in CF2.  This is my first development project using Visual
> Studio and the first for a Pocket PC so I am a little behind the
> curve.  I searched the Object Browser for SerialPort and used the only
> one I found, which is System.IO.Ports.SerialPort.


Yes, that means you are using the CF 2.0 Serial Port object (CF 1.0 didn't 
have one, so that leads us to the conclusion you're using CF 2.0 and the 
namespace highly indicates you're using Microsoft's library, not one of the 
many otehrs available like the one from Dick, OpenNETCF, Franson, etc).


-- 

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded World
www.OpenNETCF.com
Date:Fri, 10 Aug 2007 13:40:55 -0500   Author:  

Re: Accessing the Bluetooth COM ports in VB   

> Actually, I was originally referring to the inability to stop the
> program once the OS caught an IOException and reported the problem.  I
> would have thought that the Quit button on the OS-generated dialog box
> would have worked at that point regardless of any problem with the
> driver.  And barring that, the STOP running program  in the
> System>Memory Running Programs dialog should work regardless of a
> problem with a third party driver.  And when both of those things fail
> that seems like a bug in the OS to me.  But maybe that's just me.


Yes, it's just you.  In the first case it's quite possible that a thread is 
blocking in a system call (like maybe a serial read thread stuck on 
WaitCommEvent) and that thread cannot be terminated.  When the parent pukes, 
it becomes a zombie, not owned by really anything but preventing the process 
from being cleaned up.

The Running Programs dialog only sends a WM_CLOSE to the window, so it's 
rarely going to shut down anything that isn't in a known, well-behaved state 
and that has a nice main window that's non-modal and that cleans up all of 
its threads when that window is closed.  Basically that means it's pretty 
useless for a developer.


> So, is it your opinion that HP is at fault here for including a
> BlueTooth stack that is incompatible with Windows CE, at least with
> the SerialPort API?  The Widcomm stack is VERY widely used on PDAs
> running Windows CE, by the way, and I would be surprised to find that
> such an obvious application as serial communications was not tested at
> least to the point to see that the Open method didn't fail every
> time.  But again, maybe that's just me.


I'm not placing blame yet.  Based on the evidence I do suspect it's the 
bluetooth serial driver interface (not the stack, I'd like to point out). 
The fact it's widely used by people, who mostly use it for things like 
audio, doesn't hold much sway with me.  What percentage of devices have that 
stack?  Maybe 10%?  What percentage of users with that device use it for 
serial comms?  Maybe 10%?  What percentage of those are using the managed 
class to access it?  Maybe 30%?  If my junior high math is still correct 0.1 
* 0.1 * 0.3 is a pretty small number.

I wouldn't consider it "obvious" by any stretch.  I'm somewhat familiar with 
what an OEM might do for testing.  I'm also vaguely familiar with the 
pressures they're under to ship a device, and how even if BT serial failed 
but all otehr tests passed how they still might be very highly inclined to 
ship due to that really small number above.

But maybe that's just me.


-- 

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded World
www.OpenNETCF.com
Date:Fri, 10 Aug 2007 13:55:45 -0500   Author:  

Re: Accessing the Bluetooth COM ports in VB   
On Aug 10, 11:55 am, "<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote:

> > Actually, I was originally referring to the inability to stop the
> > program once the OS caught an IOException and reported the problem.  I
> > would have thought that the Quit button on the OS-generated dialog box
> > would have worked at that point regardless of any problem with the
> > driver.  And barring that, the STOP running program  in the
> > System>Memory Running Programs dialog should work regardless of a
> > problem with a third party driver.  And when both of those things fail
> > that seems like a bug in the OS to me.  But maybe that's just me.
>
> Yes, it's just you.  In the first case it's quite possible that a thread is
> blocking in a system call (like maybe a serial read thread stuck on
> WaitCommEvent) and that thread cannot be terminated.  When the parent pukes,
> it becomes a zombie, not owned by really anything but preventing the process
> from being cleaned up.
>
> The Running Programs dialog only sends a WM_CLOSE to the window, so it's
> rarely going to shut down anything that isn't in a known, well-behaved state
> and that has a nice main window that's non-modal and that cleans up all of
> its threads when that window is closed.  Basically that means it's pretty
> useless for a developer.
>
> > So, is it your opinion that HP is at fault here for including a
> > BlueTooth stack that is incompatible with Windows CE, at least with
> > the SerialPort API?  The Widcomm stack is VERY widely used on PDAs
> > running Windows CE, by the way, and I would be surprised to find that
> > such an obvious application as serial communications was not tested at
> > least to the point to see that the Open method didn't fail every
> > time.  But again, maybe that's just me.
>
> I'm not placing blame yet.  Based on the evidence I do suspect it's the
> bluetooth serial driver interface (not the stack, I'd like to point out).
> The fact it's widely used by people, who mostly use it for things like
> audio, doesn't hold much sway with me.  What percentage of devices have that
> stack?  Maybe 10%?  What percentage of users with that device use it for
> serial comms?  Maybe 10%?  What percentage of those are using the managed
> class to access it?  Maybe 30%?  If my junior high math is still correct 0.1
> * 0.1 * 0.3 is a pretty small number.
>
> I wouldn't consider it "obvious" by any stretch.  I'm somewhat familiar with
> what an OEM might do for testing.  I'm also vaguely familiar with the
> pressures they're under to ship a device, and how even if BT serial failed
> but all otehr tests passed how they still might be very highly inclined to
> ship due to that really small number above.
>
> But maybe that's just me.
>
> --
>
> Chris Tacke, Embedded MVP
> OpenNETCF Consulting
> Managed Code in an Embedded Worldwww.OpenNETCF.com


Ok, you convinced me.  I should not have come off sounding so haughty
when I am such a newbie at this.  Thanks for you feedback!

As to the percentage of devices using the Widcomm stack, I was under
the impression that it was the majority of the Smart Devices out
there, but I can't find the reference right now.  And yes, bundled BT
software on a PDA probably uses the Widcomm API to control the
BlueTooth device rather than either of the two ways I tried.

So, all that aside, can you think of a solution to my problem?  (Other
than buying the Widcomm development kit, which costs $1495.)
Date:Fri, 10 Aug 2007 19:41:05 -0000   Author:  

Re: Accessing the Bluetooth COM ports in VB   

> As to the percentage of devices using the Widcomm stack, I was under
> the impression that it was the majority of the Smart Devices out
> there, but I can't find the reference right now.  And yes, bundled BT
> software on a PDA probably uses the Widcomm API to control the
> BlueTooth device rather than either of the two ways I tried.


Widcomm is used by a lot, so is Microsoft (and if you count Symbol, there's 
a third stack floating out there too).


>
> So, all that aside, can you think of a solution to my problem?  (Other
> than buying the Widcomm development kit, which costs $1495.)


I doubt their SDK will be of much use (there's anotehr SDK that I can't 
recall the name of offhand that supports both the MS and Widcomm stuff, so 
if you end ep buying something, I'd get that instead).  The first thing you 
need to do is try to see if that truly is where the problem lies.  Either a 
native app or a managed app (the free OpenNETCF Serial stuff[1] has an 
identical interface, so the code swap should be trivial) but where you can 
run all the way to the API calls in the debugger would be very useful.


-- 

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded World
www.OpenNETCF.com


[1] 
http://www.opennetcf.com/FreeSoftware/OpenNETCFIOSerial/tabid/252/Default.aspx
Date:Fri, 10 Aug 2007 14:53:56 -0500   Author:  

Re: Accessing the Bluetooth COM ports in VB   
On Aug 10, 8:39 am, "Dick Grier" <dick_grierNOSPAM@.msn.com> wrote:

> I agree with Chris.  I haven't seen this on my units.
>
> So... I suspect a driver problem.  These things are imposible for us as
> developers (from the outside looking in) to fiddle.  Does the SerialPort
> object in CF2 suffer the same problem?
>
> --
> Richard Grier, MVP
> Hard & Software
> Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
> Edition,
> ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
> 2006.
> Seewww.hardandsoftware.netfor details and contact information.


The original problem WAS with the CF2 SerialPort object.  I just
upgraded to CF2 SP2 and see some incremental progress.  Now I get past
the open() but it hangs on Write().  I don't know what the correct
baud rate is supposed to be but I have tried 9600 (the default),
19,200, and 38,400 and 57,600.  I attempted 115,200 but got an error
message saying that 64K was the max allowable.  I think the defaults
are probably correct for data bits, stop bits, parity but I don't know
how to find out what is correct.
Date:Sun, 12 Aug 2007 06:40:33 -0000   Author:  

Re: Accessing the Bluetooth COM ports in VB   
On Aug 10, 9:57 am, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:

> You don't know much about operating systems.  What if the application isn't
> running application code at the time of the "stop"?  What if it's in the
> middle of a driver call?  Is the driver left in a bad state?  Can the OS
> terminate the driver, too?  What if another application is also in the
> middle of a call to that driver?  What if the driver is for the display?
> It's not so simple to 'just' terminate an application.
>
> The most-likely place for the bug is your code.  I'm not convinced yet that
> you are the source of the problem.  The second most-likely is in the .NET
> CF, hence the suggestion that you take that out of the loop by using native
> code.  The third most-likely is theBluetoothstack, as it was probably only
> tested for the standard communication tasks: headset, ActiveSync and maybeBluetoothserial for GPS.  The lest-likely is the operating system itself.
> It's certainly not bug-free, but it gets used in a lot more different
> scenarios than any individual program, driver, or framework.
>
> Paul T.
>
> "silverfox"  wrote in message
>
> news:1186764393.411862.317820@d30g2000prg.googlegroups.com...
>
> > On Aug 10, 5:29 am, "<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote:
> >> > I haven't had a chance to do what you suggest and it will be more than
> >> > a short gentle curve for me to figure out how.  But are you saying
> >> > that you think that the problem is with the Widcomm stack that HP
> >> > ships with all its iPAQs?   Isn't that equally unlikely?
>
> >> Since I know how OEMs tend to test, it's not as unlikely no.  It's also
> >> possible that how they tested the ports differs from how you're trying to
> >> use them (I can pretty much guarantee they used native code to test).  My
> >> guess is that the serial classes are trying to set up some parameter that
> >> makes sense in a real serial connection, but HP didn't implement or
> >> implemented incorrectly that same parameter and never bothered to test
> >> what
> >> happens when you try to change it.  Good examples might be baud rate,
> >> flow
> >> control, parity, stop bits, timeouts, etc.
>
> >> --
>
> >> Chris Tacke, Embedded MVP
> >> OpenNETCF Consulting
> >> Managed Code in an Embedded Worldwww.OpenNETCF.com
>
> > Actually, I was originally referring to the inability to stop the
> > program once the OS caught an IOException and reported the problem.  I
> > would have thought that the Quit button on the OS-generated dialog box
> > would have worked at that point regardless of any problem with the
> > driver.  And barring that, the STOP running program  in the
> > System>Memory Running Programs dialog should work regardless of a
> > problem with a third party driver.  And when both of those things fail
> > that seems like a bug in the OS to me.  But maybe that's just me.
>
> > So, is it your opinion that HP is at fault here for including a
> >BlueToothstack that is incompatible with Windows CE, at least with
> > the SerialPort API?  The Widcomm stack is VERY widely used on PDAs
> > running Windows CE, by the way, and I would be surprised to find that
> > such an obvious application as serial communications was not tested at
> > least to the point to see that the Open method didn't fail every
> > time.  But again, maybe that's just me.

>> You don't know much about operating systems.


Ok, I admit it.

I don't really see how the problem can be in my code, however, since
it consists of only the following two lines:

        System.IO.Ports.SerialPort serialOutputPort = New
System.IO.Ports.SerialPort("COM8")
        serialOutputPort.Open()

Upgrading to CF2 SP2 got past this problem, however, and as I mention
in another post, it now hangs on the following line:

        serialPort.Write(msg)

I
Date:Sun, 12 Aug 2007 06:59:32 -0000   Author:  

Re: Accessing the Bluetooth COM ports in VB   
Bluetooth has no baud rate, partity, etc.  Setting one is irrelevent, and I 
still think that the problem lies in the driver not properly handling these 
settings.


-- 

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded World
www.OpenNETCF.com


"silverfox"  wrote in message 
news:1186900833.622790.155970@l22g2000prc.googlegroups.com...

> On Aug 10, 8:39 am, "Dick Grier" <dick_grierNOSPAM@.msn.com> wrote:
>> I agree with Chris.  I haven't seen this on my units.
>>
>> So... I suspect a driver problem.  These things are imposible for us as
>> developers (from the outside looking in) to fiddle.  Does the SerialPort
>> object in CF2 suffer the same problem?
>>
>> --
>> Richard Grier, MVP
>> Hard & Software
>> Author of Visual Basic Programmer's Guide to Serial Communications, 
>> Fourth
>> Edition,
>> ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
>> 2006.
>> Seewww.hardandsoftware.netfor details and contact information.
>
> The original problem WAS with the CF2 SerialPort object.  I just
> upgraded to CF2 SP2 and see some incremental progress.  Now I get past
> the open() but it hangs on Write().  I don't know what the correct
> baud rate is supposed to be but I have tried 9600 (the default),
> 19,200, and 38,400 and 57,600.  I attempted 115,200 but got an error
> message saying that 64K was the max allowable.  I think the defaults
> are probably correct for data bits, stop bits, parity but I don't know
> how to find out what is correct.
> 
Date:Sun, 12 Aug 2007 09:42:04 -0500   Author:  

Re: Accessing the Bluetooth COM ports in VB   
On Aug 12, 7:42 am, "<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote:

> Bluetooth has no baud rate, partity, etc.  Setting one is irrelevent, and I
> still think that the problem lies in the driver not properly handling these
> settings.
>
> --
>
> Chris Tacke, Embedded MVP
> OpenNETCF Consulting
> Managed Code in an Embedded Worldwww.OpenNETCF.com
>
> "silverfox"  wrote in message
>
> news:1186900833.622790.155970@l22g2000prc.googlegroups.com...
>
> > On Aug 10, 8:39 am, "Dick Grier" <dick_grierNOSPAM@.msn.com> wrote:
> >> I agree with Chris.  I haven't seen this on my units.
>
> >> So... I suspect a driver problem.  These things are imposible for us as
> >> developers (from the outside looking in) to fiddle.  Does the SerialPort
> >> object in CF2 suffer the same problem?
>
> >> --
> >> Richard Grier, MVP
> >> Hard & Software
> >> Author of Visual Basic Programmer's Guide to Serial Communications,
> >> Fourth
> >> Edition,
> >> ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
> >> 2006.
> >> Seewww.hardandsoftware.netfordetails and contact information.
>
> > The original problem WAS with the CF2 SerialPort object.  I just
> > upgraded to CF2 SP2 and see some incremental progress.  Now I get past
> > the open() but it hangs on Write().  I don't know what the correct
> > baud rate is supposed to be but I have tried 9600 (the default),
> > 19,200, and 38,400 and 57,600.  I attempted 115,200 but got an error
> > message saying that 64K was the max allowable.  I think the defaults
> > are probably correct for data bits, stop bits, parity but I don't know
> > how to find out what is correct.


Yeah, I knew that those settings are irrelevant to the BT transceiver,
but I thought that maybe, as one other poster suggested, the interface
between the SerialPort object and the BT stack might need these
settings to be correct.  I am groping in the dark here as there is so
much that I do not know about how it all fits together.  Just trying
to puzzle it all out.

So, if it is the driver, does that mean that I am out of business?
Honestly, I don't really understand the distinction between the stack
and the driver.  There is only one software version listed in the
iPAQ's BT asset listing, and on my machine it is 1.4.1.75, which is
variously referred to on the web as the stack version and as the
driver version.  I am still not sure which that version refers to.

Well, I just found this link (http://www.salling.com/forums/
viewtopic.php?p=21525)  which is the first indication I have found
that there is a newer stack version available.  I think I will give it
a try and see if it helps.  Any other suggestions are welcome.
Date:Sun, 12 Aug 2007 17:47:49 -0000   Author:  

Re: Accessing the Bluetooth COM ports in VB   
OK, I've looked through the old messages and I don't see what the 
characteristics of 'msg' are that you are passing to that Write method.  You 
might try, if msg is a large amount of data, sending something simple, like 
a ASCII string (the three bytes 65, 66, 67 would be 'ABC' in ASCII), and 
seeing if the other end receives that.

Paul T.

"silverfox"  wrote in message 
news:1186901972.735815.80500@x35g2000prf.googlegroups.com...

> On Aug 10, 9:57 am, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
> no instrument no spam DOT com> wrote:
>> You don't know much about operating systems.  What if the application 
>> isn't
>> running application code at the time of the "stop"?  What if it's in the
>> middle of a driver call?  Is the driver left in a bad state?  Can the OS
>> terminate the driver, too?  What if another application is also in the
>> middle of a call to that driver?  What if the driver is for the display?
>> It's not so simple to 'just' terminate an application.
>>
>> The most-likely place for the bug is your code.  I'm not convinced yet 
>> that
>> you are the source of the problem.  The second most-likely is in the .NET
>> CF, hence the suggestion that you take that out of the loop by using 
>> native
>> code.  The third most-likely is theBluetoothstack, as it was probably 
>> only
>> tested for the standard communication tasks: headset, ActiveSync and 
>> maybeBluetoothserial for GPS.  The lest-likely is the operating system 
>> itself.
>> It's certainly not bug-free, but it gets used in a lot more different
>> scenarios than any individual program, driver, or framework.
>>
>> Paul T.
>>
>> "silverfox"  wrote in message
>>
>> news:1186764393.411862.317820@d30g2000prg.googlegroups.com...
>>
>> > On Aug 10, 5:29 am, "<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote:
>> >> > I haven't had a chance to do what you suggest and it will be more 
>> >> > than
>> >> > a short gentle curve for me to figure out how.  But are you saying
>> >> > that you think that the problem is with the Widcomm stack that HP
>> >> > ships with all its iPAQs?   Isn't that equally unlikely?
>>
>> >> Since I know how OEMs tend to test, it's not as unlikely no.  It's 
>> >> also
>> >> possible that how they tested the ports differs from how you're trying 
>> >> to
>> >> use them (I can pretty much guarantee they used native code to test). 
>> >> My
>> >> guess is that the serial classes are trying to set up some parameter 
>> >> that
>> >> makes sense in a real serial connection, but HP didn't implement or
>> >> implemented incorrectly that same parameter and never bothered to test
>> >> what
>> >> happens when you try to change it.  Good examples might be baud rate,
>> >> flow
>> >> control, parity, stop bits, timeouts, etc.
>>
>> >> --
>>
>> >> Chris Tacke, Embedded MVP
>> >> OpenNETCF Consulting
>> >> Managed Code in an Embedded Worldwww.OpenNETCF.com
>>
>> > Actually, I was originally referring to the inability to stop the
>> > program once the OS caught an IOException and reported the problem.  I
>> > would have thought that the Quit button on the OS-generated dialog box
>> > would have worked at that point regardless of any problem with the
>> > driver.  And barring that, the STOP running program  in the
>> > System>Memory Running Programs dialog should work regardless of a
>> > problem with a third party driver.  And when both of those things fail
>> > that seems like a bug in the OS to me.  But maybe that's just me.
>>
>> > So, is it your opinion that HP is at fault here for including a
>> >BlueToothstack that is incompatible with Windows CE, at least with
>> > the SerialPort API?  The Widcomm stack is VERY widely used on PDAs
>> > running Windows CE, by the way, and I would be surprised to find that
>> > such an obvious application as serial communications was not tested at
>> > least to the point to see that the Open method didn't fail every
>> > time.  But again, maybe that's just me.
>
>>> You don't know much about operating systems.
>
> Ok, I admit it.
>
> I don't really see how the problem can be in my code, however, since
> it consists of only the following two lines:
>
>        System.IO.Ports.SerialPort serialOutputPort = New
> System.IO.Ports.SerialPort("COM8")
>        serialOutputPort.Open()
>
> Upgrading to CF2 SP2 got past this problem, however, and as I mention
> in another post, it now hangs on the following line:
>
>        serialPort.Write(msg)
>
> I
>
> 
Date:Mon, 13 Aug 2007 08:57:08 -0700   Author:  

Re: Accessing the Bluetooth COM ports in VB   
Hi,

With BT, the actual port speed is arbitrary.  You can use anything that is 
supported, with exactly the same result.  You would want to use 8 data bits, 
with no parity.  If the code hangs on Output... I'm confused. 
CFSerialIO.dll (from my homepage) use SerialPort.Output(somemessage) syntax. 
The SerialPort object in Visual Studio uses SerialPort.Write(somemessage) 
syntax.

I have never seen a "hang," though the Output method in my dll is a blocking 
method.  Thus, if data are not accepted by the serial driver (control must 
be returned from the WriteFile API call), then what you are seeing is what 
I'd expect.  I guess.  Windows CE does not support Overlapped IO, so any 
non-blocking call to WriteFile requires extra effort -- and I've never seen 
the need. If this is the situation, there would seem to be some underlying 
mechanism that is the source of the trouble.  Just, IMO, from the outside 
looking in.

Dick

-- 
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth 
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March 
2006.
See www.hardandsoftware.net for details and contact information.
Date:Mon, 13 Aug 2007 11:13:44 -0600   Author:  

Re: Accessing the Bluetooth COM ports in VB   
On Aug 13, 8:57 am, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:

> OK, I've looked through the old messages and I don't see what the
> characteristics of 'msg' are that you are passing to that Write method.  You
> might try, if msg is a large amount of data, sending something simple, like
> a ASCII string (the three bytes 65, 66, 67 would be 'ABC' in ASCII), and
> seeing if the other end receives that.
>
> Paul T.
>
> "silverfox"  wrote in message
>
> news:1186901972.735815.80500@x35g2000prf.googlegroups.com...
>
> > On Aug 10, 9:57 am, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
> > no instrument no spam DOT com> wrote:
> >> You don't know much about operating systems.  What if the application
> >> isn't
> >> running application code at the time of the "stop"?  What if it's in the
> >> middle of a driver call?  Is the driver left in a bad state?  Can the OS
> >> terminate the driver, too?  What if another application is also in the
> >> middle of a call to that driver?  What if the driver is for the display?
> >> It's not so simple to 'just' terminate an application.
>
> >> The most-likely place for the bug is your code.  I'm not convinced yet
> >> that
> >> you are the source of the problem.  The second most-likely is in the .NET
> >> CF, hence the suggestion that you take that out of the loop by using
> >> native
> >> code.  The third most-likely is theBluetoothstack, as it was probably
> >> only
> >> tested for the standard communication tasks: headset, ActiveSync and
> >> maybeBluetoothserial for GPS.  The lest-likely is the operating system
> >> itself.
> >> It's certainly not bug-free, but it gets used in a lot more different
> >> scenarios than any individual program, driver, or framework.
>
> >> Paul T.
>
> >> "silverfox"  wrote in message
>
> >>news:1186764393.411862.317820@d30g2000prg.googlegroups.com...
>
> >> > On Aug 10, 5:29 am, "<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote:
> >> >> > I haven't had a chance to do what you suggest and it will be more
> >> >> > than
> >> >> > a short gentle curve for me to figure out how.  But are you saying
> >> >> > that you think that the problem is with the Widcomm stack that HP
> >> >> > ships with all its iPAQs?   Isn't that equally unlikely?
>
> >> >> Since I know how OEMs tend to test, it's not as unlikely no.  It's
> >> >> also
> >> >> possible that how they tested the ports differs from how you're trying
> >> >> to
> >> >> use them (I can pretty much guarantee they used native code to test).
> >> >> My
> >> >> guess is that the serial classes are trying to set up some parameter
> >> >> that
> >> >> makes sense in a real serial connection, but HP didn't implement or
> >> >> implemented incorrectly that same parameter and never bothered to test
> >> >> what
> >> >> happens when you try to change it.  Good examples might be baud rate,
> >> >> flow
> >> >> control, parity, stop bits, timeouts, etc.
>
> >> >> --
>
> >> >> Chris Tacke, Embedded MVP
> >> >> OpenNETCF Consulting
> >> >> Managed Code in an Embedded Worldwww.OpenNETCF.com
>
> >> > Actually, I was originally referring to the inability to stop the
> >> > program once the OS caught an IOException and reported the problem.  I
> >> > would have thought that the Quit button on the OS-generated dialog box
> >> > would have worked at that point regardless of any problem with the
> >> > driver.  And barring that, the STOP running program  in the
> >> > System>Memory Running Programs dialog should work regardless of a
> >> > problem with a third party driver.  And when both of those things fail
> >> > that seems like a bug in the OS to me.  But maybe that's just me.
>
> >> > So, is it your opinion that HP is at fault here for including a
> >> >BlueToothstack that is incompatible with Windows CE, at least with
> >> > the SerialPort API?  The Widcomm stack is VERY widely used on PDAs
> >> > running Windows CE, by the way, and I would be surprised to find that
> >> > such an obvious application as serial communications was not tested at
> >> > least to the point to see that the Open method didn't fail every
> >> > time.  But again, maybe that's just me.
>
> >>> You don't know much about operating systems.
>
> > Ok, I admit it.
>
> > I don't really see how the problem can be in my code, however, since
> > it consists of only the following two lines:
>
> >        System.IO.Ports.SerialPort serialOutputPort = New
> > System.IO.Ports.SerialPort("COM8")
> >        serialOutputPort.Open()
>
> > Upgrading to CF2 SP2 got past this problem, however, and as I mention
> > in another post, it now hangs on the following line:
>
> >        serialPort.Write(msg)
>
> > I


I am in fact sending three ascii characters plus a CR.
Date:Mon, 13 Aug 2007 18:45:19 -0000   Author:  

Re: Accessing the Bluetooth COM ports in VB   
And the result on the sending end is nothing.  What is the result on the 
receiving end?  It sure sounds like no connection is established.

Paul T.

"silverfox"  wrote in message 
news:1187030719.497967.113900@x40g2000prg.googlegroups.com...

> On Aug 13, 8:57 am, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
> no instrument no spam DOT com> wrote:
>> OK, I've looked through the old messages and I don't see what the
>> characteristics of 'msg' are that you are passing to that Write method. 
>> You
>> might try, if msg is a large amount of data, sending something simple, 
>> like
>> a ASCII string (the three bytes 65, 66, 67 would be 'ABC' in ASCII), and
>> seeing if the other end receives that.
>>
>> Paul T.
>>
>> "silverfox"  wrote in message
>>
>> news:1186901972.735815.80500@x35g2000prf.googlegroups.com...
>>
>> > On Aug 10, 9:57 am, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
>> > no instrument no spam DOT com> wrote:
>> >> You don't know much about operating systems.  What if the application
>> >> isn't
>> >> running application code at the time of the "stop"?  What if it's in 
>> >> the
>> >> middle of a driver call?  Is the driver left in a bad state?  Can the 
>> >> OS
>> >> terminate the driver, too?  What if another application is also in the
>> >> middle of a call to that driver?  What if the driver is for the 
>> >> display?
>> >> It's not so simple to 'just' terminate an application.
>>
>> >> The most-likely place for the bug is your code.  I'm not convinced yet
>> >> that
>> >> you are the source of the problem.  The second most-likely is in the 
>> >> .NET
>> >> CF, hence the suggestion that you take that out of the loop by using
>> >> native
>> >> code.  The third most-likely is theBluetoothstack, as it was probably
>> >> only
>> >> tested for the standard communication tasks: headset, ActiveSync and
>> >> maybeBluetoothserial for GPS.  The lest-likely is the operating system
>> >> itself.
>> >> It's certainly not bug-free, but it gets used in a lot more different
>> >> scenarios than any individual program, driver, or framework.
>>
>> >> Paul T.
>>
>> >> "silverfox"  wrote in message
>>
>> >>news:1186764393.411862.317820@d30g2000prg.googlegroups.com...
>>
>> >> > On Aug 10, 5:29 am, "<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote:
>> >> >> > I haven't had a chance to do what you suggest and it will be more
>> >> >> > than
>> >> >> > a short gentle curve for me to figure out how.  But are you 
>> >> >> > saying
>> >> >> > that you think that the problem is with the Widcomm stack that HP
>> >> >> > ships with all its iPAQs?   Isn't that equally unlikely?
>>
>> >> >> Since I know how OEMs tend to test, it's not as unlikely no.  It's
>> >> >> also
>> >> >> possible that how they tested the ports differs from how you're 
>> >> >> trying
>> >> >> to
>> >> >> use them (I can pretty much guarantee they used native code to 
>> >> >> test).
>> >> >> My
>> >> >> guess is that the serial classes are trying to set up some 
>> >> >> parameter
>> >> >> that
>> >> >> makes sense in a real serial connection, but HP didn't implement or
>> >> >> implemented incorrectly that same parameter and never bothered to 
>> >> >> test
>> >> >> what
>> >> >> happens when you try to change it.  Good examples might be baud 
>> >> >> rate,
>> >> >> flow
>> >> >> control, parity, stop bits, timeouts, etc.
>>
>> >> >> --
>>
>> >> >> Chris Tacke, Embedded MVP
>> >> >> OpenNETCF Consulting
>> >> >> Managed Code in an Embedded Worldwww.OpenNETCF.com
>>
>> >> > Actually, I was originally referring to the inability to stop the
>> >> > program once the OS caught an IOException and reported the problem. 
>> >> > I
>> >> > would have thought that the Quit button on the OS-generated dialog 
>> >> > box
>> >> > would have worked at that point regardless of any problem with the
>> >> > driver.  And barring that, the STOP running program  in the
>> >> > System>Memory Running Programs dialog should work regardless of a
>> >> > problem with a third party driver.  And when both of those things 
>> >> > fail
>> >> > that seems like a bug in the OS to me.  But maybe that's just me.
>>
>> >> > So, is it your opinion that HP is at fault here for including a
>> >> >BlueToothstack that is incompatible with Windows CE, at least with
>> >> > the SerialPort API?  The Widcomm stack is VERY widely used on PDAs
>> >> > running Windows CE, by the way, and I would be surprised to find 
>> >> > that
>> >> > such an obvious application as serial communications was not tested 
>> >> > at
>> >> > least to the point to see that the Open method didn't fail every
>> >> > time.  But again, maybe that's just me.
>>
>> >>> You don't know much about operating systems.
>>
>> > Ok, I admit it.
>>
>> > I don't really see how the problem can be in my code, however, since
>> > it consists of only the following two lines:
>>
>> >        System.IO.Ports.SerialPort serialOutputPort = New
>> > System.IO.Ports.SerialPort("COM8")
>> >        serialOutputPort.Open()
>>
>> > Upgrading to CF2 SP2 got past this problem, however, and as I mention
>> > in another post, it now hangs on the following line:
>>
>> >        serialPort.Write(msg)
>>
>> > I
>
> I am in fact sending three ascii characters plus a CR.
> 
Date:Mon, 13 Aug 2007 12:00:11 -0700   Author:  

Re: Accessing the Bluetooth COM ports in VB   
On Aug 13, 10:13 am, "Dick Grier" <dick_grierNOSPAM@.msn.com> wrote:

> Hi,
>
> With BT, the actual port speed is arbitrary.  You can use anything that is
> supported, with exactly the same result.  You would want to use 8 data bits,
> with no parity.  If the code hangs on Output... I'm confused.
> CFSerialIO.dll (from my homepage) use SerialPort.Output(somemessage) syntax.
> The SerialPort object in Visual Studio uses SerialPort.Write(somemessage)
> syntax.
>
> I have never seen a "hang," though the Output method in my dll is a blocking
> method.  Thus, if data are not accepted by the serial driver (control must
> be returned from the WriteFile API call), then what you are seeing is what
> I'd expect.  I guess.  Windows CE does not support Overlapped IO, so any
> non-blocking call to WriteFile requires extra effort -- and I've never seen
> the need. If this is the situation, there would seem to be some underlying
> mechanism that is the source of the trouble.  Just, IMO, from the outside
> looking in.
>
> Dick
>
> --
> Richard Grier, MVP
> Hard & Software
> Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
> Edition,
> ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
> 2006.
> Seewww.hardandsoftware.netfor details and contact information.


Dick, I just sent you a vb file containing the simplest possible
example that hangs my iPAQ on a SerialPort.Write( ).  The PDA must be
physically reset after the hang.  The program does nothing but create
a SerialPort object with the string "COM8", calls Open( ) on that
object then calls Write("ABC") on it.  The program contains calls to
MsgBox( )  before all four operations and after the Write( ).  The
last MsgBox to display is the one before the Write( ).  The final one
never appears.  If anyone would like me to send them a copy of this vb
file, please let me know.
Date:Mon, 13 Aug 2007 20:08:46 -0000   Author:  

Re: Accessing the Bluetooth COM ports in VB   
See my replies to your email.

-- 
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth 
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March 
2006.
See www.hardandsoftware.net for details and contact information.
Date:Tue, 14 Aug 2007 13:36:47 -0600   Author:  

Re: Accessing the Bluetooth COM ports in VB   
On Aug 14, 12:36 pm, "Dick Grier" <dick_grierNOSPAM@.msn.com> wrote:

> See my replies to your email.
>
> --
> Richard Grier, MVP
> Hard & Software
> Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
> Edition,
> ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
> 2006.
> Seewww.hardandsoftware.netfor details and contact information.


A few posts back someone said that the SerialPort problem I was
experiencing was most likely due an error in my code.  I replied that
my program contained only three significant lines of code and I didn't
see how there could be a problem there.  Well, ahem,  it seems that I
did screw up one of those three lines of code.  The PDA has two serial
ports dedicated to the bluetooth device, one for input and one for
output.  And, you guessed it, I switched them.  I tried to write to
the input port.  40 years of programming should have taught me that no
matter how small a program, I am capable of getting something wrong.
Donald Knuth, I am not.  So, I am sorry for all the bandwidth and time
anyone might have spent reading about or thinking about my problems
with SerialPort.Write( ) hanging my PDA.  It works fine when you write
to the output port instead of the input port.  My attempts to get
SerialPort.Read( ) to work (yes, on the input port) are still
unproductive, but Richard Grier sent me some information on that
problem and I hope to have the whole thing put to bed soon.  Thank you
for your patience and please accept my apologies.  And Richard, thank
you especially for your help.
Date:Wed, 15 Aug 2007 00:35:20 -0000   Author:  

Google
 
Web dotnetnewsgroup.com


COPYRIGHT ?2005, EUROFRONT WORLDWIDE LTD., ALL RIGHT RESERVE  |   Contact us