Wrappers

[tacoman667]

Could someone explain the concept of a "Wrapper" to me? I was reading a little while back that you could use a wrapper on the .NET framework to get some .NET functionality in VB6. A wrapper is totally foreign to me though.


Thanks.

[Shaggy Hiker]

In general, when somebody says wrapper they mean something along the lines of building a class that has a member function that calls the desired method. Thus, you could do something like this:

Public class String
 Public Function Mid(strt as integer, length as integer) as string
   'Call the VB6 Mid$ function in here.
 End function
End Class

By doing something like this (though this is a pretty dumb example), you can expose the underlying functionality (in this case, the VisualBasic Mid$ function) via a .NET class.

API calls are often wrapped in this fashion. The calls are called within functions of the wrapper class, which keeps the user from needing to deal with API calls directly.

[tacoman667]

So basiclly I could create a class, inherit Process for example, and just write a function and properties that will call the process functions and properties?

I am feeling a little confused...

[Shaggy Hiker]

Oddly, my answer depends on a space. Specifically, did you mean to put a space between inherit and Process?

If you did, then you are talking more about inheritance, which is separate. If you didn't, and inheritProcess is the name of a class, then you are on the right track.

You could have a process that you would wrap into a class and expose only some functions through the methods of the class. That would be a wrapper. Why you would want to do such a thing could be one of several reasons.

1) You might want to filter how the process is used, so the wrapper class mediates how the process is called, what arguments are passed in, etc. In this way, it is acting as a gatekeeper.

2) The process might be so awkward to call (as some API calls can appear to be) that you want to provide an easier interface for people to use. Therefore, the wrapper exposes functions that make more sense to people, but don't do anything except make the more complex calls. Most application frameworks are wrappers for Windows. If you read Petzold, you will see all the message pumps, registrations, etc., that make Windows difficult. All of that is wrapped in frameworks like C++. The wrapping provides easier, more intuitive functions in lieu of the tougher, more basic functions.

3) Both of these.

4) You could wrap something to change the names. Function X() calls function Y(). The name Y() is no longer visible, but X() is. This is a rare reason, but a possible one.

5) I think there was another reason, but I forget what it was.

[tacoman667]

So you are telling me I cannot create a class that inherits in order to wrap that for use in VB6? I say "Process" for one because it is FAR easier to have a process object and manipulate the process priorities?

Thanks for the replies!

[Shaggy Hiker]

No, you can have a class that inherits, but inheritance is generally a different concept from wrappers.

For instance, I find that working with Excel Apps via .NET is a royal pain in the ass. Therefore, in one app, I created a wrapper for Excel. The class takes a template name, and deals with finding the template, creating the app, opening a workbook based on the template, taking data to fill in the template, saving and closing the workbook, and closing the app.

Later, I found that I wanted a special type of template to be handled in a special way. To do this, I wrote a class that inherited the Excel wrapper. The child class didn't need all the functions for finding and opening the workbook, nor did it need the functions for saving and closing everything up. All that functionality was already in the parent (or base) class, and was inherited by the child.