PureBasic Forums - English

It woul be a great thing if PB support com object like in Visual Basic.
I know that there were Comate object , but comate object is hard to understand.
If we can use object like in VB PB will be the best for programming witout any contest

I seriously doubt it would change the "best programming language" stuff for linux and OS X users

Fred wrote:I seriously doubt it would change the "best programming language" stuff for linux and OS X users

I agree with you but most of the programmers use Windows for business application and the only things that isn't good in PB for concuurencing VB is accessing easyli to com object

Fred wrote:I seriously doubt it would change the "best programming language" stuff for linux and OS X users

so 90% of all PureBasic programmers can not code COM in a
comfortable (native) way, because the remaining 10% are
using a different os?

Greetings ... Kiffi

You are assuming that all Windows users want to use COM, which i doubt very much.

freak wrote:You are assuming that all Windows users want to use COM, which i doubt very much.

the interest in using COM is quite high (just see the activity in threads
about COMate, PureDispHelper and your postings about using COM).

And i prognosticate a much higher participation if PB supports COM officially.

Greetings ... Kiffi

Well, we'd have to make some fundamental changes to the language to have "real" support for it. And we are not going to do that because it just doesn't fit the crossplatform design to have a large part of the language focus on a single, non-crossplatform technology. Yes, Windows makes up the largest parts of the userbase, but that doesn't change the fact that PureBasic is a crossplatform language (if it weren't, there would not be a Windows version either).

Must admit that I avoid using COM unless I absolutely have to.

If we can use object like in VB

How does VB use com objects?

You add a reference to a type library to your project and then you can use the objects defined therein in your project etc. The compiler will typically build vTables dynamically as required based on the info gleamed from the type-lib, but will proceed via iDispatch if the vTables cannot be built and the component exposes iDispatch etc. or the developer specifically requests that automation is used.

In order for PB to support that level of COM integration.... well it would be a huge huge undertaking. VB wraps up all parameters as appropriate (variants, safe-arrays etc.) and handles nested object calls as well as object parameters. And then there is the garbage collection...

For this level of integration ... use VB!

Hi Srod,
Not that I'm complaining...But how or why did COMate(Plus) ever get written?
Instead of suggesting we use VB, shouldn't we really just say NO to VB.NET?
...
I agree with you in that I try not to use ActiveX objects and opt for DLLs when available.
However, some electronic equipment I must automate only offers ActiveX controls.
They are dwindling in number now, and I hope your COMatePlus tool will help as I convert from VB6 to PB.

To Fred and Freak,
I appreciate your direct answers on these topics.
It is just as important to know where PureBasic is going, than what features(and bugs) already exist.
My request would be an updated blog of "what's next".

Thanks for a great development tool!

COMate arose out of an original need of mine to use ADO and it was, for me, a good way in to COM. Call it a learning experience if you like.

Use the best tool for the job, and if quick and easy access to COM objects is required then you can not go far wrong with VB. I am no great fan of VB, but I can recognise it's strengths easily enough. As I see it, there is little point complaining about PB's apparent lack of COM support when it was never intended to be a VB clone. Tools like COMate are there to be used and there is little you can do with VB automation that you cannot do with COMate (and almost as easily - though not quite! )

Just my opinion.

Fred, do you still have the 2010 belief about adding com objects?
what's wrong with adding a few more functions to pb to run only on Windows?
You have already done this:

SetWindowCallback(@ProcedureName() [, #Window])
It's only supported on Microsoft Windows.

EventlParam() and EventwParam() and ClearConsole() and
SmartWindowRefresh(#Window, State) and ConsoleCursor(Height) and
ConsoleLocate(x, y) and ConsoleTitle(Title$) and GadgetItemID(#Gadget, Item) and
GetFunctionEntry(#Library, FunctionEntry) and GetSoundFrequency(#Sound [, Channel]) and
InitScintilla([LibraryName$]) and KeyboardMode(Flags) and ThreadPriority(Thread, Priority) and
MDIGadget(#Gadget, x, y, Width, Height, SubMenu, MenuItem [, Flags]) and MouseWheel() and ...

Supported OS

Windows

All these are minor functions, while built-in COM support would be very hard to do. You can use COMate which fills the gap.

Not complaining, but nothing, that COMate isn't easy to use.