An Introduction to the .NET FCL, Part 1
Pages: 1, 2
Example 1-2. Launching an application using the .NET FCL
Option Strict On
Imports System
Imports Microsoft.Win32
Imports Microsoft.VisualBasic
Public Module modMain
Public Sub Main()
Dim strExten, strProgID, strExe As String
Dim oProgID, oOpenCmd As RegistryKey
Dim strFile As String = InputBox("Enter Name" & _
" of File" & _
" to Open: ", _
"Open File", "")
If strFile = "" Then Exit Sub
' Get file extension
Dim iPos As Integer = InStrRev(strFile, ".")
Try
strExten = Mid(strFile, iPos)
Catch
MsgBox("Filename must include an extension.")
Exit Sub
End Try
' Get Programmatic Identifier
Dim oHKCR As RegistryKey = Registry.ClassesRoot
Try
oProgID = oHKCR.OpenSubkey(strExten)
strProgID = CStr(oProgID.GetValue(Nothing))
oProgID.Close()
Catch
MsgBox("File extension not found.")
Exit Sub
End Try
' Get associated application
Try
oOpenCmd = oHKCR.OpenSubkey(strProgID & _
"\shell\open\command")
strExe = CStr(oOpenCmd.GetValue(Nothing))
oOpenCmd.Close()
Catch
MsgBox("Open command key not found...")
Exit Sub
End Try
' Launch application and pass its
' filename as a parameter
iPos = InStr(1, strExe, " %1")
If iPos > 0 Then _
strExe = Left(strExe, iPos)
strExe = strExe & " " & strFile
Call Shell(strExe, AppWinStyle.NormalFocus)
End Sub
End Module
COM Automation
In place of the function-based programming using the Win32 API, COM automation represented a clear step forward. COM was a more or less object-oriented technology that held out the promise of language independence; as long as a language understood the Component Object Model, it should be able to access and take advantage of COM components.
Example 1-3 shows a VB 6 program written using COM automation that, like the programs in Examples 1-1 and 1-2, launches the application responsible for handling the data file whose name the user enters in a text box. Like the VB.NET program in Example 1-2, it is a short and fairly simple program that relies on the WScript object available from the Windows Script Host object model.
Example 1-3. Launching an application using COM automation
Option Explicit
Private Sub Main()
On Error Resume Next
Dim lPos As Long
Dim strFile As String, strExten As String
Dim strProgID As String, strExe As String
strFile = InputBox("Enter Name of File to Open: ", _
"Open File", "")
If strFile = "" Then Exit Sub
' Get file extension
lPos = InStrRev(strFile, ".")
If lPos = 0 Then
MsgBox "Filename must include an extension."
Exit Sub
Else
strExten = Mid(strFile, lPos)
End If
' Initialize WSH Shell object
Dim oShell As WshShell
Set oShell = New WshShell
' Get programmatic identifier
strProgID = oShell.RegRead("HKCR\" & strExten & "\")
If Err.Number <> 0 Then
MsgBox "File extension not found."
Exit Sub
End If
' Get associated application
strProgID = "HKCR\" & strProgID & "\shell\open\command\"
strExe = oShell.RegRead(strProgID)
If Err.Number <> 0 Then
MsgBox "Open command key not found..."
Exit Sub
End If
' Launch application and pass it
' filename as a parameter
lPos = InStr(1, strExe, " %1")
If lPos > 0 Then _
strExe = Left(strExe, lPos)
strExe = strExe & " " & strFile
oShell.Run strExe, 5, True
End Sub
Despite its substantial popularity, COM suffered from a number of limitations:
-
COM itself offered a model for binary code reuse; it did not offer a model for source code reuse. An implication of this is that, although COM offered interfaced-based inheritance (a feature that predominantly advanced programmers were interested in), it did not support code-based inheritance.
-
Although COM offered the promise of a language-independent architecture, reality often fell far short of the promise. The root of the problem was the fact that seamless interoperability with COM presupposed that each language was able to create and manipulate common automation-compatible data types. This, however, was not the case. As a result, although COM made some real advances in the area of language independence, it also had some real weaknesses.
-
COM was extremely complex, and for the most part only C++ programmers were able to work with COM directly. For VB programmers, the Visual Basic environment masked much of the complexity of COM. The inevitable result was that Visual Basic failed to give the developer full control over COM when it was needed, and many Visual Basic programmers often lacked sufficient familiarity with COM to take advantage even of those features that they were able to control.
|
In This Series
An Introduction to the .NET FCL, Part 5
An Introduction to the .NET FCL, Part 4
An Introduction to the .NET FCL, Part 3
An Introduction to the .NET FCL, Part 2 |
In addition, COM did not offer an integrated class library comparable to the .NET FCL. Instead, the developers of each application or operating system service were free to implement whatever object model made sense to extend their application. As a result, there are major gaps in the functionality made available through COM automation, and there is not a good deal of consistency across object models.
The .NET platform and the .NET Framework Class Library were developed in an effort to address these weaknesses of COM.
In the next installment, learn about the .NET Framework Class Library.
Budi Kurniawan is a senior J2EE architect and author.
Ted Neward is an independent software development architect and mentor in the Sacramento, California area.
|
Related Reading VB.NET Core Classes in a Nutshell |


