Hi guys,
having been away from programming for many years and having time on my hands, I thought I'd have another go at it. One thing is immeadiatly clear - we're not in Kansas anymore Toto.
I've been doing some research and a lot of reading and I've settled on using some dialect of Basic, which brings me to choose between PowerBasic and Visual Basic. It appears to me to be PowerBasic for performance and Visual Basic for everything else. I have conserns about PowerBasic, one of which being the appearant lack of interest in the world outside Power Basic. Unless I've missed something, the users of PowerBasic rely on you for translations of the newer parts of the Windows API. Even FreeBasic, (not a contender) provides headers for some of the more common third party DLLs. Also PowerBasic doesn't appear to address WMI which looks like a pretty important technology, or USB (all the stuff I've gleaned about Powerbasic and comms seems to only refer to serial?)
Are these points true? and are they relevant?
I don't pretend to understand this but I found the thread - "Need complete, simple example of a PB/Win COM DLL with calling VBSCRIPT code" - on the PowerBasic board disconserting - it appeared to take the combined efforts of the most authoratative posters to solve a problem which I suspect wouldn't have been an issue in Visual Basic. True?
Anyway, any comments from you Jose or any PowerBasic users as the pros and cons gladly accepted.
BTW If anyone wonders why I'm posting these questions here and not on the PowerBasic board - the staffers who post on that board seem to have a fairly high handed atitude and seem to have issues with anything construed as critisism. Plus I don't need the sales pitch.
James McNab
Which flavor of Visual Basic, VB6 or VB.NET?
Quote
PowerBasic doesn't appear to address WMI which looks like a pretty important technology, or USB (all the stuff I've gleaned about Powerbasic and comms seems to only refer to serial?)
You can use WMI with PB easily. You can find examples here: http://www.jose.it-berater.org/smfforum/index.php?board=229.0
Regarding USB, I have recently translated the headers for the HID.DLL: http://www.jose.it-berater.org/smfforum/index.php?topic=3853.0
With PB you can use all what Windows provides, without the need of ActiveXs or .NET assemblies.
Quote
I don't pretend to understand this but I found the thread - "Need complete, simple example of a PB/Win COM DLL with calling VBSCRIPT code" - on the PowerBasic board disconserting - it appeared to take the combined efforts of the most authoratative posters to solve a problem which I suspect wouldn't have been an issue in Visual Basic. True?
This is a shortcoming of VB, that is unable to use a COM server unless all its particular requirements are fulfilled. With PB you can use them even if they are not registered. I have been doing it years before M$ came with its convoluted way of doing it ( http://msdn.microsoft.com/en-us/library/ms973913.aspx ). All you need to activate a COM server with PB is the ClsID (Class identifier) and, if it is not registered, the path of the .DLL or .OCX.
PB is a wonderful compiler for those like me that like low-level programming, not by masochism but because your applications run much faster and use less resources.
Hello José Roca,
Dus me speak from the heart, it is possible in PowerBASIC COM DLL call I wonder if they are not registered! And with an ease which even C programmers can only dream ;D
I Work in a large company where it is not possible to register OCX modules that simple. By using Power Basic jukt me not even a simple I bind the OCX whom she is on the computer
Example:
LET ufreedb = NEWCOM CLSID $CLSID_pbfreedb_FREEDB LIB "pbfreedb.dll"
And now you can use the object
Regards Peter
>LET ufreedb = NEWCOM CLSID $CLSID_pbfreedb_FREEDB LIB "pbfreedb.dll"
This won't work if the activex needs another activex and most likely loads it via the registry.
(The technique Jose describes works differently and i have no sayings about that one right now)
Hello Edwin,
Maybe I've misunderstood, but it really works and I can also access the this object to another is Registered. The freedb object is not registered! And just in a DLL
Here's an excerpt
CLASS freeDB GUID$("{E77563CD-28AE-4822-9169-82F9BD934E23}") AS COM
INSTANCE enumCDDBMode AS uCDDBMode
INSTANCE m_MatchCode AS uCDDBMatchCode
INSTANCE m_UseFirstMatch AS Boolean
INSTANCE m_CdTextInfo AS STRING
INSTANCE m_Genre AS STRING
INSTANCE m_AlbumSeconds AS LONG
INSTANCE m_Tracks AS INTEGER
INSTANCE m_Notes AS STRING
INSTANCE m_Year AS STRING
INSTANCE m_MediaTOC AS STRING
INSTANCE strUserEmail AS STRING
INSTANCE m_DAODir AS ASCIZ * %MAX_PATH
INSTANCE m_strCDDBFilePath AS ASCIZ * %MAX_PATH 'STRING
INSTANCE strCDDBServer AS STRING
INSTANCE m_AllowSubmit AS Boolean
INSTANCE strAppName AS STRING
INSTANCE m_MediaId AS STRING
INSTANCE m_Category AS STRING
INSTANCE m_ArtistName AS STRING
INSTANCE m_AlbumName AS STRING
INSTANCE m_QueryString AS STRING
INSTANCE m_Revision AS INTEGER
INSTANCE strAppVer AS STRING
INSTANCE m_cdType AS INTEGER
INSTANCE m_ReadType AS INTEGER
INSTANCE m_hDlg AS LONG
INSTANCE frmFuzzy AS fFuzzy
INSTANCE frmSites AS fSites
INSTANCE m_dbWorkspaces AS Workspaces
INSTANCE m_dbWorkspace AS Workspace
INSTANCE m_dbDatabase AS Database
INSTANCE m_dbTableDef AS Int__TableDef
INSTANCE m_dbEngine AS Int__DBEngine
INSTANCE m_dbEngineEnable AS INTEGER
INSTANCE m_DAOAutoSave AS INTEGER
INSTANCE m_DAO_Update AS INTEGER
INSTANCE m_DAO_Enable AS Boolean
INSTANCE m_DeleteFreeDB AS Boolean
INSTANCE m_CDTEXT_Enable AS Boolean
INSTANCE m_internet_Enable AS INTEGER
INSTANCE m_QueryLocal_Enable AS Boolean
INSTANCE m_TOC AS STRING
'INSTANCE m_TEXT AS STRING
GLOBAL colTrackNames AS ICollection
GLOBAL colTrackCDNames AS ICollection
GLOBAL colTrackTimes AS ICollection
GLOBAL colTrackNotes AS ICollection
GLOBAL colServers AS ICollection
CLASS METHOD CREATE()
colTrackNames = CLASS "CCollection"
colTrackCDNames = CLASS "CCollection"
colTrackTimes = CLASS "CCollection"
colTrackNotes = CLASS "CCollection"
colServers = CLASS "CCollection"
frmFuzzy = CLASS "frmFuzzyMatch"
frmSites = CLASS "frmServerSites"
frmSubmit = CLASS "frmSubmitInfo"
#IF %DEF($PROGID_DAO_DBEngine36)
m_DBEngine = ANYCOM $PROGID_DAO_DBEngine36
#ELSE
m_DBEngine = ANYCOM $PROGID_DAO_DBEngine120
#ENDIF
IF ISOBJECT(m_DBEngine) THEN
m_dbWorkspaces = m_DbEngine.Workspaces()
m_dbWorkspace = m_dbWorkspaces.Item(0)
m_DBEngineEnable = %True
ELSE
END IF
END METHOD
CLASS METHOD DESTROY()
colTrackNames = NOTHING
colTrackCDNames = NOTHING
colTrackTimes = NOTHING
colTrackNotes = NOTHING
colServers = NOTHING
frmFuzzy = NOTHING
frmSites = NOTHING
frmSubmit = NOTHING
m_dbWorkspace = NOTHING
m_dbWorkspaces = NOTHING
m_DBEngine = NOTHING
END METHOD
'**************************************************************
'** GetPossibleRecord (STR Path of the local Files of FreeDB,**
'** STR Subdirectory, STR MediaID) **
'** returns a string with the name of the file, where **
'** the selected album could be in (without path) **
'**************************************************************
CLASS METHOD GetPossibleRecord(BYVAL sppath AS STRING, spKat AS STRING, spDiscID AS STRING) AS STRING
LOCAL dbDatabase AS Database
LOCAL dbRecordset AS Recordset
IF RIGHT$(sppath, 1) <> "\" THEN sppath = sppath & "\"
dbDatabase = m_dbWorkspace.OpenDatabase(UCODE$(sppath & "FREEDB.MDB"))
IF ISTRUE ISOBJECT(dbDatabase) THEN
dbRecordset = dbDatabase.OpenRecordset(UCODE$(spKat), %dbOpenDynaset)
IF ISTRUE ISOBJECT(dbRecordset) THEN
dbRecordset.findfirst(UCODE$("DISKID = " & "'" + spDiscID + "'"))
IF dbRecordset.NoMatch THEN
METHOD = ""
ELSE
METHOD = VARIANT_TO_STR(dbRecordset.collect(0))
END IF
dbRecordset.CLOSE
dbRecordset = NOTHING
END IF
dbDatabase.CLOSE
dbDatabase = NOTHING
END IF
METHOD = ""
END METHOD
As you can see is called in my DAO object freedb object, this in turn is regestriert.
Regards Peter
All through the nineties Visual Basic was incredibly popular. I believe there is some statistic I saw somewhere to the effect that there were more VB programmers than all the rest of the languages combined. I may be wrong about that, but VB was a truely powerful product. I used it hard up to around 2004 or so. After that I started switching to PowerBASIC because of .NET. That was pretty much the 'schism'. I tried hard to like .NET but just couldn't pull it off. I spent about 6 months working though about a half dozen VB.NET & C# books, and finally just admitted to myself I hated it and would seriously consider giving up programming if that was all there was.
Since I was pretty good at C coding I was considering using C as my main language; maybe learn a bit more C++ too; but I soon discovered I could have the best of both worlds with PowerBASIC. I could have small fast executables with no dependencies, plus the high productivity of an excellent standard BASIC dialect.
In the early 2000 time frame I don't think too many PowerBASIC users were making apps that would compare very well with Visual Basic apps in terms of fancy user interfaces, or containing high-powered COM functionality. But that has changed totally within the past several years thanks in large part to Jose's work plus of course the compiler itself now supports COM and OOP.
Another issue with me is that I felt no compulsion to follow the crowd with .NET due to its being what everybody else was doing in terms of furthering their carreers or anything like that (I'm old enough not to be worrying about that). I chose PowerBASIC because I like it and felt it to be my best choice for the coding I do. I definitely like procedural style programming, and only use OOP to a fairly small extent. I'd classify myself as a low level coder. That was one of the things I didn't like about .NET - too high level. Basically, with .NET, my impression is that most folks spend their time scouring the net for code snippets to do this that, or the other thing, or searching help for how you string nested object references together to accomplish what you want. To me, that isn't programming, and I get little satisfaction from it.
As things stand now with me I spend about half my time using PowerBASIC, and the other half with mobile devices and C/C++. If PowerBASIC produced a compiler for Windows CE I'd probably abandon C/C++ and only use the reference material on the Apis which are in C mostly.
Quote
Maybe I've misunderstood [...]
He means that if the loaded OCX creates an instance of another OCX not using a registration free technique, and this other OCX is not registered, it will fail. Of course. This is like if you use an standard DLL that has a dependency of another DLL and this other DLL can't be loaded because it is not in any of the suitable folders.
It would not happen if the OCX will check first if the other OCX is in the same folder, in which case it will load it using a registration-free technique, and using the CoCreateInstance way if it can't find it.
My point is that neither all that registry crap, nor type libraries, are needed. It is only a requirement of Automation languages.
Quote
I have conserns about PowerBasic, one of which being the appearant lack of interest in the world outside Power Basic.
That is interesting James, and I've spent a lot of time wondering about it too. All I can say about it is that kids in college are going to be pushed into the newer Microsoft technologies, probably C/C++/C# if in Computer Science/IT majors, and .NET if in various technical specialties. PowerBASIC seems to be something a small percentage 'discover' in one way or another. Alternately, many of us have been around programming languages practically since the beginning of PCs, so its not too big a jump to have discovered PowerBASIC somewhere along the way. The one thing I'm quite certain about is that I wouldn't let PowerBASIC's lack of exposure in the college classroom or anywhere else worry me in terms of its value. Its a gem. In these forums you'll find a lot of professional programmers fluent in many languages or expert in PowerBASIC who use it to earn a living.
In my particular circumstance where I work, we had a mission critical app we spent millions of dollars on, designed and written by a team of professional programmers, and the thing barely worked and ran so poorly we were always being told we needed to be buying bigger and more powerful servers to keep it running. It was costing us on average $250,000/year in contractor fees to keep it patched and running, and another $29,000/year in license fees for the particular app development tool used (I don't want to mention names). I replaced it with a PowerBASIC app whose total size is around 900K (in other words, it would easily fit on a floppy). Its performance in everything it does is all but instantaneous. The program is a single exe and a dll containing a custom control grid. So we now have a perfectly performing application thanks to PowerBASIC and are approx $300,000 per year richer. I'd call that value. So my take on PowerBASIC's lack of exposure in the mainstream programming world is that its their loss for not being aware of it.
Mr Zale will claim for some of that $300,000 ;D
It's really hard to tell if they where actually professionals + the fact of having a lot of programmers may result in poor guidance.
Incorrect/poor guidance is one of the most problematic issues imo.
Sounds to me that the person who wrote it in PB was a single programmer?
The guidance needed may be totally different then with the larger group.
The PB variant may have been the better choice from the start, you may call it poor descisionmaking to use a tool which costs so much money..
Imo you can not compare programming languages this way.
If you where very good with .NET i am sure you where fine with it too, .NET has many more (self)described features (but also some limits).
In PB nothing is described besides some silly helpfile and MSDN.
Also the debugging is a poor thing, for example when i use PwrDev code for debug i get code i really don't want to debug but stepping takes serious time.
Compare that to a winforms app where these details are hidden, the debugger skips these parts so you only need to deal with the custom code.
There are many aspects which are hard to compare, your PB app may have an issue later on not good solvable.., who knows?
Nothing is perfect.
Proficient programmers must have several tools at their finger tips, and select the best one to achieve the specific task in the shortest delay.
For large projects, i found that RAD tools + low level specific DLLs are the best combination.
...
Yes, I largely agree with you Edwin. You made all good points. In the context of the original poster's question about the value of PowerBASIC though, I think the situation of which I speak has merit in terms of bringing out the plusses and minuses of the different programming tools and development methodologies.
The app of which I speak was originally a mainframe app written in Algol and maintained by a talented individual within my organization for probably over 20 years. At about the time he transferred to another area of the organization, the company that supported the mainframe was phasing it out, so another app needed to be created, and at the time - around 1997, PCs had developed to the point where a PC application became possible. It was estimated that it might cost several million to create and it was a big project that lasted several years. A large outside programming contractor was hired to do the work (a large firm, again I won't mention any names). Around 2000 the application came into use, and there were continual problems. It was very slow, it lost data, and was expensive to maintain, as I mentioned. Interestingly, like .NET, the application ran within an interpreted environment, but it wasn't .NET.
About that time I transferred into the section of the organization that used this application and my role, in addition to developing mobile device data collection software, was to troubleshoot problems with this application and interface with the contract programmers who needed to continually fix bugs, modify features, etc. There was some overlap in the functionality of this app and some of the support software I had created in Visual Basic to support my data collection software. When I saw how horrible, slow, and poor the thing was it occurred to me I could probably easily redo that part of it not done by my Visual Basic app and end up with an 'in house' solution that actually worked.
Long about 2003 I was learning .NET and decided I'd take a crack at some of the database functionality of the thing. I was making some slow progress and all of a sudden there was an initiative from higher up in my organization to create an 'Enterprise Information Management System' and incorporate our application into that and ditch the failed monstrosity we had been using; write it off as a failure, so to speak. I and several of my collegues felt it would be a massive waste of more money and we would end up with another clunky hard to use, slow application from another outside contractor.
So I pulled out 'all the stops'; abandoned .NET (I wasn't proficient enough in its use yet) and essentially produced a Visual Basic 6 app as a 'fait accompli' that incorporated all the missing features not part of my other Visual Basic 6 applications we used in support of the data collection software. Naturally it was very fast and efficient and was tailored to meet our exact business specifications. This was of course easier for me to do as an 'insider' with intimate knowledge of our business requirements. The app was heavy into Microsoft database and ActiveX technologies. When I coded it all that mattered to me was to get it done really fast so as to eliminate the possibility of having our application done as a part of the larger 'Information Management System'. A lot of my code was real crap but we adopted it and it worked. It was later in around 2005 that I recoded the whole thing in PowerBASIC. That code I wrote with 'tender loving care'; really the best I could do (an SDK program), and everyone is well pleased with it. Just recently I recoded the original Visual Basic 6 (it was started in VB4) part into PowerBASIC too. All totalled, the thing (which was originally a mainframe app) comes in around 1200K actually (1.2M). Maybe 50,000 lines of code not counting includes.
Although my original Visual Basic app was heavy into ActiveX database and visual control functionality as was typical for VB apps, I opted for custom controls and low level ODBC Api database access in the PowerBASIC app (still use PB COM for Word and Excel access which is a big part of the app). Like many PowerBASIC users I found that custom controls in Dlls were an easier route to take than heavy COM components. Likewise one could end up with smaller apps with fewer dependencies and registry problems. I like the idea of distributing an app by telling someone to copy an exe and paste it anywhere they like and it will run! Certainly a far cry from Microsoft stuff which largely relies on heavy duty installation software.
This PowerBASIC app has had a big positive effect in my organization over and beyond what one might ordinarily think of as programming matters. Because it runs so fast over the network it has allowed several individuals to actually relocate their home away from our main offices in the capitol of the state. The older failed app it replaced could take several hours to perform a transaction over the network, and the PowerBASIC app only takes a few seconds (instantaneous if not done accross a network). So it wasn't really possible to work from remote locations.
Had I been more proficient in .NET at the time I could have used that to good advantage. It would have been somewhat slower than the PowerBASIC app, but I'm sure it could have been done. At the time though I was more interested in going low level than high level because of my personal inclinations I suppose. I had just survived the trauma of having invested a significant part of my life into Visual Basic and I saw how Microsoft simply abandoned it in favor of an interpreted programming environment. And then there was Dll h*** and registry problems. I saw the PowerBASIC solution as a better option. I have to say though that my organization is big behind .NET. It is a requirement of all software development projects let out to bid. We are solid Microsoft except for the anomaly of my PowerBASIC system. I do not get any static from anyone. Our IT department (I'm not part of it) ignores me and would prefer to believe I and my system do not exist. However, they can't argue with success.
When Microsoft abandoned Visual Basic 6 and I found that I disliked .NET so much, I was like many others really rethinking the issue of programming languages. Since DOS was finally falling by the wayside even in the world of handheld data collectors, I had to use C/C++ Microsoft tools for my programming there. I was seriously considering using C or C++ for my desktop development work too. However, I found that I also disliked the Windows Class Frameworks such as MFC that most C++ developers were using for their GUI C++ apps. Basically, I liked Charles Petzold style Sdk coding in C. Long about that time (maybe 2002) I discovered I could use that exact style of coding with PowerBASIC. That's pretty much when I became a true believer in PowerBASIC. I thought it was incredible I could code exactly the same in C++ or PowerBASIC; the programs were so similiar you had to look close to tell the difference. What this meant to me was that I didn't really need to learn two different application development paradigms for the two different platforms I had to work with, i.e., Windows CE and desktop Windows. True, there were two different languages involved, i.e., C++ and PowerBASIC, but using the SDK programming style they were essentially the same. Anything I learned while coding in Windows CE would transfer directly to my desktop PowerBASIC work and vice - versa. So there you have my principal reasons for thinking PowerBASIC is close to the ultimate choice for app development work.
Quotebut using the SDK programming style they were essentially the same
And once you understand that, then you become free to move from one language to another or to mix them together!;D ;D ;D
Well, i am not going to reply with such a long text :)
I wanted to tell you that we did/are made the move from the low-level stuff like Borland and PowerBASIC to .NET.
Coding in c# is easier, the IDE works with you, debugging is a breeze and also we prefer a built-in way to maintain the project (currently sourcesafe but we'll move on).
For myself i started .NET doing ASP.NET using VB but made the move to c# rapidly.
The first year and a half where daunting!
Then a few new people came in and they did c# (and T-SQL) for years and thus i learned a lot from them.
This was a real gain for the company and for me otherwise i doubt we ever got so far as we did right now.
ASP.NET, i know a lot about its technique but i truly(!!!!) hate the html part of it.
I am not a designer, i produce code, it took years before we finally got us a 'html-billy', this combination works, he doesn't know that much of the language and i don't care.
It's a lack of understanding development not to obtain the right people, i can't stress that enough, something that i meant before which may have applied to your situation.
So far i haven't found any speed reducing components in c# itself, many people complain about speed.
Problem is the ASP.NET MSIL being compiled over and over (even precompiled) and the combination of SQL server.
This simply requires the biggest computer imo to make it run propelry, ASP.NET will never run properly!
The language is fine but medium to large projects are a real pain to edit, the IDE is so slow..
Winforms, i haven't dealt with it much but i know it develops slightly better for some reason.
But i mentioned speed in c#, this is truly so, datasources, dictionaries and stringbulders are really fast.
Of course you'll need to learn c# and not think of (byte)pointers as i do in PB but the have alternatives which are really fast.
Main problem is that it is complex, very hard to understand how to combine parts together, i often refer to sending a mail, this requires certain objects but can not be solved unless you look it up online.
No beginner can solve these kind of complexities, they are to 'low-level', simply having a simple mail object where you add attachmentsfiles and all the parts is not what it brings.
In some cases you need to cast objects like during the http context request stuff, how would i know when?
(Unpredictable but these are rare though)
For me PowerBASIC is a dead end, it was all i needed several years ago and currently i am no longer the only person writing those modular includes.
My colleague can program PB if i am not around.
As i see it now a compiler like PB has simply to much options, it should be a bare bones compiler classes included but no DDT stuff, no graphics.
Simply PBDLL6 with classes should do, maybe activex support oh and.. unicode all the way?
Of course it would be hard to keep on selling since there would be no new features.
I will be doing the few PB apps/dlls for several more years but even those are extended with .NET support so more users can maintain that.
As you see, an opposite story and also reasonably succesful.
And let's not forget, i really liked PB and doing pointers and such but if you learn new things older things it may no longer forfill the needs.
I fully understand where you are coming from Edwin.
I believe my reason for taking a low level coding approach using strictly SDK style coding against the Windows Api has more to do with my Windows CE work than anything else, coupled with the fact the material itself is so overpowering in its complexity that there simply isn't enough of me to go around to master both low level Windows Api coding and .NET high level coding. People often lament about there being no tutorial book written about PowerBASIC from which one could learn the language. And this is a problem. However, there is also a thing called 'information overload'; kind of the problem in reverse, and that was the problem for me with .NET. Too much information and not enough time! Petzold's recommendation was to sleep less!
Back to Windows CE though, what I had to do there was recreate all my DOS data recorder data collection software in Windows CE. I imagine most of us here were experts at DOS coding and knew all the tricks to write incredibly efficient programs. My DOS programs created with QuickBasic & PowerBASIC DOS were designed for very, very, fast high speed data entry of large amounts of field data (tree info). For example, users never had to hit an [ENTER] key or [TAB] key to move to the next data entry field. In addition, most of my programs provided for entry in a full screen grid type setup. Well, trying to recreate something like this in Windows isn't easy. Not easy at all. And it had to be done. My greatest fear once it became clear that we would need to move from DOS to Windows CE was that the folks simply wouldn't use the newer data recorders running funky Windows programs and would revert to paper data entry which is a nightmare. And this has indeed happened even though I've created Windows CE programs just as easy to use as the DOS ones. To do that sort of thing though required me to delve pretty deep into the low levels of Windows. Basically, I create my own edit controls and custom control data entry grids and such. But what with all that work I guess I found it more efficient for me to use low level coding for everything rather than just Windows CE. Maybe I'm wrong, but it seems like it would have been more work to master the Windows Api just for Windows CE coding, and master .NET too for desktop work. And after all, while one amasses many lines of code to do a simple thing using the Api, there is a lot of copy/paste (clipboard inheritance!) involved to ease the task. I mean, after all, who starts a new Windows program from scratch?
But I wouldn't say I'm totally disinterested in .NET. I especially like the things you've done in integrating various levels of .NET functionality into your designer, and Jose's work with using .NET components from PowerBASIC is also interesting. I'd like to have more time to explore that. What I've found is that I only have so much time to spread around, so I have to pick and choose what I learn to use. I wish I was smarter that I could pick up stuff faster, but I find that it takes me quite a bit of time to learn these various things.
It's easy. The problem is that you can't use many of the .NET classes directly and you have to write wrapper assemblies.
That's not a big deal to me, i write those in visual studio and include (link) them in the PB code.
At the end we'll drop PB completely, it's just a transition phase.
MS C++ is the most powerful toy here since it allows the mix, never seen actual code but i know it allows mixing .NET with its own code.
Powerbasic has grown over the years and in recent years I believe Third Party developers have made a big difference.
First, Powerbasic has seen many useful features in third party tools and then implimented similiar (albeit in their own way) features in the PB compiler.
Third party developers created visual design tools before PB did, but they jumped on the bandwagon and added DDT and even a Graphic control.
The PB language gets richer and richer in each new version and the third party developers just have to stay one step ahead of PB to keep their own tools relevant.
The key to using Powerbasic is taking advantage of reusable code, whether they be third party tools or your own library code. The key to fast development is code reusability.
Personally I prefer DLL's over COM components.
What I really like about PB is how reliable the compiler is. It generates fast executing apps and I don't have to worry about serious bugs in the compiler to mess things up.
I also like PB because it has a lot of low level stuff. I am using things like pointers all the time, to write mission critical code.
PB's string processing command set are by far the most powerful you will find in any language. I doubt there are any other compilers that come close to the power of Powerbasic when it comes to string processing.
BASIC itself as a language is far more readable than other languages IMO (makes code maintainance easier) and PB follows the Microsoft Basic language syntax which has been around a long time. I also feel that procedural coding is faster and better than Obect oriented coding, yet PB supports OOP for those who want it.
Microsoft languages have become bloated, IMO. As hardware improves, MS compilers get more bloated, so one tends to lose the benefits of the newer hardware.
PB is "lean and mean" so one really benefits from improved hardware.
>and the third party developers just have to stay one step ahead of PB to keep their own tools relevant.
To make sure we understand each other, many of these light-weight compilers (freebasic, bcx, PowerBASIC and PureBasic) implement features which are not finished or do not work as desired.
While DDT offers a pretty normal windowprocedure the rest of it is simply so-so from a technical point of view.
Unf. many many users like an easy route, this is in this case the PB helpfile presenting all the features and limits and seems enough for those people.
It's hard to explain why i find it just another poor implementation to the majority of the users.
I really don't care if PB brought us a supurb Visual Studio lookalike, i would have stopped right away if that was the case, i would not have mind it at all(!)
Other compilers offer similar or even worse implementations, it's then still expected by users to follow the native features and not some home-brewed feature.
PwrDev offers support for DDT and SDK but to make things work the same some code had to be adjusted towards DDT.
Therefore i say, just bring a bare bones compiler so end users using a third party tool don't have a choice.
If you purchase a designer (like PwrDev) a user should not have to make a choice, just bring him a single but good form engine.
Therefore all third party tools will at some point fail (and not because some native feature was that great, it wasn't).
The above is just an illusion, there is no money to earn if you bring out a bare bones compiler and forget about it.
It is most likely a poor market and you'll need to bring new features.
Problem is that for most of these tools you can not bring them as they are in their current state, you'll need a great IDE and debugger nowadays.
Better include support, static linking, ActiveX support, classes and so on.
Iow there is a moment a compiler simply has to many features or has to little features to become a real competitor for existing programming languages (like MS VS).
I truly like the current classes implementation but then, many things come so late..
Well, I guess its nice there is such a large assortment of programming languages and development languages out there for us folks to choose from!
Your negativism Edwin made me wonder why I like PowerBASIC as much as I do. And as an aside, I always seem to see folks screeming for static linking. I can't imagine why that is thought to be such an advantage. Obj files aren't even portable.
I've worked for years with fancy development environments. Right now I have Visual Studio 2008 Professional, Visual Studio 2003 Enterprise Archetect, Visual Studio 6 Enterprise Edition, as well as lots of other fancy and modern development tools. I use them frequently for my C, C++, and Visual Basic work in desktop Windows and Windows CE. They have their good points and bad points (The latest Visual Studio is a resource hog and always wants to be connecting to the Mother Ship). But in the end app development comes down to writting lines of code in a text editor, and for that a decent coder could even get by with Notepad. So for me its the basics that really count. For example the point Chris Boss made about string handling. That is not a minor thing. In fact, I consider strings to be one of the major hinderances in any of the C family languages. Of course, the situation in C is simply disasterous. C++ String classes have helped tremendously in that regard. However, I wouldn't say they match PowerBASIC. Its simply easier to have string handling built right into the programming language as opposed to adding it in through string class includes. At least that's my opinion.
I also can't help thinking that the type of development one works on mostly might have some effect on what one thinks to be the best choice. I don't do anything with internet programming, web pages, html, or anything like that. I do a lot of database work and number crunching. Also, like I said, high performance data entry screens for data recorder applications. The console compiler is a real workhorse for me. For my GUIs I don't need 'skins', OpenGL whatever that is (I've no idea!), fancy buttons (the regular, ordinary, standard ones that come at no extra cost are fine with me), or anything like that. However, my code has to work.
Another possible take on the issue for me is I don't care anymore for 'throw away' type knowledge. By 'throw away' knowledge I mean that which I had to do with Visual Basic 4 through 6 when Microsoft abandoned it. All that knowledge was tied to the workings of an ide and a particular programming paradigm that has been abandoned. And I'm not sure jumping on the .NET bandwagon is a great idea right now.
In 1981 Microsoft gave us DOS and BASIC. In 1991 they killed DOS, deprecated BASIC, and gave us Visual Basic, in 2001 they deprecated Visual Basic and gave us .NET. What do you think is going to happen to .NET in 2011? Its just about had its 10 years, you know. So if it takes a year and a half to totally master it as Edwin said if one would start now one could possibly be an expert at it when Microsoft finally deprecates IT. I don't know and don't follow Microsoft's machinations very close, but I'd rather stick to more fundamental programming techniques that have a longer shelf life than what I've got from Microsoft's technologies and IDEs. When I was younger struggling to learn difficult things then throwing away that knowledge came easier than now. I'm 57 and have to be careful what I sink my time into.
Static linking makes it possible to avoid code to be debugged, when precompiled it doesn't need to be compiled again.
It's not really a matter of selling objects however, it is possible.
>our negativism Edwin made me wonder why I like PowerBASIC as much as I do.
You are right, since a year i am much more negative but somewhat unrealistic, can't handle certain behaviour anymore.
It must be me getting grumpy, i have to understand that while i may have a point i am the one being negative.
I guess i need to move on and leave the programming scene, my interest has changed and may be the reason abandoning PB as well (slowly though :) ).
>The latest Visual Studio is a resource hog and always wants to be connecting to the Mother Ship
Yes, all versions are, you'll need a good computer with ram to not get to frustrated :)
ASP.NET with over 10 pages is getting frustrating already.
Though the outcome is rather good but sometimes to slow as i mentioned before if not executed on a good server.
I believe winforms (an ordinary win32/64 executable) will work just fine.
.NET is not slow internally with it's objects, some MSIL overhead makes things slow.
>What do you think is going to happen to .NET in 2011?
I don't think so, this is currently a platform versus a VB run-time library situation.
Anyone can create code and compile it and does not need MS VS.
.NET appears very stable to me and is very large.
I even believe web will change towards 'WPF via browser' (a reliable binary which is supported by the browser and runs in a sandbox and is not html based).
>So if it takes a year and a half to totally master it
I am not a master, after that period i was lucky to get some colleagues to help me even more but after the first period i understood the more commonly used mechanisms.
Frankly, it's fun i understand the workings of ASP.NET on some parts better than my colleagues, they often ask me to work out a mix between javascript and ASP.NET/html code for example while i really dislike the html part of it :) (just funny)
I always have a technical interest for things, therefore...
>I'm 57 and have to be careful what I sink my time into.
Gee, i am 45 and had two burn-outs and thinking each day when to quit this programming job.
I like what i do but i need to see different things, it's hard to make a switch, especially when the pay is serving me well.
57 and 'worrying' about a language, i would not i guess when i am 57.
If i only knew what to do when i quit my job... :)
Personally I think Powerbasic is one of the best compilers around.
There are two types of programmers IMO.
(1) Those who want to work at a low level and have a compiler which allows them to push their apps to the limits.
This requires one be an experienced API programmer though, but once you become experienced with the Windows API
there isn't much you can't do.
(2) Those who need as high level a programming tool as possible, so they can develop apps as quickly as possible.
While PowerBasic isn't that high level, especially its IDE, I think the current support by Third Party developers fills that void.
For those who prefer 100% code and a more SDK style of coding, FireFly is probably the best tool around. There are also some
other Visual tools that satisfy other PB users.
EZGUI tends to go against the common PB users concept of how to write PB apps, so it serves a smaller market, but for those who use it,
it pushed the limits of Windows development with some very high level (and low level too) features. For those users the combination of PB and
EZGUI is a powerful combination, but it would never have been possible without the PB compiler. EZGUI was written in PowerBasic 6.1.
You can't please everyone, so no one addon tool will solve everyones needs, but the more different addons to PB there is, the more choices there are
and PB gets more powerful.
The next generation of PB addons will offer even more possibilities. For example, EZGUI 5.0 is in development and one of the most exciting features is
an OpenGL Canvas control. I could never have written it with anything other than PowerBasic (at least not as well).
There are a number of aspects of Powerbasic which I find critical to quality software.
(1) Small executable size and fast execution speed.
Few languages can compared to PB in this area.
(2) PB is not only BASIC, but it has the perfect BASIC syntax, based on the core Microsoft Basic compilers from long ago.
When other languages treated things like GOTO or GOSUB obsolete, PB maintained such long time constructs.
PB concentrates on being a Procedural language, even though it has added OOP, one can still write a 100% procedural app.
BASIC is IMO, the most readable programming language there is. I have dabbled with other languages like Pascal, Fortan, C, LOGO, but I have never
gotten very far, because the language syntax never appealed to me. I would rather work with assembler, than have to learn a second language like C.
I strongly believe that it is better to work with just one language primarily, rather than work with multiple languages at one time (ie. Basic, C). IMO it is better
to learn just one high level language well and one low level language to support it, such as assembler.
(3) PB is sound as a rock (reliable)! One would be amazed at how shaky many compilers are. Some have criticized Powerbasic because they don't provide updates
on a regular basis, like say every few weeks. Want to know why ? IMO, its because unlike other compilers, PB is rock solid and there is not reason to update all the time.
Some compilers update every few weeks (ie. some of the less professional BASIC want to be's on the web) because they are fixing lots of bugs. Not so with Powerbasic.
I have a lot of confidence in the PB compiler.
(4) PB is likely the richest Basic language as far as command set, especially when it comes to things like strings.
Things like Code pointers, data pointers, register variables, variety of data types (ie. quads), While so called "moderns"
call commands like GOTO and GOSUB obsolete, I find commands like GOTO, GOSUB, ON GOSUB critical tools in my software
development. Anyone who has worked with assembler will appreciate how important such commands are.
Visual Basic always left me wanting. I liked the high level aspect of VB, but when I wanted to optimize something or do
something lowlevel, VB always left me wanting.
(5) COM is not the panacea of code reusability.
While COM has some nice aspects to it, it has failed IMO in its ultimate goal of the perfect method of code reusability.
The Windows registry is glutted with COM component registries, which may be one reason Windows slows to a snails pace after
a few years. The installation of apps with COM components is a pain. DLL's are just copy and run, but COM components can have a real down
side. Just compare the Windows API docs when it discusses API functions (DLL's) compared to the parts that discuss COM components in the
operating system. Without a Visual development environment which is atuned to COM components, a procedural coder is totally lost.
COM tends to add more code IMO, rather than decrease it. COM adds overhead, which slows it down a little.
This is one reason I chose OpenGL over DirectX. At least OpenGL is an API, rather than a bunch of COM classes.
If so called code reusability methods, like COM, are so great, why then does each new generation of compilers produce bigger and bigger (and more bloated)
executables ? Why are the latest runtimes, like dot.net, so huge ?
Even compilers like C++, have all sorts of runtimes with them supposedly to make programming easier.
Often the advances in new hardware (ie. faster CPUs) are lost because newer programming languages require faster CPUs and more memory.
Why was Vista such a big failure ? It was so slow (a memory hog) compared even with its own predecessor (Windows XP).
While PowerBasic may have a learning curve, it is well worth the investment of time to get the most out of it.
Rather than looking for more ways to make everything more Visual (meaning the programmer doesn't have to do anything anymore), it would be better
to start teaching programmers how to write real code.
How many programmers today could write a large and complex app by just hand coding without the benefit of a Visual Designer ?
Probably very few.
I am impressed when I see some of my own customers using EZGUI's runtime alone without its Visual Designer to write large and complex
applications. No drag and drop. Just hand coding the entire app. Take the visual designer away and see whats left of the programmer ?
Visual basic users (in the old days) were programmers, but with each new generation of VB, the dependency on Visual Design and drag
and drop components became the mainstay, to the point where anyone who could drag and drop a component felt they could program.
PowerBasic, puts the "programming, back into programming"!
Quote
There are two types of programmers IMO.
(1) Those who want to work at a low level and have a compiler which allows them to push their apps to the limits.
This requires one be an experienced API programmer though, but once you become experienced with the Windows API
there isn't much you can't do.
I'm one of these. I don't need/like fancy IDEs, debuggers, intellisense, etc. I just need a decent editor.
Quote
(2) Those who need as high level a programming tool as possible, so they can develop apps as quickly as possible.
And instead of programmers, they become tool users, unable to write an application without them.
Quote
(5) COM is not the panacea of code reusability.
While COM has some nice aspects to it, it has failed IMO in its ultimate goal of the perfect method of code reusability.
The Windows registry is glutted with COM component registries, which may be one reason Windows slows to a snails pace after
a few years. The installation of apps with COM components is a pain. DLL's are just copy and run, but COM components can have a real down
side. Just compare the Windows API docs when it discusses API functions (DLL's) compared to the parts that discuss COM components in the
operating system.
You're still looking COM from a VB perspective. Low-level COM servers are as fast and lightweight as non COM DLLs. With a compiler like PB, that supports direct interface calls, you don't need to bloat the server with type libraries and property dialogs, you don't need to register it, and you can just copy it in your application folder, like any other DLL. A low-level COM server IS a standard dll, and it is loaded with LoadLibrary.
Quote
Just compare the Windows API docs when it discusses API functions (DLL's) compared to the parts that discuss COM components in the operating system.
Yes, do it. But choose the right documentation: the one that discusses the methods for C++ programmers, not the documentation for Visual Basic programmers. You will notice that there is not much difference from the ones that discuss procedural APIs.
Quote
Without a Visual development environment which is atuned to COM components, a procedural coder is totally lost.
No. Only those that intend to use COM without first learning COM programming are lost. I'm a procedural programmer and I don't have any problem to use COM without any visual designer.
Quote
COM tends to add more code IMO, rather than decrease it. COM adds overhead, which slows it down a little.
Again looking it from a VB perspective. Low-level COM servers don't have overhead, bloat or speed penalties. Forget for a moment all your previous experience with VB and all that Automation crap.
About two thirds of the Windows APIs are implemented as low-level COM servers.
COM classes nicely allow you to encapsulate code and data.
Some months ago I went into a famous library here in Milan (Italy) searching for some good books on low COM.
I was not able to find one even if that library has one complete floor (many squares meters) dedicated to Informatics.
So I asked to the desk about one or more COM books and I got this reply: "COM mmmm ??? ah aaaah ok: No. I'm sorry it is an old technology and we do not have anymore books on that"
I replied: "COM is an old technology???, Can you realize that at least half of the world is driven by COM technology in one way or the other? And this is not going to change other that increasing?"
Well, they looked at me like a was craxy and passed over to the next customer.
I went into another direction and ordered some Don Box books in Amazon.
A book on COM I like a lot Eros is "Inside Distributed COM" by Guy Eddon and Henry Eddon. I think they are father and son. Its really mostly a COM book in spite of its name. It actually shows how to code the writing of type libraries and unusual stuff like that I havn't seen in other COM books. Also good material in it on Connection Points; in fact right now I'm working on another one of my tutorials about connection points where I convert my custom control example I have posted here in Jose's forum into a visual COM control which implements the connection point interfaces.
There was about a ten year period of time from about the mid eighties to the mid nineties where I wasn't doing any programming at all. Where I had left off was with QuickBasic 4.5 I think, then I got back into programming again real heavy in the mid nineties with VB 4, 5, and 6. I just couldn't believe what had transpired in those ten years in the computer world! Visual Basic really intimidated me at the time because I had to learn both Windows and Visual Basic itself. It really didn't seem like programming even. It seemed more like learning how to use an application rather than writting one. One refreshing thing I've discovered in my forays into the Linux world is that programmers there still use C a lot and are mostly coders.
PowerBASIC seems to fill a gap or vacuum. Programming right now seems to be dominated by big RAD application frameworks that create monsterous applications. Naturally they have heavy dependencies on supporting binaries of various types. The situation with C++ is something I know about because I use that language a lot. As much as I love PowerBASIC, I have to admit that C++ seems to have a small edge on PowerBASIC both in speed and executable program size; however, they are real close, the difference in most cases isn't terribly big in my opinion. However, when C++ programmers go to write applications they almost inevitably saddle themselves with so many binary dependencies (Windows Class Library Frameworks mostly, but also others) that they end up with bloatware products. Kind of like using a Corvette Stingray to pull a trailer. And most of the young kids learning C++ are brainwashed to the effect that procedural programming is bad and OOP is the only thing that is good.
So when I discovered PowerBASIC in the late nineties it kind of represented a bringing together of my mid eighties programming world with the realities of modern Windows programming - a continuity, so to speak, that was lost to me due to the shock of Visual Basic. Its a funny thing about Visual Basic; while I was using it (and I used it heavy for many years) I really had no idea what COM was. Everything about Visual BASIC was COM - through and through, from the COM Control Container, which is essentially what the IDE was, to all the controls its users drag and drop on its forms. Truth be told it was a tremendous and awesome achievement and testament to the power of the COM paradigm which formed its basis. I never really learned anything about COM until I came into the PowerBASIC fold. Now I'm glad I have the oportunity to learn and use it. Its no longer 'magic' to me; but rather something I can learn and comprehend. But like Chris said, if you fall in his second camp, i.e., those only interested in quick results, then the Visual Basic or other class framework approach is the one to take.
You know though, even if you fall in that second catagory Chris described, i.e., only interested in quick and dirty results, PowerBASIC still has the much maligned (at least by some here) DDT framework. And if that is used you still won't end up with multi-megabyte sized executables. It only adds a scanty few K to what an SDK coder would produce. I don't use it myself, but newcommers find it a good starting point. In fact, if it wasn't for DDT, PowerBASIC might not have been as successful as they have been. It seems that a really significant number of new users come from the old DOS Basic background, and find it a good place to start if wanting to get into programming again. I imagine for every new user that is an experienced or professional programmer coming from some language like assembler, VB, C, C++, or something else, there are probably 10 or 20 coming from the old DOS basic background I alluded to. The amazing thing about PowerBASIC though (at least to me), is that it meets the needs of so many real hard core advanced programmers such as many here and in the PowerBASIC forums that could easily write advanced code in any language.
Eros,
The book you want for learning low level COM is:
"Inside OLE"
by Kraig Brockschmidt
Published by Microsoft Press
COM is the wrong term to use when looking for books on it.
COM is based on OLE and OLE is at the core of COM (and DCOM).
This book is suppose to be the best book on the subject from what I have read.
You should be able to find it "used" on the web, since it is not published any more.
Another book I found which may be useful is:
"The COM and COM+ Programming Primer"
by Alan Gordon
Published by Prentice hall
They are big books and I would expect that it would take a good year to dig deep into them to fully understand COM at its lowest levels.
Just a comment about Visual Basic.
VB is not simply a Windows compiler (programming language).
It is in its own rights an engine , a "black box if you will", especially more so than say C++
For example it does not use native windows controls for its standard controls.
It uses its own Superclasses of the native controls (the class names all start with the word THUNDER).
Also VB does not always even follow the rules of the Windows API I have found.
For example, my EZSprite library can subclass any native windows static control and add a 2D sprite engine to it.
EZSprite depends upon the standard support of WM_PRINTCLIENT which natives Windows controls all support.
EZSprite won't work though with Visual basic!
Why ?
Because the VB static controls (Image, Picture, even a Frame) don't properly support WM_PRINTCLIENT !
Now if Microsoft who created Windows can't even follow their own rules when making a compiler (VB), then one must question how they design stuff.
EZSprite works fine even with Powerbasics Graphic control, since DDT does not modify the core workings of the ownerdraw static control. PB follows the rules.
To be fair, Visual Basic is really not a Windows compiler, but it is a "black box" protending to be a Windows compiler.
I have nothing against a "black box" approach, since even my own EZGUI is a "black box" of sorts, but one should make sure that such a "black box" follows the rules of the Windows API so one can easily integrate any standard SDK (API) technique with it.
I would venture to say that a lot of Microsoft technologies are simply "cludges" (fudging it) written on top of the Windows API, likely not always following the rules of the core API.
A good example of this is the "mismash" in the API itself of partly procedural API's and partly COM based API's. Some API's can only be accessed via COM.
Even the GDI+ stuff are a mess since they are classes not API functions.
When MS first documented the flat API, they still did not recommend using them and now documentation of the flat API appears to have vanished.
I have found that I have less problems by avoiding the more "leading edge" technologies in favor of the long time core API's in Windows.
One good example are DIBSections. They have been around for a long time, a number of higher level OS DLL's actually use them internally (so DIB's aren't going anywhere) and you can do amazing things with them. With Powerbasic is its low level command set (ie. pointers) I can write all sorts of complex graphic stuff using DIB's and it will work on Windows 95 all the way to Windows 7 with little fuss.
Quote
Even the GDI+ stuff are a mess since they are classes not API functions.
GDI+ is a flat API. The classes are not part of it, but a collection of wrappers provided with source code to C++ programmers for convenience. The only messy part is the documentation, only provided for the C++ wrappers.
Microsoft has always developed its technologies as flat APIs or as low-level COM servers. Then, for convenience of VBers, it wrote ActiveX wrappers, e.g. CDO is a wrapper on top of MapiX (extended MAPI), ADO is a wrapper on top of OLEDB, etc. But you can use GDI+, MapiX, OLEDB, etc., directly with PB.
Now, they continue doing the same, but instead of ActiveXs for VB6, they provide wrapper assemblies for VB .NET and C#.
Jose,
The interesting thing about the GDI+ flat API was that Microsoft strongly recommended "not to use it", but to use the C classes instead.
A normal API would be encouraged to be used.
Notice the current API docs about GDI+:
http://msdn.microsoft.com/en-us/library/ms533969(v=VS.85).aspx (http://msdn.microsoft.com/en-us/library/ms533969(v=VS.85).aspx)
MS recommends not to use the flat API, won't provide any support for it and don't provide any details about each API, except a very simple declaration for each and what class one should use instead.
MS refers to GDI+ as a "class based API" for C++ programmers.
That surely doesn't sound like a positive recommendation for non-C++ developers.
Fortunately PB'ers have been smart enough to figure it all out and take advantage of that flat API.
Quote
The interesting thing about the GDI+ flat API was that Microsoft strongly recommended "not to use it", but to use the C classes instead.
Maybe it thinks that C++ programmers have been spoiled by OOP and are unable to safely use a flat API ;D
Quote
MS recommends not to use the flat API, won't provide any support for it and don't provide any details about each API, except a very simple declaration for each and what class one should use instead.
Who needs them? The reference guide that I compiled ( http://www.jose.it-berater.org/gdiplus/iframe/index.htm ) has been highly recommended in several forums and blogs. Non C++ programmers found it more useful that the M$ documentation. As I have included both the C and PB declares, even ansi C programmers have recommended it.
Quote
MS refers to GDI+ as a "class based API" for C++ programmers.
Nonsense. It is a flat API. The C++ classes are just wrappers.
If you have the SDK, you can ascertain it, since the classes come as source code. Almost all of the methods do little more than calling the appropriate flat API function, e.g.
inline UINT
Image::GetEncoderParameterListSize(
IN const CLSID* clsidEncoder
)
{
UINT size = 0;
SetStatus(DllExports::GdipGetEncoderParameterListSize(nativeImage,
clsidEncoder,
&size));
return size;
}
The only adavantage to C++ programmers is that as C++ classes support overloading and default values,many of the methods are a little easier to use.
Quote
Fortunately PB'ers have been smart enough to figure it all out and take advantage of that flat API.
And programmers of any other language that can't use C++ classes.
I am always using the Flat API and the procedural model, even with Dot.NET, because this make my code highly portable from one platform to another, and from one language to another. 8)
For me using PB with the SDK syntax, is like writing C with a "basic" syntax. Hower understanding C is a mandatory when you want to learn and use the latest technology (see the Direct2D examples posted by José and myself).
...
Hadn't ever really thought of this before, and in terms of some of Chris's comments about preferring 'regular exported procedural' type Dlls rather than dlls containing code in the form of COM objects, I can't see any reason why it has to be 'either/or'. Couldn't you put both regular exported procedural code plus COM components in the same Dll? After all, even the COM runtime has to use a plain ordinary exported procedural function - DllGetClassObject(), to get its first pointer to an objects's VTable. So what I'm saying is that if you don't like the registry you could still stick your favorite procedural functions in a dll, intermixed with COM objects which could be loaded with DllGetClassObject(). If you don't want to use the Service Control Manager (SCM) to load the COM objects you could even do it yourself. Like I said, I hadn't ever done this, but see no reason why it wouldn't be fine. Jose?
This is all you need to do to load and activate an in-process COM server:
LOCAL hr AS LONG ' // HRESULT
LOCAL hLib AS DWORD ' // Library handle
LOCAL szLibName AS ASCIIZ * %MAX_PATH ' // Path of the COM server
LOCAL pProc AS DWORD ' // Procedure address
LOCAL pIClassFactory AS IClassFactory ' // IClassFactory interface
LOCAL pUnk AS IUnknown ' // The requested interface pointer
LOCAL rclsid AS GUID ' // CLSID that will associate the correct data and code
LOCAL riid AS GUID ' // IID of the interface to be used to communicate with the newly created objec
szLibName = <Path of the server>
rclsid = GUID$("<guid of the class>")
riid = GUID$("<identifier of the interface>")
' // See if the library is already loaded in the address space
hLib = GetModuleHandle(szLibName)
' // If it is not loaded, load it
IF hLib = %NULL THEN hLib = LoadLibrary(szLibName)
' // Retrieve the address of the exported function DllGetClassObject
pProc = GetProcAddress(hLib, "DllGetClassObject")
' // Request a reference to the IClassFactory interface
CALL DWORD pProc USING DllGetClassObject(rclsid, $IID_IClassFactory, pIClassFactory) TO hr
' // Create an instance of the server or control
hr = pIClassFactory.CreateInstance(%NULL, riid, BYVAL VARPTR(pUnk))
No registry entries, no type libraries, no DLL/OCX hell, no nothing.
It is like the the old good LoadLibrary/GetProcAddress to call procedural functions, with the difference that, instead of getting the address of a single function, you get the address of a pointer to a virtual table to the addresses of the several functions (they are called methods in COM lingo, but are the same that procedural functions) that integrate an interface.
Looks as if most ex-VBer's are spoiled for life to understand low-level COM.
A COM server, DLL or OCX, can of course contain procedural functions, exported or not, for the simple reason that it is not a different kind of DLL, but a standard DLL.
Maybe it is even useful on .NET assemblies which are com-exposed, not sure, should be i guess.
Quote
Looks as if most ex-VBer's are spoiled for life to understand low-level COM.
No, I've understood that quite well for a long time now, and have lots of examples of doing just that down in my COM tutorials. Its just that the idea of exporting additional functions besides the four required by COM (DllCanUnloadNow, DllGetClassObject, DllRegisterServer, DllUnregisterServer) struck me as a novel and interesting proposition that I hadn't really thought of before, but its possibility simply follows from the fact that you have tried to make plain many times here and elsewhere, and that is that the Dlls that house COM objects aren't special in any way; they are just ordinary Dlls which must export several specific functions if they are to be accessed by the COM implementation within Windows.
And I don't think all the VB'ers were ignorant of code writing skills. Maybe a lot of them but not all. Especially in the field of database projects, VB was simply easier to use to put a sophisticated database back end plus front end together than any of the C/C++ oriented tools, and I think a lot of experienced coders from other languages moved to VB. That was back in the nineties. Where they all scattered to now I don't know; probably most to .NET and PB picked up a few here and there.
The only issue that strikes me as one that would take special care regarding mixing one's own procedural library functions in a dll mixed with COM objects is that one wouldn't want COM reference counting mechanisms to unload the Dll ignorant of the fact that it was still being used in terms of simple procedural functions contained within it.
It won't happen because LoadLibrary also keeps a reference count.
Quote
The system maintains a per-process reference count on all loaded modules. Calling LoadLibrary increments the reference count. Calling the FreeLibrary or FreeLibraryAndExitThread function decrements the reference count. The system unloads a module when its reference count reaches zero or when the process terminates (regardless of the reference count).
There are many servers that mix procedural functions and interfaces, such urlmon, htmlhelp, ATL, Direct 2D and even the .NET runtime.
Quote
And I don't think all the VB'ers were ignorant of code writing skills. Maybe a lot of them but not all.
I said that "Looks as if most ex-VBer's are spoiled for life to understand low-level COM." And this is not a judgement about their code writing skills. If I had been a VB user, probably I would not have learned anything about low-level COM. I learned it out of necessity.
But many have the misconception that COM is bloated, slow and evil. And it is not. Low-level COM was designed by C programmers and is pretty straightforward and not much different as using procedural functions. I started using it with PB writing procedural wrapper functions that used CALL DWORD and function prototypes.
Automation was designed by the Visual Basic team, and to allow to use it filling values in the properties grid individually, they come with the get/set properties (there are only methods in low-level COM). Therefore, where low-level COM servers use methods with several parameters, just like procedural functions, Automation servers designed to be used in visual designer come with properties for each value. And many OCXs incorporate their own property dialogs, some of them very sophisticated, that add a lot of bloat to the server and are only needed by visual designers.
And then, to provide intellisense, they needed to have the interface definitions, and they invented the type libraries, that add more bloat to the server, unneeded to work with it because they only are needed by the visual designer.
They also wrapped the common controls with OCXs, to allow to use them filling values in a property grid and to provide intellisense. And because they are ActiveX controls instead of custom controls, they need an OLE container. More bloat.
And then invented new data types, variants and safe arrays, and forbid the use of pointers and null-terminated strings because VB doesn't support them. With low-level COM you can use all the same data types that with procedural functions and in the same way.
And then all that registration mess that originated the OCX hell.
etc...
Quote
It won't happen because LoadLibrary also keeps a reference count.
I was thinking that too, but wasn't sure.
Sounds like you dislike anything having to do with IDispatch, and anything having to do with supporting property sheets and all the rest of the interfaces that go along with ActiveX controls able to be hosted by scripting languages Jose. I can't say I blame you because I've studied all your code and everything you had to go through when you first figured out how to get those things to work with PowerBASIC 7 back around 2005. Talk about jumping through hoops (an American English colloquialism meaning having to endure tremendous trials and difficulties to accomplish something). Talking about colloquialisms, this thread's starter used one many here on the continent might not be familiar with and that is the 'not in Kansas' bit. That's actually a somewhat rare and unusual American English expression whose meaning is something to the effect that we're not living in rustic farm like simplicity anymore in the field of programming (Kansas is a mostly rural and agricultural area of the American mid-west). Just though I'd mention this sort of thing because I guess I'm the only one of the moderators here on Jose's forum that speaks native American English, and I oftentimes lapse into colloquialisms that in afterthought I realize may not be understood. And I have nothing but the highest respect for all the PowerBASIC members whose primary language isn't English but have managed to learn it. I myself studied German for many years but eventually discontinued my study of it. I simply had no one with whom to converse (Leider hatte Ich niemand mit dem zu sprechen!), as here in America almost nobody speaks more than one language (and the folks from England maintain we can't speak English either!). :)
Also, regarding your comments Jose about all the bloat associated with *.ocx (ActiveX controls used in VB) controls, I've been experimenting a lot lately with creating visual COM controls, and what I've discovered so far is that it takes very little to create one. If you recall that custom control demo I posted quite a while back (there were buttons on the host which caused the custom control to turn blue, green, or red, and when you clicked on the control it SendMessage()'ed a WM_NOTIFY back to the host), I created a COM object out of that, and to get it to be recognized in both VB or PB9 in terms of a sink object all I implemented was a simple out going interface and IConnectionPointContainer and IConnectionPoint. And I didn't even implement all the methods in those interfaces; only the ones I needed, i.e., Advise, Unadvise, FindConnectionPoint, etc. I didn't do any of the enumerators. I didn't mark it as a 'control' in the typelib, and probably because of that it doesn't show up on the 'Components' tab within Visual Basic where users choose and insert such things, but as I said, it does show up in the COM 'References' tab in Visual Basic, and Visual Basic seems quite happy to dynamically generate a sink for it and accept outgoing method calls on it; likewise PowerBASIC 9.
It seems like I've found a methodology to create these things low level which would be useful to me, i.e., visual COM controls, but I'm not quite sure what to call them besides visual COM controls. I believe ActiveX controls mostly implement piles of additional interfaces that ADD ALL THE BLOAT OF WHICH YOU ARE SPEAKING, i.e.,
IPropertyNotifySink
ISpecifyPropertyPages
IPropertyPage(2)
IOleInPlacrActiveObject
IViewObject(2)
IViewObjectEx
IOleInPlaceObject
IOleInPlaceObjectWindowless
IOleControl
IOleObject
IOleWindow
IDataObject
IQuickActivate
IPersist
IPersistStorage
IPersistStreamInit
IPersistPropertyBag
IProvideClassInfo(2)
and at this point I'm not really sure what to do with all those interfaces, if anything. From what I've gathered/learned so far, most or all of those interfaces pertain not so much to the fundamental working of the control, but to providing a design environment with which such design containers as Word and Visual Basic can provide a visual design experience to the user involving the control. Is my understanding of that anywhere close to the truth?
And what happened to James McNab? ???
Quote
Sounds like you dislike anything having to do with IDispatch, and anything having to do with supporting property sheets and all the rest of the interfaces that go along with ActiveX controls able to be hosted by scripting languages Jose.
So right. I'm not a "drag and drop" programmer.
Quote
I can't say I blame you because I've studied all your code and everything you had to go through when you first figured out how to get those things to work with PowerBASIC 7 back around 2005. Talk about jumping through hoops (an American English colloquialism meaning having to endure tremendous trials and difficulties to accomplish something).
I believe that first you have to learn how to do it the hard way. You have to understand how things work to become a developer and not just a coder or tool user.
Quote
And I didn't even implement all the methods in those interfaces; only the ones I needed, i.e., Advise, Unadvise, FindConnectionPoint, etc.
And using low-level COM you can use any class that inherits from IUnknown as the event sink and call the methods directly using any data type, without having to go through the IDispatch way and all that Variant conversion crap.
Quote
I believe ActiveX controls mostly implement piles of additional interfaces that ADD ALL THE BLOAT OF WHICH YOU ARE SPEAKING, i.e.,
Many of them are to communicate with the OLE container and the others with the visual designer.
The newest ribbon framework has not been implemented as an ActiveX control. It simply renders in the window you provide, without the need for an OLE container. But, of course, M$ had to spoil it with the use of manifests and even a new lenguage (the ribbon markup) and a compiler (the UI Command Compiler) for it to describe the controls and their properties.
Quote
And what happened to James McNab? ???
Posts of the kind This vs That are usually meant to promote flame wars.
Quote
Many of them are to communicate with the OLE container and the others with the visual designer.
I need to study up on that. Its a big area of misunderstanding, or lack of understanding on my part. And I am aware it is something of an important topic that I need to grasp. I'm even afraid to ask any questions about it of you because I feel they would be so dumb due to my lack of understanding. For example, if I want to put an edit control or a listbox on a form/dialog/window I certainly don't need to create another window to be its parent and 'contain' it. When I created that custom control demo of which I spoke above (and the idea for which I got off Chris Boss's custom control tutorial), I just created the custom control on the main program's window through a CreateWindow() call (the class was naturally registered in the Dll through its loading) and I didn't need any 'container' other than of course the main program's main window. So why with all this ActiveX stuff is a 'control container' even needed??? Way back when you first figured out how to use the popular Visual Basic ActiveX Controls MSFlexGrid.ocx and the Calendar control I noted they needed to be created within 'containers'. You provided such simple things as "static" controls to be their containers, and if I recall the hWnd was passed to some AtlCreateControl() type functions. Then later you created your OleCon.bas code to act as containers for these controls. What in the world is going on here if you don't mind telling me or pointing me in the direction of some link that might explain it in a fashion that someone that isn't a genius can understand?
In my various studies I've come across the terms windowed verses windowless controls, and I've read up on them, but unfortunately, I still don't understand something perhaps fundamental that is going on here. I guess I don't understand how a control wouldn't create a window for itself. Oftentimes I think things are more complicated than they really are, and maybe this is one of those. Is this situation so simple that its just a matter of who is going to provide the top level container for the control, that is, the client will create a window and pass its hWnd into the control for it to use, or in the other scenerio, the client will make some kind of COM method call on the object such as Object.CreateControl(25,50,75,100) and pass in client coordinates as to where drawing is to occur on the main program window? I guess in this latter case the control would still need a hWnd from the client to do anything at all on the client window??? I have been musing over this for a couple years actually.
Well, we're all pretty level headed here I think and don't really engage in flame wars, even though we are passionate about what we do.
Frederick, can you post a small example to create a visual activex control? :)
Quote
So why with all this ActiveX stuff is a 'control container' even needed???
Custom controls are designed to be childs of a window. ActiveX controls are designed to be embeddable objects that can also be placed in a web page or a Word document, for example. The container provides services to them and the communication between the container and the controls is done with COM, not via SendMessage.
Windowless controls don't create its own window and, therefore can't process Windows messages, having to delegate this task to the container's window, that after processing the message resends the information to the control. They were dessigned mainly to be used with Internet Explorer, because a web page can have many embedded controls and if each one has its own window there is a waste of resources. When drawing itself, a windowless control asks the container to provide a device context and returns the device context to the container after drawing into it. This improves the performance of the control.
Thanks for the explanation Jose. That does clarify some things for me. The more I learn about this and work with it the more I am beginning to lose interest in the concept of ActiveX controls themselves if by ActiveX control one means something embeddable in something like Word as an 'insertable object', or something with complex property sheets usable in scripting languages. What MORE interests me is creating visual COM components with only direct interfaces and utilizing connection points and sinks as the messaging protacol. I guess this is because I don't really work with internet technologies at all. I'm basically a Windows app programmer.
Quote
Frederick, can you post a small example to create a visual activex control?
I wrote it in C and am converting it to PowerBASIC right now. If you are in a hurry I can email or attach the C code here; otherwise, I'll be posting the PowerBASIC code hopefully within a week or two. Soon as I can get it all working and wrote up.
No hurry, just curious how small you got it..
Maybe not really useful because of the unhandled methods but i would like to see the minimum you reached here :)
PB code is easier.
Like I said I'm not done with it yet, but my best guess is that if you are comparing dll size with the same visual control implemented as a custom control I'd guess it would only be a few percent bigger. Over the long term, after I have some of this stuff figured out well enough that I'm comfortable with it, I'd like to try to build myself a COM based grid control that works more or less like the siGrid control. Or maybe a stripped down version of that. The siGrid control has a pretty lot of features I don't use. Anyway, I'm wondering if I could produce something nice that wouldn't be over 50K. I don't think I could do it with PowerBASIC, but possibly with C++ and some of the unneeded methods stripped out of my String class. I'm a long way from that point yet though.
From what I've seen so far though, if one is content with just having the control respond to events in the typical manner in which either PowerBASIC or Visual Basic recognizes them through their event sink functionality, the code to get that working is fairly minimal. Adding the enumerators complicates things considerably, and at this point I'm not satisfied they are all that worthwhile. I can't really imagine why I'd want an object with multiple outgoing interfaces. But might just be my ignorance at this point. Also, some host environments might not be as forgiving as VB or PB too and might freak out if all the connection point interfaces weren't implemented to their satisfaction.
Quote
IPropertyNotifySink
ISpecifyPropertyPages
IPropertyPage(2)
IOleInPlacrActiveObject
IViewObject(2)
IViewObjectEx
IOleInPlaceObject
IOleInPlaceObjectWindowless
IOleControl
IOleObject
IOleWindow
IDataObject
IQuickActivate
IPersist
IPersistStorage
IPersistStreamInit
IPersistPropertyBag
IProvideClassInfo(2)
The only interfaces of the lot above that I consider as contributing to bloat
and that are related to visual designers would be those listed below. The rest are quite
important depending on the type of control and what it does.
IPropertyNotifySink
ISpecifyPropertyPages
IPropertyPage(2)
IPersistPropertyBag
Quote
For example, if I want to put an edit control or a listbox on a form/dialog/window I certainly
don't need to create another window to be its parent and 'contain' it.
And you can do the same thing with an ActiveX control. For example, if you want to place five
ActiveX controls on a top-level sdk window(aka a form), you can create them directly on the window.
There is no need to place each of them in a container window. The only caveat is that the window hosting
the ActiveX controls must be an OLE container.
This means that Jose OleCon.bas code would have to be modified to use the form as the container and enhanced
to allow for such things as control placement and sizing.
Placing each ActiveX control in its own container window is for convenience. They are easier to work with
in environments where the host window is not an OLE container by default. For example, think of what is needed
in the case of a tabbed dialog. The top-level window and the pages would all have to be OLE containers.
But this convenience comes at a price.
For
IConnectionPointContainer::EnumConnectionPoints
and
IConnectionPoint::EnumConnections
you can return
E_NOTIMPL
And you probably do not want to support more than one outgoing interface not unless
you intend to confuse code generators.
Quote
... but I'm not quite sure what to call them besides visual COM controls.
How about ActiveX controls. All you need is IUnknown as per the ever changing specification. How well your
control works, if at all, in its environment will depend how many of the not too long ago used to be required
interfaces you implement.
If you want your outgoing interface to work in all environments, it should inherit from IDispatch.
Quote
But this convenience comes at a price.
Yes. The price is that it won't work with some ActiveX controls. But my purpose was to write a lightweight container to replace ATL.DLL and I always have warned about its limitations. It works well with a wide variety of controls and, contrarily to ATL.DLL, allows me to use them without havig to register them first. If one day I need to use a control that doesn't work with my container, I will use yours. No need to duplicate efforts.
I love E_NOTIMPL almost as much as S_OK!
I have a large project which contains many Active X COM DLL's some of which are nested. Some of these Active X DLL are written in C++ , which will not be changed and others are written in VB 6.0. I want to port these to PowerBasic. I thought about making them all C++ but that would be too expensive.
Let me give you an example
Active X DLL X has 20 different interface classes exposed
which will be called by other modules and about 25 lower level classes which are used in these exposed interfaces.
In addition this Active X DLL calls 3 dll's written in C++ and 2 of them written in VB 6.0 , I want to port the ones which will give me the most performance increase first.
Can anyone help me with several issues.
Can you explain exactly how you call Active X DLL using early binding from a power basic Active X DLL
How do you orginize a project with multiple exposed classes and many lower level classes
Has anyone ever put together any type of notes on porting from vb 6.0 to power basic.
Quote
Can you explain exactly how you call Active X DLL using early binding from a power basic Active X DLL
If you have PB 9, it's better to use direct interface calls.
1. Generate interface definitions using the PB COM Browser or my TypeLib Browser.
2. Create an instance of the wanted object.
DIM <object variable name> AS <interface name>
<object variable name> = NEWCOM <program identifier>
3. Call methods and/or properties:
<object variable name>.<method name> (<parameters>)
<result> = <object variable name>.<get property name name>
<object variable name>.<set property name name> = <value>
Quote
Has anyone ever put together any type of notes on porting from vb 6.0 to power basic.
I'm afraid not.
1. Generate interface definitions using the PB COM Browser or my TypeLib Browser.
Where is this documented how to make a interface definitions. Is there any step by step guide anywhere ?. This is shrink wrap software I am writting and don't know where end user will install so direct interface might not be best solution.
Also , I am new and don't know how to start a new thread or if we even can , but the Porting from VB 6.0 to PowerBasic would be a good new thread between all the member maybe we can get something together useful.
In the PowerBASIC IDE click the Tools option on the main menu...
Select PowerBASIC COM Browser;
Scroll to find type library for which you want to create interface definitions;
Double Click the library;
Paste the generated definitions into a file and give it a *.inc extension;
Include the file in your project;
Read the PowerBASIC manual.
Additinal info:
If your ActiveX controls are visual interface elements, to the best of my knowledge you'll have to use either Jose's container or Dominic's which I'm thinking you may have gathered from this discussion. Oh. yes, there are two other possibilities for ActiveX support. Edwin Knoppert's visual designer may have that support (not sure). I know Paul Squires's FireFly does. You should be able to easily find those links.
Quote
This is shrink wrap software I am writting and don't know where end user will install so direct interface might not be best solution.
You don't need to know where the user has installed the software to use direct interface calls if the ActiveX is registered. You create an instance of the object with pObj = NEWCOM <PROGID = program identifier>.
Quote from: Chris Boss on September 10, 2010, 10:39:17 PM
The book you want for learning low level COM is:
"Inside OLE"
by Kraig Brockschmidt
Published by Microsoft Press
COM is the wrong term to use when looking for books on it.
COM is based on OLE and OLE is at the core of COM (and DCOM).
This book is suppose to be the best book on the subject from what I have read.
You should be able to find it "used" on the web, since it is not published any more.
Another book I found which may be useful is:
"The COM and COM+ Programming Primer"
by Alan Gordon
Published by Prentice hall
They are big books and I would expect that it would take a good year to dig deep into them to fully understand COM at its lowest levels.
Be sure to compare book prices at http://www.abebooks.com/servlet/SearchResults?sts=t&tn=inside+ole&x=0&y=0 before you buy (can get Inside OLE for $1 plus $3 shipping).
You want to be careful about getting that book as the 1st edition is 16 bit from around 1993 and the next edition about a year or two later for 32 bit.
I've never been able to get any of Kraig's code to run, being as its based on such old and out of date C++ compilers (VC4). Of course, that's based on only several hours of trying. At one point I thought of sinking a major effort in trying to get Kraig's code working, but then I gave up on it. I might return to it at some point though, as his work on COM was very important.
I have the second edition of the book!
Meaning it was edited to deal with 32 bit code.