PowerBasic or Visual Basic?

[Frederick J. Harris]

Thanks for the explanation Jose.  That does clarify some things for me.  The more I learn about this and work with it the more I am beginning to lose interest in the concept of ActiveX controls themselves if by ActiveX control one means something embeddable in something like Word as an 'insertable object', or something with complex property sheets usable in scripting languages.  What MORE interests me is creating visual COM components with only direct interfaces and utilizing connection points and sinks as the messaging protacol.  I guess this is because I don't really work with internet technologies at all.  I'm basically a Windows app programmer. 

[Frederick J. Harris]

Frederick, can you post a small example to create a visual activex control?

I wrote it in C and am converting it to PowerBASIC right now.  If you are in a hurry I can email or attach the C code here; otherwise, I'll be posting the PowerBASIC code hopefully within a week or two.  Soon as I can get it all working and wrote up. 

[Edwin Knoppert]

No hurry, just curious how small you got it..
Maybe not really useful because of the unhandled methods but i would like to see the minimum you reached here

PB code is easier.

[Frederick J. Harris]

Like I said I'm not done with it yet, but my best guess is that if you are comparing dll size with the same visual control implemented as a custom control I'd guess it would only be a few percent bigger.  Over the long term, after I have some of this stuff figured out well enough that I'm comfortable with it, I'd like to try to build myself a COM based grid control that works more or less like the siGrid control.  Or maybe a stripped down version of that.  The siGrid control has a pretty lot of features I don't use.  Anyway, I'm wondering if I could produce something nice that wouldn't be over 50K.  I don't think I could do it with PowerBASIC, but possibly with C++ and some of the unneeded methods stripped out of my String class.  I'm a long way from that point yet though.

From what I've seen so far though, if one is content with just having the control respond to events in the typical manner in which either PowerBASIC or Visual Basic recognizes them through their event sink functionality, the code to get that working is fairly minimal.  Adding the enumerators complicates things considerably, and at this point I'm not satisfied they are all that worthwhile.  I can't really imagine why I'd want an object with multiple outgoing interfaces.  But might just be my ignorance at this point.  Also, some host environments might not be as forgiving as VB or PB too and might freak out if all the connection point interfaces weren't implemented to their satisfaction.

[Dominic Mitchell]

IPropertyNotifySink
ISpecifyPropertyPages
IPropertyPage(2)
IOleInPlacrActiveObject
IViewObject(2)
IViewObjectEx
IOleInPlaceObject
IOleInPlaceObjectWindowless
IOleControl
IOleObject
IOleWindow
IDataObject
IQuickActivate
IPersist
IPersistStorage
IPersistStreamInit
IPersistPropertyBag
IProvideClassInfo(2)

The only interfaces of the lot above that I consider as contributing to bloat
and that are related to visual designers would be those listed below.  The rest are quite
important depending on the type of control and what it does.

IPropertyNotifySink
ISpecifyPropertyPages
IPropertyPage(2)
IPersistPropertyBag                                        

For example, if I want to put an edit control or a listbox on a form/dialog/window I certainly
don't need to create another window to be its parent and 'contain' it.

And you can do the same thing with an ActiveX control.  For example, if you want to place five
ActiveX controls on a top-level sdk window(aka a form), you can create them directly on the window.
There is no need to place each of them in a container window.  The only caveat is that the window hosting
the ActiveX controls must be an OLE container.
This means that Jose OleCon.bas code would have to be modified to use the form as the container and enhanced
to allow for such things as control placement and sizing.

Placing each ActiveX control in its own container window is for convenience. They are easier to work with
in environments where the host window is not an OLE container by default. For example, think of what is needed
in the case of a tabbed dialog.  The top-level window and the pages would all have to be OLE containers.
But this convenience comes at a price.

[Dominic Mitchell]

For

IConnectionPointContainer::EnumConnectionPoints

and

IConnectionPoint::EnumConnections

you can return

E_NOTIMPL

And you probably do not want to support more than one outgoing interface not unless
you intend to confuse code generators.

... but I'm not quite sure what to call them besides visual COM controls.

How about ActiveX controls.  All you need is IUnknown as per the ever changing specification. How well your
control works, if at all, in its environment will depend how many of the not too long ago used to be required
interfaces you implement.                                                                                   

If you want your outgoing interface to work in all environments, it should inherit from IDispatch.

[José Roca]

 

But this convenience comes at a price.

Yes. The price is that it won't work with some ActiveX controls. But my purpose was to write a lightweight container to replace ATL.DLL and I always have warned about its limitations. It works well with a wide variety of controls and, contrarily to ATL.DLL, allows me to use them without havig to register them first. If one day I need to use a control that doesn't work with my container, I will use yours. No need to duplicate efforts.

[Frederick J. Harris]

I love E_NOTIMPL almost as much as S_OK!

[Murray Ruggiero]

 
   I have a large project which contains many Active X COM DLL's   some of which are nested.  Some of these Active X DLL are written in C++ , which will not be changed and others are written in VB 6.0. I want to port these to PowerBasic. I thought about making them all C++ but that would be too expensive.

   Let me give you an example

    Active X DLL X  has  20 different interface classes exposed
which will be called by other modules and about 25 lower level classes which are used in these exposed interfaces.

In addition this Active X DLL calls 3 dll's written in C++ and 2 of them written in VB 6.0 , I want to port the ones which will give me the most performance increase first. 

  Can anyone help me with several issues.

Can you explain exactly how you call Active X DLL using early binding from a power basic Active X DLL

How do you orginize  a project with multiple exposed classes and many lower level classes

Has anyone ever put together any type of notes on porting from vb 6.0 to power basic.

[José Roca]

Can you explain exactly how you call Active X DLL using early binding from a power basic Active X DLL

If you have PB 9, it's better to use direct interface calls.

1. Generate interface definitions using the PB COM Browser or my TypeLib Browser.

2. Create an instance of the wanted object.

   DIM <object variable name> AS <interface name>
   <object variable name> = NEWCOM <program identifier>

3. Call methods and/or properties:

   <object variable name>.<method name> (<parameters>)
   <result> = <object variable name>.<get property name name>
   <object variable name>.<set property name name> = <value>

Has anyone ever put together any type of notes on porting from vb 6.0 to power basic.

I'm afraid not.

[Murray Ruggiero]

1. Generate interface definitions using the PB COM Browser or my TypeLib Browser.

Where is this documented how to make a interface   definitions. Is there any step by step guide anywhere ?.  This is shrink wrap software I am writting and don't know where end user will install so direct interface might not be best solution.

  Also , I am new and don't know how to start a new thread or if we even can , but the Porting from VB 6.0 to PowerBasic would be a good new thread between all the member maybe we can get something together useful.

[Frederick J. Harris]

In the PowerBASIC IDE click the Tools option on the main menu...

Select PowerBASIC COM Browser;

Scroll to find type library for which you want to create interface definitions;

Double Click the library;

Paste the generated definitions into a file and give it a *.inc extension;

Include the file in your project;

Read the PowerBASIC manual.

Additinal info:

If your ActiveX controls are visual interface elements, to the best of my knowledge you'll have to use either Jose's container or Dominic's which I'm thinking you may have gathered from this discussion.  Oh. yes, there are two other possibilities for ActiveX support.  Edwin Knoppert's visual designer may have that support (not sure).  I know Paul Squires's FireFly does.  You should be able to easily find those links.

[José Roca]

This is shrink wrap software I am writting and don't know where end user will install so direct interface might not be best solution.

You don't need to know where the user has installed the software to use direct interface calls if the ActiveX is registered. You create an instance of the object with pObj = NEWCOM <PROGID = program identifier>.

[Jim Dunn]

The book you want for learning low level COM is:
"Inside OLE"
by Kraig Brockschmidt
Published by Microsoft Press
COM is the wrong term to use when looking for books on it.
COM is based on OLE and OLE is at the core of COM (and DCOM).
This book is suppose to be the best book on the subject from what I have read.
You should be able to find it "used" on the web, since it is not published any more.
Another book I found which may be useful is:
"The COM and COM+ Programming Primer"
by Alan Gordon
Published by Prentice hall
They are big books and I would expect that it would take a good year to dig deep into them to fully understand COM at its lowest levels.

Be sure to compare book prices at http://www.abebooks.com/servlet/SearchResults?sts=t&tn=inside+ole&x=0&y=0 before you buy (can get Inside OLE for $1 plus $3 shipping).

[Frederick J. Harris]

You want to be careful about getting that book as the 1st edition is 16 bit from around 1993 and the next edition about a year or two later for 32 bit.

I've never been able to get any of Kraig's code to run, being as its based on such old and out of date C++ compilers (VC4).  Of course, that's based on only several hours of trying.  At one point I thought of sinking a major effort in trying to get Kraig's code working, but then I gave up on it.  I might return to it at some point though, as his work on COM was very important.