OpenNETCF Smart Device Framework 2.0 Beta 1#

Smart Device Framework 2.0 Beta 1 from OpenNETCF has been released.  We have worked really hard to getting this ready and the redistributables for Beta 1 are now available.  The SDF2.0 documentation is also available online.

A lot of work was done throughout the whole SDF but some of the major changes was supporting the the new design time framework for controls for Visual Studio 2005.  Throughout the process we also decided to change some of the class names that ended with 'Ex' to '2'.  For example, OpenNETCF.Windows.Forms.ProgressBarEx is now OpenNETCF.Windows.Forms.ProgressBar2.

There are still some remaing minor issues with some controls and design time support for Visual Studio 2005.  See this post for some of those issues.

Also, check out the new Licensing Class available in the SDF 2.0.  It works the same as the full framework class so if you are looking to license your .NETCF application to your users this will help.

In a future post I will be writing some tips for creating and migrating controls for Visual Studio 2005.


Wednesday, January 25, 2006 1:00:21 PM (Eastern Standard Time, UTC-05:00) #    Comments [0]  | 

 

Designing Pocket PC Applications for Stylus-Free Usage - Sample Application#

I have been asked a few times for the source code that accompanies my latest article so here it is.  It's for .NET CF V2 and Visual Studio 2005.  Also, here is a link to the article so you can view in fulll screen instead of the small frame.

MileageTracking.zip (33.64 KB)
Tuesday, October 11, 2005 11:48:55 PM (Eastern Daylight Time, UTC-04:00) #    Comments [0]  | 

 

WebBrowser Control Part II#

As said in my previous post the SDF WebBrowser Control wraps HTMLView.dll which PocketIE uses.  On WindowsCE the SDF WebBrowser control will not browse to a http:// URLs but will work on a PocketPC.  .NET Compact Framework 2.0 has a standard WebBrowser control similar to the WebBrowser control in the Smart Device Framework. .NETCF 2.0 WebBrowser Control will work on both PocketPC and WindowsCE, but on WindowsCE you will need the Pro License and have the control as part of your OS image.

In my previous post I stated you could wrap IWebBrowser2.  Well, IWebBrowser2 is actually an interface so what you will have to wrap is shdocvw.dll.  IWebBrowser2 allows your application to create an instance of the WebBrowser control using ActiveX.  Of course this is all done in C++ using Embedded Visual C.

Sergey Bogdanov has actually done a lot of the work to get web browsing working in WindowsCE.  Download the sample project here

Here are some update links to get you started if you want some more technical information on the browser in CE. 


Wednesday, September 14, 2005 10:01:06 AM (Eastern Daylight Time, UTC-04:00) #    Comments [1]  | 

 

OpenNETCF SDF WebBrowser Control#

The OpenNETCF SDF has a WebBrowser control under the OpenNETCF.Windows.Forms namespace.  There have been some "issues" with the WebBrowser control and using it on a WindowsCE device using .NETCF 1.0.  The WebBrowser control works on Pocket PC devices but does have limited functionality on Windows CE devices. 

First some background on the control.  The SDF WebBrowser control is a wrapper to the HTMLView.dll that come with PocketPCs.  This gives the functionality to browse URLs as long as you have connectivity.  For more technical information see here.  The SDF WebBrowser control wraps this functionality so it can be used in managed code and has design time support.  

On windows CE devices you cannot browse to external URLs but you can browse to files on the local device.  For example if you set the URL property on the WebBrowser control to file://[YOUR FILE] you should be able to see your file.  The reason for this is, WindowsCE uses HTMLView for Help files so it has limited functionality on a WindowsCE device. 

To have a full blown WebBrowser on windows CE there are a few things you have to do.  First, you have to pay for a Pro License which includes a full blown IE browser.  You may be able to get the Core license which has a scaled down version of IE but I'm not 100% sure.  Check here for more details or contact your distribution partner for more information. Second, you have to wrap IWebBrowser2 to be p/invoked from managed code and to display the unmanaged browser window within your unmanaged application.  This is not an easy task but is possible.

So basically, the OpenNETCF SDF WebBrowser control is fully functional and does not have any "bugs" or "issues" since we rely on the underlying OS.

Here are a few links to that may be of help if you attempt to wrap IWebBrowser2.  NOTE: There is an article on MSDN that goes through a C++ sample which is useful. I don't have the link but will post if I find it.

WINCE
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceshdoc/html/ceconAddingInternetBrowsingFunctionalityToYourApplication.asp
http://msdn.microsoft.com/library/en-us/dnce30/html/iece30.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetcomp/html/HostingANativeWindowsControl.asp

Desktop - http://msdn.microsoft.com/workshop/browser/webbrowser/browser_control_node_entry.asp


Tuesday, September 13, 2005 3:06:53 PM (Eastern Daylight Time, UTC-04:00) #    Comments [0]  | 

 

TCPClient.ReceiveBufferSize#

A couple of months ago I started creating a socket wrapper to make creating socket connections a little easier.  Yesterday, I started working on it again and came across a 'bug' when setting the ReceiveBufferSize.  I wanted to make the SendBufferSize and ReceiveBufferSize changeble by the user. Here is the code:

// Set these socket options
this.tcpClient.SendBufferSize = this.sendBufferSize;
this.tcpClient.ReceiveBufferSize = this.receiveBufferSize;

The error returned when setting ReceiveBufferSize was "An unknown, invalid, or unsupported option or level was specified in a getsockopt or setsockopt call"

Upon further investigation (and with help from Sandeep P.) by searching getsockopt and setsockopt from the error message I came accross this:

SO_RCVBUF int Specifies the total per-socket buffer space reserved for receives.
For Windows CE .NET 4.1 and later, the default buffer space is set to 8192 bytes. You can change the per-socket buffer space by calling setsockopt.
Note   This option is only supported for SOCK_DGRAM sockets.

So, basically Windows CE only supports setting the ReceiveBufferSize if you are using Datagrams (or UDP) and since I'm using TCP .NETCF throws the error.  It's not really an bug, but something not supported by the underlying OS (Windows CE) which VS.NET2005 IDE let's you see using IntelliSense. Don't get me wrong IntelliSense has been greatly improved for Compact Framework (see here) and TCPClient.ReceiveBufferSize I'm sure is rarely used.

So if you're doing some socket programming on a device be aware of this.  8K of buffer size should be big enough, but just be aware of this when using TCPClient.  

Note: On the desktop setting ReceiveBufferSize does not throw an exception. 


Thursday, August 18, 2005 4:47:34 PM (Eastern Daylight Time, UTC-04:00) #    Comments [0]  | 

 

All content © 2008, Mark Arteaga
Related Sites
Archives
Sitemap
Disclaimer

Powered by: newtelligence dasBlog 1.9.7174.0

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

Send mail to the author(s) E-mail

Theme design by Jelle Druyts