PureBasic Forums - English

The thing that's really missing, before PB can compete with any of the mainstream languages, is the ability to create ActiveX (OCX) components in PB.

I mean, just think about all the totally professional stuff you'd be able to do with it - deploying your apps as plugins for Internet Explorer, building database-driven web server components for IIS, making plugins or custom controls for Office applications...

(of course, support for using ActiveX controls in PB would then be a natural extension as well...)

ActiveX would also be the link between PB and other languages, which in turn would make it a potential choice for a lot more professional developers, since they would be able to integrate new PB components with their existing software.

And finally, support for ActiveX controls would give the PB team more time to concentrate on the PB language as such, which is where their time really ought to be spent if you think rationally about it - the PB team is fighting a hopeless battle to implement their own versions of every library function requested by every PB user, whereas a lot of these functions could simply be reused from existing ActiveX components instead.

In turn, if more time was invested in developing the actual PureBasic language, along with more low-level functions, more developers would have the tools they needed to implement good library functions - which again would make the language grow and become even more attractive.

Feel free to argue.

:)

No arguments from me.

mp303 wrote:The thing that's really missing, before PB can compete with any of the mainstream languages, is the ability to create ActiveX (OCX) components in PB.

The thing that's really missing is accurate maths.

There is no work-around.

mp303,

I'm doing a lot of work around ActiveX controls, and it will be possible in PureBasic. Theres a lot of work to do, but it can be done. Give it a year, I say.

What I wouldn't want to see is for Purebasic to make ActiveX central in the way you describe.

The whole design of Activex leads to bloat. C++ isn't a bloated language, but C++ with MFC is.



If Purebasic were to be build on ActiveX then it would be yet another buggy, bloated language. Why buggy? Because PureBasic will have all the DLLHell problems of VB.

Keep Purebasic pure is what I say.

I think it is kind of funny, that everytime somebody wants a new feature, it
becomes the *one single thing, that makes PB superior or even to other languages*

Everybody has his wishes, but not all will be implemented, and certainly not all at once.

Timo

I'm all for introducing new consepts, and this activex/ocx stuff sounds very promising, but I will NOT trade it for PBs speed and compactness...
If this is the case, then I'd rather see it implemented through some sort of extension library or module..

I don't think PB has to be based on, or "bloat out" with, activeX. It just needs to have a relatively easy way to use it. A lib would probably be enough.

With OLE/ActiveX/Com capabilities (both create and access) made easy, PB does have a larger and more powerful role in the world.

But first:

NOT()
SGN()
DOCS
CHR[x] type, or blob, or fixed length binary strings (binary zero can be embedded)
DOUBLES
Logical operators operating logically in expressions.
[Let] Structure=Structure
And uncle tom cobley and all.

I think the ActiveX interface will come, probably from some genius PB user, as a tool, addin or library and once done it will be enough.

I just wish that genius user would hurry up.

I'm working on it, but unfortunately I'm no genius.

The work is already done for me. Ruby has an opensource library called Win32Ole written in C. I'm working on converting it.

It would work rather like Purebasic's existing 'Library' commands, only for activeX dlls rather than ordinary ones.

After I've done that I've got to tackle OCX controls, and thats a whole other ball game!

I'm working on using ActiveX rather than creating it.

once done it will be enough.

No, by that point what PureBasic will really need will be .Net!

.NET!

True.

Maybe Fred should write something called PureClr. Or Pure#

I think the above was a nice joke I mean why would you guys want a 30+ MB runtime library for a scripting environment?

like others said there are much more important things missing, things that don't have workaround. you can ask for AX, but if ie your program will crash because you did a mistake in a variable name..

LarsG wrote:I'm all for introducing new consepts, and this activex/ocx stuff sounds very promising, but I will NOT trade it for PBs speed and compactness...

I don't think you have too...

Most of the implementation of ocx support could be done in Visual Designer - add code to generate a wrapper for the control... This would be really nice...

Everything in this thread that everyone said is correct. So what is the comprimise? Have a front end option like Microsoft Visual C++ where you can specify if you want to create a .exe or an ActiveX file. This way, the ActiveX development in PureBasic is completely seperate and doesn't effect in anyway the ability to produce fast and small .exes or bloat in anyway.

Just my 1 euro cent...

Compiler Option -> Bloat Exe

This would really make the diference! No one would argue with the power of purebasic if your executable is at least 1.2 Mb !!!