The power of Basic and the WIN32 API’s !
It is so easy for a programmer to want the programming language to do all the work for them, but for myself I just want a core compiler which allows me to build what I want, the way I want it. I have noticed that my style of coding doesn’t actually use many of the more current features of the PowerBasic compiler. What is most important to me is the ability to access the Windows API (WIN32) and the core Basic command set necessary for most logic and low level coding. Few may realize that I have been programming using PowerBasic since version 5.0 (current version is 10), when it was still called PBDLL rather than PBWIN. My latest software, EZGUI 5.0, was written using PowerBasic 9.0, but it almost was written using a much older version which was 6.1. I actually started coding EZGUI 5.0 using the 6.1 compiler, but I maxed out the compiler (meaning it could not handle the size of the source code I had), so I was forced to move to a newer compiler. I decided on jumping straight to the 9.0 version, since I would have the benefit of a few new features which would compensate for the larger embeded runtime code of the compiler. Each new version of the PowerBasic compiler has added a few kilobytes to its embeded runtime code. I was trying to keep the EZGUI runtime DLL’s as small as possible so this mattered a lot to me.
The point of this discussion is that even a much older version of PowerBasic had the majority of features I required. While some PowerBasic users are always looking to the next version of the compiler to solve their problems, I have been learning how to maximize the use of the core parts of the language which have been there for years. PowerBasic has been so rich of a language for so long that there aren’t many new features that turn out to be a “must have” for me. I upgrade to the new versions only to be current, but I can live with a much older version of the compiler.
The real power of Powerbasic is its core language and the ability to access the Windows API. Things like the OLE string engine (for variable length strings), memory management built in (no need to allocate and deallocate memory), rich logic command set (ie. IF THEN, DO LOOP, FOR NEXT), rich string command set and plenty of low level stuff (ie. pointers) and I am happy.
The real challenge when using PowerBasic has been the GUI (graphic user interface) stuff. That is why I created EZGUI. By tapping into the power of the Windows API and building a reusable library which simplifies coding (aka. RAD), I have the best of both worlds. EZGUI taps into features of Windows that most PowerBasic programmers aren’t even using right now. One good example is the ownerdraw engine in EZGUI. The ability to be able to customize the look of existing controls is so very useful.
The problem with programming today is that it is too “plug and play”. Programmers want the programming language to do all the work. True, building reusable code makes sense, but I have always felt that reusable code is something the programmer does for himself according to his own needs. For me, I wrote my own GUI library so I didn’t have to “reinvent the wheel” as they say. Even with a high level library like EZGUI, I also made it quite low level too, since I felt that it would not make sense for me to try to build everything a customer would want, but instead provide the tools for them to build what ever they required. There is no way to build a library which does everything. At best it can be a stepping stone which gets you closer to what you want.
At first glance, programming languages which allow you to quickly drag and drop components seem so productive. That was the allure of Visual Basic. It was a great tool for designing a user interface, but at some point you have to start writing some real code to get some work done and that is where problems may occur. Experienced Visual Basic programmers often found themselves having to tap into the Windows API to solve many a problem. The real power was the ability to go beyond what was considered standard user interface design to create something totally new.
This is why even with an addon tool like my own EZGUI, it does not limit the programmers ability to customize and to go beyond what the library may provide. Even though EZGUI is a GUI framework of sorts, it was designed so you can easily integrate pure WIN32 API’s into it. I actually want customers to go beyond EZGUI it they have to, to solve a problem. EZGUI is just a stepping stone getting you closer to the power of the Windows API. Yet, I also designed EZGUI so it has plenty of its own low level features, so you can do an amazing amount of customizing without having to resort to the Windows API. The rule is, “try to do it with EZGUI first, but if you can’t then there is always the Windows API”. This has worked well for my customers.
The BASIC language makes the code more readable (more natural) as well. Modular design is easy using simple, standard subroutines and functions. While PowerBasic can do some degree of OOP and classes, I don’t require it. I find OOP only gets in the way of clean simple code. The idea that everything needs to be in a class is just wrong in my opinion. Purely procedural code produces faster and smaller applications and is easier to debug.
I am sure some who read this blog may object and think “what can you do with a simple language like Basic ?”. Yet I have been very pleased with what I have been able to accomplish with EZGUI 5.0 Professional. The feature continues to get more and more advanced. One of my favorites has been the new OpenGL based glCanvas control, which makes 3D so easy to do. Yes, PowerBasic has done me well. As Bob Zale put it, one can “compile without compromise”. !