Classes -> Lib

[Steven Pringels 3]

Hi,

Well, you can see where this is going. I'm creating classes but wish that I
could place them in a library without having to make them into a COM component. Then htese classes are accessible by others but the source is
protected. This is apparently something that will come in a further release, not ?

Cheers

Steven

[Paul Squires]

Couldn't you just put the classes into a DLL? Why does it have to be a Lib?

[jcfuller]

Hi,

Well, you can see where this is going. I'm creating classes but wish that I
could place them in a library without having to make them into a COM component. Then htese classes are accessible by others but the source is
protected. This is apparently something that will come in a further release, not ?

Cheers

Steven

Classes are a COM component. Are you saying you don't want to create a com server? If yes why not??



James

[Steven Pringels 3]

Hi Paul, Mr. Fuller,

Yes, correct, I don't want to create a COM server but just a library of Classes
that I can use at my disposal without the need to include the source code of
those classes all the time.

I would of course use the interface/members that would be generated by a
tool to gain access to the classes.

How could one achieve this ? Like Paul says, put then in a DLL and use some
kind of export mechanism.

#Compile DLL "Classes.DLL"

Class MyClass Export

End Class


When you create a COM class of it, one can use the classes since COM is almost self-documenting. I just one to tie my class to an application using an external library. This may come in the future, who knows.

[Edwin Knoppert]

The new pb version is good for that.
but the library (dll!) will contain all classes and not as other languages may support, static linking.
So you'll have a 'big' dll containing all classes.

The new PB class part is com based but frankly that is a good thing.
PB itself supports creating class objects without the need to register your library.
That as plain code can be found on this board to be used with other languages as well.

Since the pb class is com, the pb compiler will generate a typelibrary file.
like: dllfilename.tlb

A com browser can be used to explore the contents of the library and generate the code required.
There is also a method to embed this specific tlb file in your resource and thus you'll have only a dll to distribute!

If you prepare your classes as dual interface you don't even need these declares (tlb and such) since latebinding is used and internal code will route your call to the correct function (Object Call stuff... ).

If you are willing to use a full blown dll and eventually expose the class methods via a tlb, than the new PB stuff is the way to go.
Optionally do not expose and use the dispatch interface.

There is also a way to create an (single?) exported function where you pass a variant.
You can set the variant in the library to a newly created com interface and in the exe you can use the variant to set a dispatch.

Several ways to do this..
Com based is not an issue imo.

[Bob Zale]

A COM object is only self-documenting when you publish the Type Library.

Bob Zale
PowerBASIC Inc,

[Fred Harris]

Bypass COM

Yesterday after your question about the TypeLibs Steven I read those links Steve Rossell provided and it certainly does look easy to Register COM Servers with PB's new functionality. However, it looked to me like the registry entries were an optional step. All COM gets out of the registry is the path to the component so that it can load it and internally do a GetProcAddress() call. If you wanted to load a component yourself and handle the low level details yourself in terms of getting the addresses of exported functions, I suppose it could be done. I havn't tried it but can the Export keyword be attached to a class in a dll? I'm thinking that would be key or not?

[Edwin Knoppert]

You'll need a simple wrapper function.

[Steve Rossell]

Yesterday after your question about the TypeLibs Steven I read those links Steve Rossell provided and it certainly does look easy to Register COM Servers with PB's new functionality. However, it looked to me like the registry entries were an optional step. All COM gets out of the registry is the path to the component so that it can load it and internally do a GetProcAddress() call. If you wanted to load a component yourself and handle the low level details yourself in terms of getting the addresses of exported functions, I suppose it could be done. I havn't tried it but can the Export keyword be attached to a class in a dll? I'm thinking that would be key or not?

Actually in PB it is very easy to use a server that is not registered.

From the LET statement (with objects) in the help file:

LET objvar = NEWCOM CLSID ClassID$ LIB DLLPath$

PowerBASIC offers the unique ability to create and reference COM objects without any reference to the registry at all. As long as you know the CLSID (Class ID) and the file path/name of the DLL to be accessed, you can do so with no registry access at all. You don't need a special type of COM server. This technique can be used with any server, whether created by PowerBASIC or another compiler. By using this method of object creation, there is simply no need for the server to be registered at all. That allows you to keep local copies of the COM servers you use, with no chance they will be altered or replaced by another application. You use the above form, where the clause "CLSID ClassID$" identifies the 16-byte Class ID, and the clause "LIB DllPath$" identifies the file path and file name of the COM Server. Once you've obtained the COM object reference in objvar, it is used exactly as you would with a traditional object.

See the Let statement (with objects) at http://www.powerbasic.com/support/he...h_Objects).htm and also at http://www.powerbasic.com/support/he...an_object_.htm.

[jcfuller]

What Steve said ( he beat me too it ) and:
Also if you don't want to publish all the interfaces in the dll library use "HIDDEN" when declaring.

James

[Edwin Knoppert]

What Steve said ( he beat me too it ) and:
Also if you don't want to publish all the interfaces in the dll library use "HIDDEN" when declaring.

James

I didn't knew that, i read much about it yesterday though..
Handy tip