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.
:)
the thing that would allow PB to compete
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'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'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..
If this is the case, then I'd rather see it implemented through some sort of extension library or module..
AMD Athlon XP2400, 512 MB RAM, Hercules 3D Prophet 9600 256MB RAM, WinXP
PIII 800MHz, 320 MB RAM, Nvidia Riva Tnt 2 Mach 64 (32MB), WinXP + Linux
17" iMac, 1.8 GHz G5, 512 MB DDR-RAM, 80 GB HD, 64 MB Geforce FX 5200, SuperDrive, OSX
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.
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.
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.
-
techjunkie
- Addict
- Posts: 1126
- Joined: Wed Oct 15, 2003 12:40 am
- Location: Sweden
- Contact:
I don't think you have too...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...
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...
(\__/)
(='.'=) This is Bunny. Copy and paste Bunny into your
(")_(") signature to help him gain world domination.
Solution
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.