You are not logged in. You can browse in the PowerBASIC Community, but you must click Login (top right) before you can post. If this is your first visit, check out the FAQ or Sign Up.
Hi. I would like to know if a future version of PB/DLL will allow object oriented programming? Not necessarily COM though, but just OOP with true inheritance, polymorphism, etc.
Hmm... after searching the boards I think I may have found the answer to my question. Last reference I wound was dated August 25th of last year. Hopefully this means they are that much closer to rolling it out. OO Power Basic would rule. I will leave VB forever when that happens.
VB7 is supposed to have true inheritance, polymorphism and free threading, but somehow I don't see it happening, and if it does, Im very leary of how well it will perform.
=============
posted April 05, 1999 09:33 AM
Jim,
We do plan to add COM support to the PowerBASIC language, but as I have mentioned before in other threads, it will be available when we're done and not before. Adding ActiveX support to a programming language is not something you do over a beer and a donut. There's a lot involved when you change a programming language (and the BASIC programming langauge will need to be modified a bit to support objects).
You might want to take another look at that old proverb "patience is a virtue".
--Dave
posted August 25, 1998 05:19 PM
Actually, we don't use Visual Basic all that much here.
Seriously, it has always been our intention to create a complete object oriented visual environment for BASIC programmers.
Beyond that tidbit there is absolutely no information available.
--Dave
I don't mind OOP - it can be very fun and powerful. BUT, if you start talking about ocx, etc, I'm inclined to agree. I think that ocx's are the biggest distribution headache imaginable - different versions of the same thing on the same machine can be a real pain. I hope PB does oop and it results in the creation of a component module like Delphi's VCL. This a far superior model than OCX - the only distribution pains I've found are placed upon the developer and the installation - not the end-user.
my 2cents
don
<<that ocx's are the biggest distribution headache imaginable -
<<different versions of the same thing on the same machine can
<<be a real pain.
I don't really see the problem with the deploiement of OCXs or of other types of COM components. They are self installable/deinstallable, can be automatically downloaded and installed from a web site, given a deploiement context. They can be packed in compressed and code signed CAB files where all the files they need can be packed. The way they register themselves in the system registery makes possible to have different component versions cohabitate smoothly. A client application will then be able to either choose explicitly the version of the component it needs, or target the default one as determined by the registry. Also, once installed, a COM component can be accessed by any client from any location: you don't have to care about their respective paths: this is handled transparently by the COM machinery, among many other things.
<< I hope PB does oop and it results in the creation of a
<<component module like Delphi's VCL. This a far superior model
<<than OCX
You cannot compare the VCL and COM technologies: COM goes far beyond what VCL offers. VCL is for Delphi only while COM is a very general, powerful, efficient technology for building multilangage OO components to be assembled to create state of the art business critical applications: see what COM+ has to offer.
PB would very good at that, and could probably gain a much larger audience in that field, but the first step would be to stop the misleading 'bloatware' propaganda against OO, COM, DLLs ...
I personally don't think that we're actually saying that COM or ActiveX are bloatware. Only that the way Microsoft uses COM and ActiveX in their own products makes them bloated.
Personally, I think there is much good in COM (if implemented properly). That said, I doubt I'll use it much because I don't want the overhead.
I believe that PowerBASIC should add COM support to the language and I know that the company is committed to doing just that. It's just a matter of time and priorities.
I understood Bob's comment as referring to Visual Basic DLLs, which are not "real" stand-alone Win32 DLLs and can't be used by any language except VB. Maybe I'm wrong, but I don't believe that he was being critical of DLL technology in general.
In any event, I stand (technically) corrected. Sure, there are good DLLs and bad DLLs.
I understood Bob's comment as referring to Visual Basic DLLs, which are not "real" stand-alone Win32 DLLs and can't be used by any language except VB.
Any language that can handle COM v-tables can use a VB DLL. This includes, but is not limited to, PowerBASIC, VC++, Delphi and Eiffel.
To really get on a technical point, you could actually call a VB DLL from PowerBASIC DLL via its' exported functions. Do a QuickView or a DUMPBIN on any DLL created in VB and you'll see 4 exported functions (the functions necessary for COM registration, unregistration, class loading, and DLL unloading). So, technically, VB does create exported functions; it just doesn't let the developer at this feature in VB (although I should note that a developer wrote a VBPJ article that showed the reader how one could hack the compilation process and export your functions ).
Philippe,
My main concern about active X com implementation is distribution. What if there are 2 versions of the same active X control on a machine that aren't binary compatible. This happened with a control or two in VB4 and VB5. There was a vb4 version of a control and a vb5 version. If the VB4 version was installed, the VB app couldn't use it and vice versa. This meant that until the VB4 developer recompiled their app with VB5 both applications could not run on the same machine. Maybe I'm ignorant, but isn't it true that only one version of an OCX can be registered on a machine? This is a big hangup for me. Maybe there's a simple way to fix the problem - I don't know that much about the inner workings. Also, I guess my beef isn't so much with COM (I love ole automation), but with Active X controls.
Best Regards,
Don
We can pass from DOS minding to Windows and to COM(+) without a hitch...
I defenitly think that PB have one of the best compiler in the word, but to pass from a compiler to a complete (up to date) language and tool solution, there is a very big step.
I saw that the dialogue change as the Power Basic people begin to believe that COM and OOP isn'nt soo ugly that they first see...
I see often the word "bloated" soo many times in this forum that I cannot beleive the ones who say that if they never really tried this deeply.
For myself, Jason, Philipe, and other like me who had worked in the both sides of the mirror, and not just tried it but puch the knowledge deeply in the both technologies, we can say that OOP, COM and all others Microsoft technologies aren't soo ugly, they are a tool that a programmer have to use days after days, understanding those tools deeply will make the difference between the developper centralized in just an only one technology who know only what he know..., but we are more productive with better optimized tools..!
I remember the old days where I need to programming myself my listboxes or inputboxes, and my windows too in a primitive GUI in DOS. When Windows come in the market it was very slow but I persevered, when my friends tell me that was a "bloated" OS . Now, if I put beside Linux, who now don't use Windows???!!
Now, the only "bloated" things in this dicussion, is the one who refused to make R & D and refuse to learning deeply the new technologies, out of ignorance!
-------------------------------------------------------------
Francis Beaulieu
FrabLaser Softwares
------------------
Francis Beaulieu
Prog senior of 17 years.
Microsoft Specialist
<<Dave
<<I believe that PowerBASIC should add COM support to the
<<language and I know that the company is committed to doing
<<just that. It's just a matter of time and priorities.
Ok, but COM is a very complex and quickly evolving technology,
it will take a lot of time and effort to add support for it
to PB. Also, many new technologies only come in the form of
COM components.
<<Eric
<<I've never seen a single critical word from PowerBASIC, on
<<this BBS or elsewhere, about DLLs.
Given PB/DLL's name it would be quite surprising <g>. I have seen many customers on this forum refusing to consider third party products only provided in the form of DLLs, while most of them could be shaped as LIB files as well if PB supported them.
As for VB DLLs, they are actually inproc COM servers, exposing not an API but VB classes. Our JA COM/PB 2.0 shows how to instantiate and manipulate VB classes (exposed indifferently by DLLs or by EXEs) in PB/DLL or PB/CC. The VB DLLs can therefore be used at once by any COM language: VB, Delphi, VC++, PowerBuilder, and PB/DLL too.
<<Don
<<isn't it true that only one version of an OCX can be
<<registered on a machine?
The COM specs strongly recommend that once a COM interface is 'published', its signature never changes in anyway. A new version of a published COM interface must be assigned a different Interface ID (128 bit unique signature). Respecting strictly that rule should suffice to install and run properly several versions of the same COM components on a machine.
Unfortunately, that rule is not always respected, including by MS itself...
We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, and to analyze site activity. For additional details, refer to our Privacy Policy.
By clicking "I AGREE" below, you agree to our Privacy Policy and our personal data processing and cookie practices as described therein. You also acknowledge that this forum may be hosted outside your country and you consent to the collection, storage, and processing of your data in the country where this forum is hosted.
but I persevered, when my friends tell me that was a "bloated" OS
Comment