In the authors' words, "Our main aim in writing this book is to write the most advanced book yet available on Microsoft Visual Basic." Written from the perspective of the professional Visual Basic developer, "Advanced Microsoft Visual Basic, 2ND Edition" explores all the possibilities open to a developer using Visual Basic as his or her primary client/server development tool. New to this edition is material on new data access technologies, accessibility issues for the physically challenged, increased support for IIS, BackOffice and mixed language programming, and enterprise support for server side objects, such as the component gallery and Microsoft Transaction Server. The accompanying CD-ROM contains sample code and valuable utilities developed and tested by the authors, The Mandelbrot Set.
Read an Excerpt
Chapter 5: Developing Application in Windows CE WIN32 API
Microsoft estimates that there are some 4.76 million professional developers worldwide, a large number of which currently program Win32 using languages such as Visual C++ or Visual Basic. Of this number, it is estimated that around 300,000 are embedded developers (developers who write software to control hardware devices). For this reason, basing Windows CE on the Win32 API provides a sound foundation from which to build. Don't be fooled, though; if there were not such a large user base, it is feasible that Windows CE might have been based on some other API. With a development team of around 700 on Windows CE alone, Microsoft is more than capable of achieving this!
The API set for Windows CE is very much scaled down from the desktop and server operating systems. Whereas Windows NT has around 10,000 API routines, Windows CE has a mere 1200. This isn't a bad thing, because the new versions are highly optimized and the duplicated functions that exist in the Windows NT/9x operating systems have been removed. If you will be porting from an existing application to Windows CE and you use Win32 API calls in your code, I hope you will have converted to the newer calls. For example, where a function Foo and FooEx exists you should be using the newer FooEx version. If you haven't then never mind, the conversion should not be too painful, although you will need to convert because the older routines do not exist in Windows CE. The subset of API calls should be sufficient for most tasks. Remember that Windows CE has been built with a "ground-up" approach, so the immediate requirements have been dealt withfirst. As the operating system's development progresses, new calls will be added as required by users.
The Object Store
The object store is the collective name for the data storage elements within the Windows CE operating system. On the HPC, physical RAM is divided into application memory space and emulated disk space. The disk portion of RAM is Where the object store resides. The object store is home for such items as the Registry, Windows CE databases, user files, and applications. Applications that are built into the operating system core are actually held in ROM and cannot be accessed using the object store API calls. A default Registry is also stored in ROM and therefore it, too, cannot be accessed using the API.
An important feature within the Windows CE object store is its transaction mechanism. Microsoft stipulates that if for any reason data cannot be written to the object store, the whole operation will be canceled. This mechanism works on a record level-for example, if you are writing 10 records to a database and a power loss occurs during record 8, records 1 to 7 will have been saved, but no fields in record 8 will be. This applies to the Registry and file system in the same way.
The object store comprises three elements: the database, the Registry, and the file system. These are explained in the following sections.
The Windows CE database
The Windows CE database model provides storage for non-relational data. You can create any number of databases, each with a unique ID. Each database can contain any number of records (depending on memory). A database record can have any number of fields and these fields can be of type Integer, String, Date or Byte array (also known as Binary Large Objects, or BLOBs). Each database record has its own unique ID and this ID is unique across all databases. Database records can contain up to four index keys, which can be used, for searching and sorting. In addition, a field tan be indexed either in ascending or descending order.
The records held in a database need not be related; for example, you can store contact information in some records and product price details in another record within the same database. A number of API functions 'exist to manipulate databases-these are covered in more detail later in this chapter. Microsoft has recently released a beta version of ActiveX Data Objects, (ADO) which provides full connectivity to relational databases like Microsoft SQL Server and Microsoft Access. ADO makes it possible to manipulate data in a relational database using the standard SQL to which most Windows developers are accustomed.
Even though the standard database features might sound rather limited, you should remember the kind of application for which Windows CE is designed. If you think in terms of the OEM developing a household device, you'll see that the functionality is more than adequate.
The Windows CE file system has a host of functions with which to access file-based data. The file functions that exist in the normal development environment are not supported by Windows CE; instead, new functions have been provided in the API. Most Windows CE devices presently use the FAT-based file systems. However, the operating system can support installable file systems. For most current Windows CE applications, file access will be to RAM rather than to a physical hard disk, although in terms of coding the difference is transparent.
The file system can be browsed and manipulated using the Mobile Devices application that is installed as part of the Windows CE Services. This application is rather like Windows Explorer and works in the same way. You can even copy, move, or paste files between Windows Explorer and mobile devices.
Windows CE, like Windows NT/9x, uses the Registry to store system and application configuration data. However, the Windows NT Registry consists of several files, or hives, that together form the entire Registry. Windows CE does not support hives - the entire Registry is stored as a single file. The Registry file is stored in ROM and is copied to RAM when the device is booted. You should bear in mind that a Windows CE device will probably boot only after the power supply has been connected. Normally, when the device is turned off, backup batteries retain RAM memory. This design allows a feature that Microsoft calls "Instant On" - that is, the device is immediately available when switched on. It is possible to write software that saves the Registry file to a nonvolatile storage device. Given the nature of the power supply for many prospective Windows CE devices, however, user data can be lost in almost any situation. Losing the Registry should not cause too many problems for an application, because more than likely any user files will be lost as well. A good design principle to employ might be for an application to back up the Registry to non-volatile storage whenever the user chooses to backup his or her files.
The RAM copy of the Registry can be accessed using the Win32 API, or Visual Basic programmers can use the built-in Registry functions. Desktop applications written in Visual Basic often need to use the API in order to access different Registry keys; for example, global application data would probably need to be saved to HKEY_LOCAL_MACHINE, whereas user specific settings would be better located under HKEY_CURRENT_USER, For Visual Basic programmers, a COM DLL is required to access keys or paths other than the default one that Visual Basic accesses: BICEY_CURRENT_USER\Software\VR,and VBA Program Settings.
ActiveSync is the technology introduced with Windows CE 2 that provides an easy way to keep data synchronized between a mobile device and a desktop PC. ActiveSync allows you to keep databases synchronized between your device and the desktop PC in much the same way as replication occurs between SQL Server databases. Conflict resolution is handled for you once you set up the required configuration. The synchronization operations can be performed using the Mobile Devices folder menu options, but you can also use certain API functions to control the process. The ActiveSync API calls are listed later in this chapter in the section "Visual Basic Development."
Processes and Threads Because Windows CE is based on the Win32 API, it has full support for processes and threads. Visual C++ (and even Visual Basic 5) programmers might already be familiar with these concepts, Essentially, a process consists of one or more threads of execution, where a thread is the smallest unit of execution. Windows CE allows a maximum of 32 processes; however, the number of threads is limited only by available memory. It i's possible to create threads using Visual Basic, but this is not advisable because the Visual Basic run time is not "thread safe" - that is, if two threads within the same process were to call a Visual Basic routine at the same time, some fairly nasty things might happen. However, because I know that some of you will try it, and because it is very applicable to C++ development, the section "Visual Basic Development" later in this chapter describes the thread-handling API calls. If you have trouble remembering the difference between processes and threads, you might find the diagram in Figure 5-3 helpful....
Table of ContentsForeword ..... xxi
Preface ..... xxiii
Using the Companion CD ..... xxvii
Chapter 1: On Error Goto Hell ..... 1
Chapter 2: Taking Care of Business (Objects) ..... 72
Chapter 3: IIS This a Template I See Before Me? ..... 108
Chapter 4: Programming With Variants ..... 132
Chapter 5: Developing Applications in Windows CE ..... 164
Chapter 6: Staying in Control ..... 215
Chapter 7: Minutiae ..... 274
Chapter 8: Visual Basic Programmer's Guide to Successful Dating ..... 342
Chapter 9: "Well, At Least it Compiled OK!" ..... 398
Chapter 10: Starting with Bases Loaded ..... 430
Chapter 11: Mixing Languages with Visual Studio ..... 455
Chapter 12: Databases Are for Dorks 00 It Once and Forget It Forever ..... 491
Chapter 13: Programming on Purposec ..... 540
Chapter 14: Didn't I Write That Function Last Week? ..... 586
Chapter 15: Now to Juggle 30 Balls Blindfolded ..... 650
Chapter 16: Accessibility in Visual Basic ..... 703
Chapter 17: Three Steps to Employment Heaven ..... 740
Appendix A: Coding Conventions ..... 787
Appendix B: Sample Answers to the Technical Test in Chapter 17 ..... 807
Appendix C: TMS Developer's Framework ..... 817
Appendix D: Visual Datescope 2000 and VBA2000 ..... 823
Appendix E: Keeping Current with TMS ..... 827
Other Newsgroups ..... 828
Index ..... 830