| The list of features not supported by eVB is fairly extensive , but don't let that discourage you. Many of the programming techniques you know from VB6 will transfer, and I'll give you workaround tips for most of the bigger issues. GoTo and Error Handling Error handling in Visual Basic has always been a sore point with many developers, and eVB further limits what you can do. The only On Error option in eVB is On Error Resume Next. You can't have an error handler at the bottom of a procedure and simply use a GoTo to jump to it; in fact, you can't use GoTo at all in eVB. Instead, you must use line-by-line error handling. You have to be aware of what types of errors a code line might throw when you write it, because you'll likely have to check for and handle each one. To minimize the amount of error-handling code you need, try to validate most data that you pass into functions to ensure that data that may cause an error never gets there. Another good catchall for development and testing is to write a generic error trap at the end of your functions, something like this: Public Function MyFunction() As Boolean On Error Resume Next ' Implementation code If Err.Number <> 0 Then MsgBox Err.Description, vbCritical, "MyFunction Error" End If End Function This displays a message box if any error occurs in the function and helps you to pinpoint both the location and the type of error for which you may need to add a handler. Other unsupported error-handling features are Erl and Resume. New, CreateObject, and Events The New operator isn't supported in eVB. All object creation must be done with CreateObject or CreateObjectWithEvents and, as the latter suggests, With Events isn't supported for variable declarations. Creating Objects with Events To create an object and still be able to handle that object's event, you must use the CreateObjectWithEvents method, which takes two parameters: the object's ProgID and the Event prefix you want to use. For example, if you want to create a WinSock control and be able to handle its events, you would use something like the following: Set objSocket = CreateObjectWithEvents("Winsock.Winsock", "MySocket_") This tells eVB to create the object and that all the object's events will start with MySocket_. For example, the Connect event for our created socket would be MySocket_Connect(). Let's look at an example that you can actually run in eVB. You can create a WinSock control and immediately try to connect with it. Because you haven't told it where to connect to, the call will fail and fire the WinSock's Error event, which you trap in MySocket_Error: Sub Main() On Error Resume Next Dim objSocket As WinSock.WinSock Dim vData As String Set objSocket = CreateObjectWithEvents("Winsock.Winsock", "MySocket_") objSocket.Connect End Sub Public Sub MySocket_Error(Number As Integer, Description As String) MsgBox Description End Sub Chapter 5, "Using the Windows CE WinSock for IR Communication," covers the details of socket programming; this snippet just serves as an example of using CreateObjectWithEvents. CreateObject's Memory Leak To add to the challenge of creating objects, the Microsoft implementation of CreateObject in eVB has a memory leak. The leak boils down to this: when you call CreateObject to create any object with an enumeration (which almost all objects have), eVB allocates space for that enumeration. When the variable goes out of scope or is set equal to Nothing, the memory isn't released. This means that every call to CreateObject will consume enough space for the enumeration(s) and not release that space until your application ends. The more enumerations the object has and the more times you create it, the worse the problem becomes. No fix has been made publicly available by Microsoft, although Knowledge Base article Q286504, "eVB CreateObject Function Causes Memory Leak," acknowledges that it does exist. This means that you must program defensively against this leak. The best method that I've come up with is to be sure that you create an object only once for your application and to reuse that object rather than create a new one every time. Chapter 3, "Manipulating Files," gives more information and a full working example of a workaround for the CreateObject leak. No Class Support eVB projects support only two types of files: forms and standard modules. You can't create a Class Module, nor can you create your own classes with eVB. This means that many programming techniques and styles must be "unlearned." No Validate Events eVB controls, such as the TextBox, don't have Validate events, so any validation must be achieved in another way. One option is with the LostFocus event. Here is one way to validate a TextBox to ensure that it has numeric data: Private Sub Text1_LostFocus() If Len(Text1.Text) = 0 Then Exit Sub If Not IsNumeric(Text1.Text) Then MsgBox "Invalid Data" End If End Sub Menus Are Different eVB has no Menu Editor like VB6's, but the Pocket PC doesn't support menuing the way a desktop PC does. Instead, eVB provides a MenuBar control, which is covered in Chapter 4, "Working with Menu Controls for Pocket PC," for the application menus. Pop-up menus aren't supported by eVB at all, but Chapter 9, "Harnessing the Windows CE API," shows an implementation that mimics their behavior. Optional Isn't an Option eVB doesn't support creating functions with optional parameters (although you can call C++ functions with optional parameters). This can make extending functions without breaking the interface difficult at best. One option that you can use is to pass an array as the last parameter to a function, and simply add to the array for additional parameters. For example, consider the following function that takes a Grid control, an ADOCE recordset, and a variant array, and then formats and fills the control: Public Function DisplayRecords(objGrid As GRIDLibCtl.GridCtrl, _ adoRecordSet As Variant, _ OptParams() As Variant) '----------------------------------------------------- '----- MetaData is a 1 dimensional array '----- Element 0: Maximum column width '----- Element 1: Number of rows to preserve on redraw '----- Element 2: Row Height '----- Element 3: Minimum column width '----------------------------------------------------- Dim intRowHeight As Integer Dim intMaxWidth As Integer Dim intMinWidth As Integer Dim intPreserveRows As Integer If OptParams(0) <> 0 Then intMaxWidth = OptParams(0) End If Select Case UBound(OptParams) Case 1 intPreserveRows = OptParams(1) Case 2 intPreserveRows = OptParams(1) If OptParams(2) <> 0 Then intRowHeight = OptParams(2) End If Case 3 intPreserveRows = OptParams(1) If OptParams(2) <> 0 Then intRowHeight = OptParams(2) End If If OptParams(3) <> 0 Then intMinWidth = OptParams(3) End Select ' Implementation Code End Function I've left out the implementation code because I want to focus on the variant array of "optional" parameters. I've defined them as MaxColWidth, PreserveRows, RowHeight, and MaxColWidth. By using a Select Case on the upper bound of the array, the caller can opt not to use all the parameters. For example, to call it with only MaxColWidth and PreserveRows, you could use this: Public Sub Main Dim vParams(3) As Variant vParams(0) = 1200 vParams(1) = 1 DisplayRecords grdMyGrid, objRs, vParams End Sub The limitations are that you can't omit a variable in the middle of the list, and you must provide at least MaxColWidth. Both of these could be fixed with some ingenuity if you need to get past these limitations, but I'll leave that as an exercise. ActiveX Controls, DLLs, and EXEs Another substantial limitation of eVB is that it doesn't support the ability to create ActiveX controls (often called user controls ), ActiveX DLLs, or ActiveX executables. To make any of these, you have to use eVC. Control Arrays Control arrays aren't supported in eVB, so writing common code for multiple controls is more challenging. Usually moving the implementation to a single function and having all controls call that function is the easiest way to handle this problem: Private Sub Text1_Change() HandleTextChange Text1 End Sub Private Sub Text2_Change() HandleTextChange Text2 End Sub Private Sub Text3_Change() HandleTextChange Text3 End Sub Private Sub HandleTextChange(txtControl As TextBox) MsgBox txtControl.Name & " changed" End Sub User-Defined Data Types eVB doesn't support user-defined types, also called UDTs or structures. This makes calling API calls that require UDTs difficult. Chapter 9 provides a workaround and samples for getting past this limitation. With Blocks Using a With block for shortcut coding isn't supported in eVB. The following code With frmMain .Caption = "My Form" .Left = (Screen.Width - .Width) / 2 .Top = (Screen.Height - .Height) / 2 End With must be rewritten like this: frmMain.Caption = "My Form" frmMain.Left = (Screen.Width - frmMain.Width) / 2 frmMain.Top = (Screen.Height - frmMain.Height) / 2 Modal Forms You can't show a form modally in eVB. This means that if you have an application with multiple forms, be aware that the user may change to another form at any point, sometimes by accidentally clicking outside the current window if it isn't full screen. To help avoid this, use only full-screen forms and set the Visible property of background forms to False. Another option is to use only a single form for the entire application and use frames for each screen the user will view.  | 
