 |
|
Over the years, the Windows platform has become an extremely complete, but also extremely complicated, software environment to program against. Dozens of new services, subsystems, and APIs have been added at a stunning rate by the prolific teams Microsoft to the delight of many categories of niche-oriented programmers, but with an obvious downside. There is no such profession as "Windows developer" anymore: Mastering (or even possessing a working knowledge of) the whole Platform SDK became simply too time-consuming for anybody, assuming he/she also plans to get some real work done. Everyone must specialize in a selected few areas and keep up-to-speed with the new bits emerging in those subsectors of the huge Win32 universe.
Nevertheless, the majority of the world is not made up of framework designers, operating systems specialists, and vertical utility producers. Many projects require their implementers to be able to work with a variety of modern technologies, typically integrating them at a fairly high level and mixing them with a nontrivial amount of business logic. The need to focus the attention and the effort on the business logic more than on the purely technological side of software has been the driving force behind the move of thousands of developers from the classic tools and languages (let's talk clear: C and C++) to Visual Basic. And tough as this can be to say for a once-diehard C++ developer, they were perfectly right. While limited and substantially unfit for a long list of uses, the ever debated Visual Basic actually guarantees the highest productivity rate for an even longer list of scenarios, especially with the latest versions (the real boom dates back to version 4.0) and their impressive bag of features and capabilities.
Born as a toy for quick-and-dirty UI prototyping and for simplistic Windows-based applications a long time ago, VB has seen a remarkable lift over time, to the point of nearly standing the comparison of Visual C++ and Delphi in terms of capabilities nowadays, while still emerging out of the crowd when it comes to rapid development and graphical application design. Despite the growing number of features, the entire set of fundamental concepts and resources can still pretty much be exposed in a single tome, unlike the Visual C++ counterpart where encyclopedias represent the most common learning path for those who wish to establish a profession in the field.
The only pitfall in this seemingly perfect world is finding one such bible to digest page by page on the market...or better, it was until Francesco Balena decided to give this project a shot. He dedicated almost a year of hard work to download his extensive knowledge and experience in the field onto paper, and succeeded in cranking out a really compelling manual that every beginner (and not-so-beginner) should buy. Programming Visual Basic 6.0 wisely mixes no-nonsense knowledge in a very easy-to-learn manner with tips and guidelines that are likely to prove extremely useful on a daily basis. Add to this the limpid writing style of a veteran magazine author (Francesco is known to most VB technicians for his frequent contributions to the Visual Basic Programmers Journal) and you'll realize how this excellent book really lives up to the expectations set by the title. From common controls to ActiveX controls, from classes and objects to ADO programming, the chapters touch pretty much all of the aspects of professional software development. A must for any serious VB developer.
-- Davide Marcato (http://www.DavideMarcato.com)
Part I: The Basics
Chapter 1: First Steps with Microsoft Visual Basic 6
Chapter 2: Introduction to Forms
Chapter 3: Intrinsic Controls
Chapter 4: Variables and Procedures
Chapter 5: The Visual Basic for Applications and Visual Basic
Libraries
Chapter 6: Classes and Objects
Chapter 7: Events, Polymorphism, and Inheritance
Chapter 8: Databases
Part II: The User Interface
Chapter 9: Advanced Forms and Dialogs
Chapter 10: Windows Common Controls: Part I
Chapter 11: Windows Common Controls: Part II
Chapter 12: Other ActiveX Controls
Part III: Database Programming
Chapter 13: The ADO Object Model
Chapter 14: ADO At Work
Chapter 15: Tables and Reports
Part IV: ActiveX Programming
Chapter 16: ActiveX Components
Chapter 17: ActiveX Controls
Chapter 18: ADO Components
Part V: Internet Programming
Chapter 19: Dynamic HTML Applications
Chapter 20: Internet Information Server Applications
Appendix: Windows API Functions
("Chapter 16 -- ActiveX Components", page 900)
"Run As This User.
"This option lets you assign a specific user's security credentials to the component. In a production environment, this is often the best choice because only one instance of a MultiUse component will be created. In practice, the best thing to do is create a new user just for this purpose, give it proper access rights to system resources, and then let the component run with this new user's credentials. In this way, you can modify the access rights of one or more components by simply changing the rights of this fictitious user. It's important this user be assigned the permission to log on as a batch job, otherwise the logon process that invisibly starts when the component is launched will fail. DCOMCNFG automatically assigns this right to the user in the Run As This User field, and you only have to avoid accidentally revoking this right from within the Windows NT User Manager utility.
"Implementing a Callback Technique
"An area in which you can greatly improve the performance of your remote component is event notification. While your ordinary event notifications work under DCOM (but not under Remote Automation), they're so inefficient that I strongly discourage you from using them. Instead, you should implement a callback technique. The callback mechanism works as follows: when the client calls a lengthy method of the component, it passes a reference to an object defined in the client itself, and the component stores this reference in a local variable. This variable is then used when the component needs to call back the client to inform it that something has occurred.
"Early-bound and late-bound callbacks
"Callback techniques have been available to Visual Basic programmers since version 4 of the language. But only late-binding callbacks were possible in Visual Basic 4. Let me describe a concrete example of the callback technique. Say that you have created a generic reusable report printing engine: any client application can instantiate it and start a print job. The server then calls back the client when the job has been completed or when an error occurs. In this scenario, the print server doesn't know at compile time the type of the object passed by the client application because different types of clients expose different classes. The component can store a reference to the client only in a variable declared using As Object, which means that the notification occurs through late binding. The client and the component must agree on the name and the syntax of a method in the class used for callback. Any syntax error in the client or in the server will manifest itself only at run time. As you know, late binding is also less efficient than early binding, so you should avoid it if possible. In Visual Basic 5 and 6, the Implements keyword allows you to enforce a stricter contract between the client and the component. The component includes a PublicNotCreatable class that defines the callback interface, and any client that wants to receive callback notifications from the server has to expose a PublicNotCreatable class that implements that interface. The component can therefore store a reference to such an object in a specific variable, and all the notifications use early binding."
("Chapter 4 -- Variables and Procedures", page 193)
"Passing Private types
"There are restrictions when passing Private objects to a procedure, where a private object is defined in your application but not visible outside it. Private objects are those defined by classes whose Instancing property is set to 1-Private, or objects exposed such as App, Clipboard, Screen, and Printer. In general, you can neither include such private objects among the arguments of a procedure nor use them as the return value of a function if the procedure can be called from another application through COM. This restriction makes perfect sense. COM arbitrates the exchange of information between the application that provides the object and the programs that use it. COM is able to deal with all the basic data types supported by Visual Basic and with all the Public objects defined by any program in the Windows environment. On the other hand, COM is unable to pass information in a format that is defined within a program, such as a Private class, as you can see in the code snippet on the next page."
| Readability |
|
| Originality |
|
| Organization |
|
| Accuracy |
|
| Consistency |
|
| Depth |
|
| Timeliness |
|
| Editing |
|
| Design |
|
| Overall Value |
|
Explanation of ERCB rating scale: No stars = unacceptable, 1 Star = marginal, 2 Stars = average, 3 Stars = above average, 4 Stars = exceptional.