If you find a bug in the Serial libraries, post it here. This will make it easier to find submitted bugs when we're updating the source.

The Win32 API SetComStat() can not set successful in WinCE 5.0 .

Submitted a change to allow for comm ports > 9 without having to use the strange syntax. Com ports over 9 are simply opened with the value "COM10:" like those with single digits. This need arose from using the serial libraries on the full framework.

sp

File Port.cs, line 913
the call

m_CommAPI.WaitCommEvent(hPort, ref eventFlags)

don't check the return value and, in some cases (like bluetooth serial port), it hangs the device.

Version 1.4, GPS object; we are finding that some NMEA sentences get concatenated together, causing a checksum violation. The following is the fix that we employ to get around this. I like would go a step further than what I post here, and add an overload to the nmea() function to allow a sentence that has no leading '$', rather than my crude prepend of the character... but this example shows how to fix the problem...

Ivan

======================


private void GPS_DataReceived(object sender, string data)
{
String[] parts = data.Split("$".ToCharArray());
foreach (String sentence in parts)
{
if (sentence.Length > 0) // ignore null data
{
if (sentence.IndexOf("*") > 0) // ignore partial sentences (with no checksum)
{
nmea("$" + sentence);
}
}
}
}

If you've got a larger fix (such as an overload) by all means send it to submissions@opennetcf.org and we'll include it.

Some receivers, such as the Holux GM-270 Ultra, do not correctly report satellite info when the fix type is reported as "not set". Here is a sample such sentence:

$GPGSA,A,1,,,,*32

This throws an exception in process_gpgsa because the length of the strdata array ends up being only 6. There is a simple solution: add the following "if" early in the process_gpgsa routine, to cover the rest of the function.

if (fixtype != OpenNETCF.IO.Serial.GPS.Fix_Type.NotSet)
{
....
}

Ivan

At present it appears you cannot stop the GPS system when it is in the Opening or AutoDiscovery states. I suggest replacing the first line of the Stop() function as follows:

public void Stop()
{
if (state!=States.Running && state!=States.Opening && state!=States.AutoDiscovery) return;

I am seeing the SetComState error also in CE 5.0. It seems the problem is in the dcb size. DCB.c has some new local variables added that make the sizeof(this) 0x2c instead of 0x1c as it should be. This makes the SetComState fail with a parameter error.

dave

I am developing for CE, so I do not know how this applies to Windows. I have had the same bug that has been mentioned a few times around the forums. This has to do with the WaitCommEvent() hanging. In our case, the WaitCommEvent() will hang because there is no event or data being sent for it to trigger. If there is a serial device spilling data on the line for for the WaitCommEvent() to pick up, the close will work fine. When the Close() is started, The first action is to close the handle to the port, then invalidate the handle. A problem with this is that WaitCommEvent() does not care. The Thread is supposed to catch an invalid hadle and close down. The Close() needs to set a flag for closure which is checked in the while loop in the thread instead of the Invalid handle. And the one other thing that needs to happen is one final event to break the WaitCommEvent() block, and that is simply a call to m_CommAPI.SetCommMask(hPort, CommEventFlags.ALLCE).

The code below is our changes for CE, but there will need to be some cleanup. It is more of a hack right now. I just added a single global bool for the shutdown flag, but I know I could have used another existing flag.


public bool Close()
{

if(txOverlapped != IntPtr.Zero)
{
LocalFree(txOverlapped);
txOverlapped = IntPtr.Zero;
}

if(!isOpen) return false;

isOpen = false; // to help catch intentional close

m_bShutdown = true;

if(CommAPI.FullFramework)
{
m_CommAPI.SetCommMask(hPort, CommEventFlags.ALLPC);
}
else
{
m_CommAPI.SetCommMask(hPort, CommEventFlags.ALLCE);
}

if(m_CommAPI.CloseHandle(hPort))
{
hPort = (IntPtr)CommAPI.INVALID_HANDLE_VALUE;

m_CommAPI.SetEvent(closeEvent);

isOpen = false;

hPort = (IntPtr)CommAPI.INVALID_HANDLE_VALUE;

m_CommAPI.SetEvent(closeEvent);

return true;
}

return false;
}



And this is the changes for the thread

while(!m_bShutdown)
{
// wait for a Comm event
if(!m_CommAPI.WaitCommEvent(hPort, ref eventFlags))
{


Tom Kuhn

bug in GPS.cs, under .NET 2.0, in the routine "private string[] devices()"

It seems MS has fixed it so that the "rubbish" is no longer there. You need to protect against this as follows:

// fudge to remove rubbish off the end of the string
int rubbishLocation = strport.IndexOf("'");
if (rubbishLocation > 0)
strport = strport.Substring(0, rubbishLocation);


Ivan

Hi! I'm trying to use de new GPS library but I have some problems. First, the GPS object can't open my bluetooth device, I think the problem is in GPS.devices() and GPS.isconnecteddevice() functions. I changed for this:

private string[] devices()
{
// lists all modems on the device
ArrayList al = new ArrayList();
RegistryKey defkey;
string[] keyNames;
string keyvalue = "";
string strport = "";

// now get the active
defkey = Registry.LocalMachine.CreateSubKey(@"Drivers\Active");

keyNames = defkey.GetSubKeyNames();
foreach (string x in keyNames)
{

try
{
keyvalue = defkey.CreateSubKey(x).GetValue("Key").ToString();
strport = defkey.CreateSubKey(x).GetValue("Name").ToString();

// fudge to remove rubbish off the end of the string
strport = strport.Substring(0, strport.IndexOf("'"));

RegistryKey thekey = Registry.LocalMachine.CreateSubKey(keyvalue);

if (strport.StartsWith("COM"))
al.Add(strport);
}
catch
{

}
}
return (string[])al.ToArray(typeof(string));
}

--> Changes:
//**************************************************************
private string[] devices()
{
return System.IO.Ports.SerialPort.GetPortNames();
}
//**************************************************************

For the other function:
private bool isconnecteddevice()
{

foreach (string port in this.devices())
{

if (port.ToUpper() == this.comport.ToUpper())
{
return true;
}
}
return false;
}

--> Changes:
//**************************************************************
private bool isconnecteddevice()
{

foreach (string port in this.devices())
{
if (this.comport.ToUpper().StartsWith(port.ToUpper()))
{
return true;
}
}
return false;
}
//**************************************************************

With thid changes I can open my bluetooth device explorer :)



Hablo con la sabiduria que me da el fracaso. Roberto Iniesta.

When a GPS movement or GPS position is notify my applycation can't work with System.Drawing

This is my code in VB.NET (vs 2005)

Private Sub GPS_Position(ByVal sender As Object, ByVal pos As OpenNETCF.IO.Serial.GPS.Position) Handles _GPS.Position
Try
Me.TextBox1.Text = "asss" '<--- throw ex
Me.txtLatitud.Text = String.Format("Latitud: {0}", pos.Latitude_Sexagesimal)
Me.txtLongitud.Text = String.Format("Latitud: {0}", pos.Longitude_Sexagesimal)
Catch ex As Exception
MessageBox.Show(ex.Message)
End Try
End Sub

A first chance exception of type 'System.NotSupportedException' occurred in System.Drawing.dll
Run-time exception thrown : System.NotSupportedException - No se puede mostrar un mensaje de error porque no se pudo encontrar un ensamblado de recursos opcional que lo contiene

---StackTrace
"en Microsoft.AGL.Common.MISC.HandleAr()
en System.Windows.Forms.Control.get_Text()
en System.Windows.Forms.Control.set_Text()
en Localizacion.Form1.GPS_Position()
en OpenNETCF.IO.Serial.GPS.GPS.OnPosition()
en OpenNETCF.IO.Serial.GPS.GPS.nmea()
en OpenNETCF.IO.Serial.GPS.GPS.GPS_DataReceived()
en OpenNETCF.IO.Serial.GPS.GPS.OnDataReceived()
en OpenNETCF.IO.Serial.GPS.GPS.cp_DataReceived()
en OpenNETCF.IO.Serial.Port.CommEventThread()

Wath can I do?? :(

Hablo con la sabiduria que me da el fracaso. Roberto Iniesta.

Hi! I've a solution for my problem, need to use delegates.

On this page you can si haow to send messages to main interface from serial thread

http://forums.microsoft.com/msdn/showpost.aspx?postid=21486&siteid=1

my new code is the following one:

Private PositionDelegate As OpenNETCF.IO.Serial.GPS.GPS.PositionEventHandler

Private Sub Form1_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles MyBase.Load
PositionDelegate = New OpenNETCF.IO.Serial.GPS.GPS.PositionEventHandler(AddressOf Posicion)
End Sub

Private Sub Posicion(ByVal sender As Object, ByVal pos As OpenNETCF.IO.Serial.GPS.Position)
Try
txtLatitud.Text = String.Format("Latitud: {0}", pos.Latitude_Sexagesimal)
txtLongitud.Text = String.Format("Longitud: {0}", pos.Longitude_Sexagesimal)
Catch ex As Exception
MessageBox.Show(ex.Message)
End Try
End Sub

Private Sub GPS_Position(ByVal sender As Object, ByVal pos As OpenNETCF.IO.Serial.GPS.Position) Handles _GPS.Position
Try
Invoke(PositionDelegate, New Object() {Me, pos})
Catch ex As Exception
MessageBox.Show(ex.Message)
End Try
End Sub



Hablo con la sabiduria que me da el fracaso. Roberto Iniesta.

I think this code came from a Microsoft sample, but I don't know who to report it to. Since this library depends on it, too, I thought perhaps you would be interested as well.

In DegreesMinutesSeconds.cs in method ToDecimalDegrees():

return val * (absDegrees / degrees);

I'm getting a divide by zero exception here. Why I'm getting it I'm not certain, since it's coming from the intermediate driver. The odd thing is that it doesn't happen in the emulator, only on my Axim X51v.

Either way, it's possible for you to be at 0 degrees (ok, it's pretty unlikely, but possible). It strikes me that this can all be avoided by not trying to be clever with absDegrees / degrees and just using a conditional block. It's less clever, but more readable and it removes the possibility of the math exception.

Now, why precisely I am getting this I don't know. I am using the File driver, and the file only contains one line, a $GPRMC message that has coordinates that are clearly not zero. I almost wonder if there's something wrong about the way samples.Location is calling the intermediate driver ..... perhaps it should not be trying to interpret the $GPRMC message until it gets a $GPGLL ....... or .... something. I'll try to get to the bottom of it. It may be helpful for others to try; if you would like me to send you the registry keys and test files I used to feed the GPSID just email me.