That's interesting to know. My assumption was that GPSapi.dll only shipped with devices that had internal GPS, but then I've only seen WM6.0 devices that do have GPS. It looks like the Intermediate Driver may ship with all WM5.0 and later devices. Have you got a configuration program for it? It is a device only dll, there is no desktop equivalent.(1) the .dll required seems to exist on the PDA, but not on the PC, which adds to the interest of debugging!
I actually meant the device IDE!(1) The Serial2 programme works fine under the IDE on the PC.
That's OK. It means it probably will work OK in the device IDE(2) Compiling with the non-optimised compiler produces a version which works, with 2 caveats: (a) as slow as a 1-legged dog, and (b) the size of the screen is doubled so only 1/4 of each form fits on the screen!
You must have defined the GPS array in Globals, did you do so as a byte array? "Dim GPS(0) As Byte?". If not try that as a next step.(3) The error message without the ErrorLabel is "Invalid Cast Exception"
Yes, a .NET Char is a 16bit Unicode character, a Byte is an 8bit value. GPS() should be defined as a Byte array because that is what Serial2.InputArray returns.GPS is defined GPS() as char. Any difference between that and byte?
Yes but many times faster and so more efficient as it is closer to native code than Basic4ppc.(I suspect the internal GPS stuff has to do this anyway before handing it over to GPS libraries)
GPSSerial works on both desktop and device but probably not through a virtual COM port provided by the Windows GPS Intermediate Driver due to an incompatibility between that and the .NET SerialPort class (this was why GPSDriver was developed). The reason for writing GPSSerial was to be able to take an app from my device using GPSDriver and run it on my desktop (actually my EEE PC for portability) virtually unchanged.as things function without change on the desktop too
GPSSerial has a DataAge property that tells you the age of the parsed data and also an age parameter to GPSSerial.GetGpsData that will not return any valid data older than age.It means that I can cope with knowing when there is a break in traffic
Hmmm!. I originally put raw NMEA data access into GPSSerial for debugging purposes and for the same reason implemented my GPSDriverNMEA library when I was degugging the original code that became the official GPSDriver library. Looking again now I realise I may have missed an opportunity to provide a "middle ground" option between totally raw data and completely parsed data that returned complete NMEA sentences. I might take another look at that.The only thing that would be handy would be a Serial2.GetLines(Lines()) with dim Lines() as string, to save breaking up large chunks of characters.
I use C# and Visual Studio 2005. You can also use VB.NET and SharpDevelop is a free .NET development environment that some here use - but I never have. If you wanted to play I would try C# and SharpDevelop. As all the .NET languages run on the same framework the learning curve is that of the facilities offered by the framework (effectively the runtime libraries) rather than that of the syntax of tany of the languages. To me C# is better than VB as it is more elegant and less verbose.What are the .dlls written in?