[ANN] OpenNETCF.Net revisions

[Paul G. Tobey [eMVP]]

Hi,

For those of you using OpenNETCF.Net in version 1.4 of the SDF, you'll find
new versions of several files in the vault at www.opennetcf.org,
OpenNETCF/SDF/v1.4/OpenNETCF.Net. Note that the source and binary packages
have not been updated, so you will need to grab individual files: Enums.cs,
AccessPointCollection.cs, OpenNETCF.Net.csdproj, EAP.cs (new file),
Adapter.cs, ChangeLog.txt.

The API for wireless control has been reworked to simplify making a user
interface similar to what WZC does. That is, you can set any authentication
type, any encryption type, use EAP for authentication, etc. This has been
tested in CE 4.2 with WPA, WPA-PSK, TKIP, and PEAP.

New methods now exist in Adapter for connecting to SSIDs with all of these
parameters and the old SetWirelessSettings() and SetWirelessSettingsEx()
methods have been deprecated (although using them will only generate a
warning, not an error, for now). The new methods are careful to take care
of the preferred SSID list. The new interface is made through the new
SetWirelessSettingsAddEx() methods. There is also a new method,
RemoveWirelessSettings() for removing an SSID from the preferred list of an
adapter.

A sample program demonstrating how to use the methods can be found in the
vault at OpenNETCF/Samples/WZCReplacement.

 

[Tomppa]

Cool! Will this get into SDF 2.0?

 

[Chris Tacke, MVP]

Of course it will.

-Chris

Cool! Will this get into SDF 2.0?

 

[Markus Humm]

Hello,

seems to be usefull, but what about fixing thos crashes of the close
function of the serial.io class which occur on the HP iPaq rx1950?

Greetings

Markus

 

[Chris Tacke, MVP]

Serial has nothing to do with the .Net namespace.

Fixing the bug assumes that we have a 1950 to work with (I defintitely
don't) plus CF 2.0 has serial support so don't expect us to do much with the
serial stuff we had in 1.x. In fact SDF 2.0 drops the serial classes
altogether. The source for our 1.x library is readily available for those
with the need to make changes and improvements.

-Chris

 

[Paul G. Tobey [eMVP]]

And I'm sure the consulting group work apply some time and effort, if you'd
loan them a device and pick up the tab. We all have other jobs...

Paul T.

 

[Markus Humm]

And I'm sure the consulting group work apply some time and effort, if you'd
loan them a device and pick up the tab. We all have other jobs...

Yes, you have other jobs. But on the other hand you all want to release
good software as well...

Okay, I see that you're not too eager about gixing it, I hadn't awaited
it in the first place.

But: why should I deploy CF 2.0 (whose serial IO class has still some
errors as well as far as I heared or read here) to Wm2003 devices if I
only need serial IO of it? This question has nobody answered to me so far.

Greetings

Markus

 

[Guest]

Yes, you have other jobs. But on the other hand you all want to release

good software as well...

Sure. We try to fix what we can. In this case I don't have a device to
test with, I'm certainly not going to buy one, and you've not proven to me
it's a software problem.

But: why should I deploy CF 2.0 (whose serial IO class has still some
errors as well as far as I heared or read here) to Wm2003 devices if I
only need serial IO of it? This question has nobody answered to me so far.

Because you're the only one who can answer why you might upgrade. Generall
y the reason to upgrade anything is because a newer version has a feature
you want. In this case you might upgrade to use the serial components
because you evidently can't or won't debug the code you already have.

I have yet to see anything that definitively tells me there's a bug in
either the SDF or CF code. I'm usign it in production environments, and I
know many others that are was well, and all without incident. If it works
on all devices but one, that's an indicator to me that the driver
implementation on the one device is lacking.

-Chris

 

[Markus Humm]

Sure. We try to fix what we can. In this case I don't have a device to
test with, I'm certainly not going to buy one, and you've not proven to me
it's a software problem.

I do acknowledge that. And yes, to buy a device only for that would be
expensive (okay, often one can lend such devices from HP partners if you
tell them you've a big project and need them for evaluation).

Because you're the only one who can answer why you might upgrade. Generall
y the reason to upgrade anything is because a newer version has a feature
you want. In this case you might upgrade to use the serial components
because you evidently can't or won't debug the code you already have.

That would be an answer, but installing the whole 2.0 only for the
serial class would be a big waste of space which is limited on those
devices. And the other point is: this would be to have installed on the
windows directory which doesn't reside on a SD crad. So if the accu goes
dry on WM 2003 devices, CF 2.0 will be lost, but our app. still sitting
on the sd card, but now wincing on startup because the needed cf 2.0
isn't available... (bad for a device used by service technicians once in
a while)

I have yet to see anything that definitively tells me there's a bug in
either the SDF or CF code. I'm usign it in production environments, and I
know many others that are was well, and all without incident. If it works
on all devices but one, that's an indicator to me that the driver
implementation on the one device is lacking.

I agree with that, but convice hp that it's device ha a bug might prove
even harder than convincing you to investigate this a little bit in the
SDF ;-)

Another hint is: other serial classes for cf don't have this behaviour.
e.g. Dick grier's class works for closeing the port quite well! It seems
to have some other issues our programmer isn't to keen of...

Greetings

Markus

 

[Markus Humm]

Okay, solved this one without OpenNETCF now.

Greetings

Markus

 

[Brent West]

Mark,

How did you resolve your issue?

Thanks,

Brent