Because you are creating new objects of your own, it is essential to include all the properties and methods of the original object and simply pass the calls through to the original object where there is no extra functionality required. An example of this is the hInstance property of the App object, shown below.
Public Property Get hInstance() As Long
hInstance = VB.App.hInstance
End Property
NOTE
Note that hInstance is a read-only property of the VB.App object so you would not code a Property Let for it.
The App object
The main uses we have found for subclassing the App object are to add new application-level properties and to reformat the output of some of the standard App object properties. Typical properties that we find useful to add are InDesign (a Boolean value that tells us if we are running within the Visual Basic IDE or as a compiled EXE or ActiveX component), date and numeric formats (from the Registry), the operating system version details, and various file locations (the application help file and MSINFO.EXE, among others). Other uses for subclassing the App object include providing a consistent version number format, and the ability to store Registry settings in different locations depending on the InDesign property above (we append either ".EXE" or ".VBP" to App.ExeName).The Debug object
This is probably the most difficult and least useful of the system objects to subclass, mainly because an object cannot be created with the name "Debug" and the Print method cannot truly be subclassed, as "Print" is a reserved word. For these reasons, it is probably best to leave the Debug object alone and, if extra debug-like functions are required, create a completely unrelated object.The Err object
This is probably the most useful object to subclass, as it enables you to apply more consistently your chosen error handling strategy. We add Push and Pop methods to the error object, and we also make the undocumented Erl function a property of the object. In addition, we add an ErrorStackList method that allows us to examine the current error stack that we maintain internally within the new App object. This allows us to determine, from any point in a program, the routine that raised the current error. For more information on error handling strategies, and an implementation of a replacement "Err," please refer to Chapter 1.One note of caution with the Err object relates to the Raise method. Although you should probably add a Raise method to your subclassed Err object for completeness, you should add code to it to ensure it is never called. The reason for this becomes obvious when you stop to think about it. Your Err.Raise method would deal with the error by passing the required details to VBA.Err.Raise. This would then generate an error, with the source of the error being your Err object every time! When subclassing the Err object, you must ensure that VBA.Err.Raise statements generate all errors raised in the program.
