"Al Reid" <
areidjr@reidDASHhome.com>wrote in message
Quote
Is there any way to create a VB DLL and use a reserved word as a method
name. The situation I have is that I have a very large
application that is built around a 3rd party com library. The library is
now obsolete and no longer supported. I want to migrate
the application to something else. My initial plan was to build a
replacement dll that mimics the existing object model. That way
I can develop and test the dll and then just drop it in place of the
original and not have to mess with the code. This will be
fairly simple to implement. The problem is that the original component
uses method names that are reserved (Open, Close, Lock,
Unlock, etc.) Is there some way around this? At this point I have the
Methods called Open_, Close_, etc. Is there some way to
alias them to the correct names using a type library? If so, how? If
not, is there any other way.
TIA
--
Al Reid
I remember I had the same question a while ago and couldn't find any advise.
I thought about one solution then, but never implemented it in practice due
to unreasonable complexity and limited applicability. Anyway, these are my
untested thoughts.
First of all it should work only if your classes (those with reserved
keywords) are PublicNotCreatable and your library exposes them to client via
hierarchical object model.
You can create an IDL file with the full interface of your class. Reference
final TLB in your project and use that interface with Implements keyword.
Now you expose that Interface to the client - not a class itself. Client
doesn't see such substitution and doesn't actually care about it.
Let say you have a top class in your module, which is, let say, Application
and another class, let say, Connection, which should have a method Close.
Internally, you have a class, which you name as CoConnection, and in TLB it
is called Connection.
Now, conceptually, it looks like this:
'In Application
Public Property Get Connection() As Connection
dim obj as CoConnection
set obj=new CoConnection
set Connection=obj 'here you, in fact, pass an interface Connection of
class CoConnection, but client does see Connection only
set obj=nothing
End Property
'In CoConnection
Implements Connection
Private Sub Connection_Close()
'here either call internal class's method (e.g. your Close_) or put full
functionality. The latter is, perhapse, better (in this case class can be
used directly without interface)
End Sub
I don't remember, if there are other details, but in general, it is as
explained above.
Complexity, as I said before, is that you have to create interface in IDL
for ALL of your methods and properties, not only for those with reserved
keywords. Otherwise, you client should be aware about two interfaces, which
compromises your goal. And if those classes are directly creatable by
client, then it doesn't work either - client must do the same additional
step (declare a variable of your interface type, create concrete class and
then assign it to that variable) as shown in Application class.
I am sure this can be combined with advanced techniques of replacing VTable,
but I never went so far - in my case I decided that all these doesn't worth
the result. You might arrive to the same conclusion - time you spend on all
these tricks may greatly exceed time required for context replacement of few
[dozens or even hundreds] method calls in your client.
I don't know whether I overlooked any simpler method of doing it.
Dmitriy.
-
