Integrated COM support would be wonderful!

[JustinJack]

An easy-to-use COM support would be wonderful, I'm trying not to post something that I'm SURE has been mentioned, but I searched the site for COM and didn't get any results. The database support is great. I love it, the network functions; I believe adding a COM interface would help keep it up-to-speed with the way the world is going. A lot of SDK's that I'm running across present COM objects now-a-days instead of plain-old DLL's with functions to call. So far, I can't figure out how to use them in PureBasic. I did try the COMMate Plus; it was decent, but it seemed like a bit of a work-around. I'm by no means an expert on COM and methods and all that, if I knew VB well, I probably would be, but PureBasic follows the programming logic I've used since C first came out. It's a wonderful hybrid of C and Basic and a little more genius thrown in too. So it would be awsome to have a little more of the newer-trendier (and maybe here to stay) stuff thrown in for availability, and still, in true PureBasic style, be just another option...

[blackborg]

Agreed.. native COM would be great..

[srod]

Must admit that I struggle to understand these requests. COM is, at heart, very simple and based upon nothing more than the interface. Purebasic supports interfaces and, therefore, Purebasic supports COM.

That's how I see it.

If you have a COM dll then you simply need a list of the interfaces exposed by the various objects within and you're off. Simple.

Now languages like VB add additional layers atop COM to make things easier in terms of parameters, properties and method returns etc. especially where late-binding is concerned (but then tools like COMatePLUS can help out in this regard).

So, to my mind, PB already supports COM in it's native form. Additional 'gloss' (as provided by VB for example) in making calls through iDispatch simpler, for example, is nice (especially when dealing with ActiveX), but is in no way essential since we already have all the tools that we need to hand.

Creating COM servers, on the other hand, well that is a different matter!

Beside's, is COM really a growing/developing technology? Has the advent of .Net not taken away a lot of the impetus for COM now? I think that less people are now developing COM servers as a result.

[blackborg]

I understand all of your points, but being a consumer, there are certain things I am simply to busy or too lazy to work out for myself -- some of those things may seem simple to you or to other more experienced programmers but they are not to me..

I like Purebasic and COMatePlus. Native COM support would likely (not guaranteed, but pretty close I feel) solve an issue I have with using COMatePlus on "WinNT://" objects.. which I have posted in the appropriate section of this board and as yet have received no reply..

The request the author of this thread made struck a chord with me.. that's all..

[Trond]

A COM object is just a C++ class which follows some special rules, which are, it has to have the three virtual functions QueryInterface(a, b), AddRef() and Release() first in its interface. PureBasic already supports accessing such objects. Since PB is a static compiler it cannot support late binding of names. Since I haven't use the COM functionality of VB I am a little curious to what's "missing" in PB.

[srod]

Well, COM is designed to be language independent (and, in a sense, platform independent as well) and as such, COM objects do not really have to be implemented in C++ at all. Purebasic would do just as well. It's just that a C++ pure abstract base class happens to have the correct binary format necessary for an interface which, when combined with C++'s multiple inheritance, does arguably make C++ the language of choice when creating COM severs.

As for late binding... no problems for a compiler like PB. Course late-binding was always aimed at interpreted/scripted languages and as such is probably easier to implement (in a generic way) in these environments. Working with iDispatch directly can be a pain that's for sure.

[Christian Uceda]

Agreed!

Basic support for COM (ala VB Scripting Host) would be the ice on the cake for PB, It is surprising it does not support it already. PB does so many neat tricks so well I find surprising that it doesn't support COM natively.

So I vote for this too.

[Trond]

BUT IT DOES SUPPORT COM NATIVELY. What are you missing?

[Christian Uceda]

Well, If by natively you mean having to code the equivalent of COMatePlus, or include COMatePlus in your executable, then yes, PB already supports COM.

I could make an analogy with GUI programming, PB includes a nice set of Gadget commands, which are neat and save a lot of time and headaches. Compared with building your own GUI using Win32 API commands, which one do you choose? Imagine PB without gadgets.

Now imagine you asking for PB to have a gadget command library to ease GUI creaton, and me answering to you: "PB supports Win32 API GUI creation natively.

By supporting COM natively we mean something along the lines of:

Code: Select all

procedure ProgramEvent_EventName1
  somepbcode
endprocedure

procedure ProgramEvent_EventName2
  somemorepbcode
endprocedure

comobject.i = PBCom\createobject("whatever.program", "ProgramEvent_")

with comobject
  \setsomething = "Hey this is a string"
  \setsomenumber = 1
endwith

result = comobject\dosomethingcool

if result
  some pb code
endif

PBCom\freeobject(comobject)

This is more or less what you can do with VB Scripting host (VBS), you can test it yourself if you want, VBS comes with all windows editions, there are examples all over the internet, and as the original poster says, most commercial software comes with COM automation interfaces.

When you use Visual Basic 6 (the one I'm experienced with) you can get other objects like dictionaries or collections from com objects very easily, a very good example is when trying to automate Outlook which has a very rich and complex COM interface.

Hope this helps to clarify why COM is a desirable feature for Windows.

Note that the functionality I hilighted abobe can be more or less achieved my using COMatePlus and similar addons, but they are just that third party non-official addons.

[Trond]

I may be wrong, but I *think* what you want support for is OLE Automation. This is not the same as COM (it's build on top of COM), and it's not supported natively in PB.

[srod]

I may be wrong, but I *think* what you want support for is OLE Automation. This is not the same as COM (it's build on top of COM), and it's not supported natively in PB.

Yes that is exactly what he is after.

My next question is... why turn PB into a VB clone? If you want native support for automation servers, then use VB or Delphi.

[Christian Uceda]

@Trond

You're right, we're talking about OLE Automation, for a long time it was called COM and most old dogs like me keep naming it wrong, sorry my fault.

@Srod

Code: Select all

My next question is... why turn PB into a VB clone If you want native support for automation servers, then use VB or Delphi.

Why do you say that?

We're not talking about changing the language or anything like that.

If suddenly you had to automate some kind of work? I don't know, like automating Acrobat, Photoshop, AutoCAD, MS Office (just to mention some of most well know commercial software packages that expose OLE automation interfaces)

Would you like to be told do not use PB use any of the other languages that support it like:

* ABAP
* C
* C++ (directly or via a library like MFC or ATL)[5]
* Visual Basic and Visual Basic for Applications
* Delphi[15]
* Microsoft .NET languages[11]
* APL (most Windows versions)
* Java (only with third-party tools)
* JScript[9] and VBScript
* Open Object Rexx[16]
* Perl[8]
* PHP[17]
* PowerBuilder
* Python [18]
* Ruby (via the 'win32ole' library included in the standard Ruby 1.8.x or later distribution)
* Tcl [19]
* Visual DataFlex
* WinBatch[20]

Just to do OLE automation. It sounds a bit silly to me to be honest.

The thing is that adding more functionality to PB only makes PB better and more suited to have the recognition it deserves.

In fact I just love when my new "favorite TOOL"* can to what most commercial languages can with a fraction of the resources and ten times the speed.

And besides I do not care about database support, but you won't see me saying "do not add this because I do not use it".

OLE Automation is ubiquitous in the Windows platform, heck you can automate the whole of windows using it.

Won't be it incredible to have PB support all that extra functionality?

(*) Feel the pure power, why not OLE too?

[srod]

Well, interesting you include c and C++ in that list (amongst others) because of course neither of these offer up access to OLE servers seemlessly without using some kind of library. The same as PB then.

The point is that you should use the 'best tool for the task' in hand and if it is stacks and stacks of OLE automation you are in need of then, well, PB is not the best tool for the job, and it has never pretended to be. Why not use a tool which is better suited for that task, one designed from the ground up to interface seemlessly with automation servers?

I can see why Fred and co. might never consider this a priority; I mean, why bother with what would be a hell of a lot of work when there are far better tools out there for doing this sort of thing. Beside's, PB is not a Windows only tool.

Just my opinion.

At the end of the day, PB can work with any automation servers. Course, the job is made easier if using tools like COMatePLUS, but the support is there regardless because, even if you try and avoid late-binding via iDispatch, most servers offer dual interfaces and so, like c and c++ etc, PB applications can utilise early binding techniques to access these same servers.

I understand where you are coming from, but, honestly, I wouldn't wait around for this to be added to PB any time soon. Either use what we have or, for this task of yours, use another tool.

And besides I do not care about database support, but you won't see me saying "do not add this because I do not use it".

Me neither. But then this is not what we are talking about here. I use automation myself (sparingly) and do it with PB quite happily. If I needed a lot of automation then I would switch to Delphi or some such.

[Christian Uceda]

I can see why Fred and co. might never consider this a priority; I mean, why bother with what would be a hell of a lot of work when there are far better tools out there for doing this sort of thing. Besides, PB is not a Windows only tool.

It is not a case of OLE Automation to be a priority, it is a case of making the life of PB users easier expanding PB and thus making PB a better tool. Have at least minimal support for a very widespread technology is mainly a good thing.

Also there is not a case of other tools better suited for OLE Automation, it is a case of other tools having built-in support for the technology, and of course some will have their implementation better than others. The only tool which I have seen makes OLE things really easy is VB 5/6 and there is no way I would like to go back to VB.

And as per OLE Automation being a windows only technology, what is the problem about it? PB Supports DirectX which is a Windows only technology, and it has broad support and integration for the Win32 API and structures on the full version.
OLE Automation is Win32 only? yes, and the majority of the user base is Win32 too.

Well, interesting you include c and C++ in that list (amongst others) because of course neither of these offer up access to OLE servers seamlessly without using some kind of library.

C and C++ do OLE Automation in Visual Studio via MFT. Most of what makes Visual Studio worth it is the extra MS libs to make your life easier when developing C/C++. Same for Delphi or any other language out there including PB.

I'm have to try COMatePlus (I have not done it yet) maybe it is good enough, but whatever it does, it is not part of the official package and that will give trouble sooner or later, due to deprecated functionality or superseding. From what I have been reading on the forums the place is filled like a graveyard of old dead usermode libraries.

Again, I know the developers won't take this as a priority, and I know the majority of the people do not care or need this functionality, but believe me, some of us do, and would appreciate it. I think it is important for the people who would like it to at least show interest on the feature.

As they say one man's rubbish is another man's treasure.

[Trond]

From what I have been reading on the forums the place is filled like a graveyard of old dead usermode libraries.

Userlibs have to be recompiled for every new PB version. The whole point of distributing the source (like COMate) is that you recompile it with whatever version of PB you currently use, so it never becomes obsolete in the same way.