You are a SDK programmer, aren't you?
To answer,
Yes and No!
Would I write an application simply using the Windows API ?
Absolutely not!
That would take too much time and is too low level. I prefer as "high level" of an programming environment as possible.
Yet, part of the answer is Yes.
The core EZGUI runtimes are 100% pure API code and couldn't be written any other way.
So yes, I am an SDK style programmer.
The EZGUI Visual Designer (and version 5.0 will be far superior to the 4.0 one) is not only not an SDK application, but it is a 100%
EZGUI application (written only using core PB commands (no DDT) plus EZGUI runtime calls). Not a single Windows API is called in
the Visual Designer, not one. All of the calls are made to the EZGUI runtime and only the runtime calls the API.
I am a firm believer in using "high level" tools for programming. I did a lot of custom programming for local companies years ago, so
I appreciate the need to be able to develop applications as fast as possible. The old saying "time is money" really applies to software
development.
The need for high level tools is one of the primary goals of the next version of EZGUI. I have exhausted much of what I need to do with the Windows API
when it comes to normal controls (standard and common). The majority what one may need for writing a windows application is already in EZGUI 4.0
and most of my customers only use a small portion of its command set. The next generation instead is built upon the concept of "Code Reusability", rather
than just more API stuff.
What I mean is that, EZGUI already provides so many "low level mechanism" for handling API tasks (ie. ownerdraw, custom draw, subclassing, drawing directly on controls
backgrounds, etc.) that in the right hands one could do amazing things with it. The problem I have found though is that while the low level features are there, the average
programmer finds it too time consuming to work at that low level. If they do work at a low level, they want to be able to "code once" and reuse over and over again.
So the mechanisms I have added to the next version of EZGUI deal more with component design, code reusability, "high level functionality" (like the new auto sizing engine for controls)
, plus a few new more current features like OpenGL.
In that sense, I want to steer users further away from the API and let them just use (or build) components which they can just plug into their applications with minimal amount of code. Those who are experienced API programmers though can still use all the low level stuff and likely will build their own components.
Because of my slightly different approach to programming (albeit different than most), I can appreciate the views of both "camps", those who prefer the SDK style of programming
and those who prefer DDT (a slightly more high level approach). When I see people comment about DDT as a "black box", I have to laugh. If DDT is a "black box", then EZGUI is a "black universe". The point is that it doesn't matter. In the end, what matters is making PB'ers productive in whatever their fields are, so they can develop software as quick as possible, which works and works reliably. The end user doesn't care whether the app was written using the pure API, DDT, EZGUI and PB. The end user doesn't care whether the app
is a single EXE, uses multiple DLL's, etc. All they care about is whether the software can easily be installed and serves the purpose for what it was designed for.
I do subsribe to the "keep it as small as possible and as fast as possible" tradition found in Powerbasic itself. Thats why I wrote EZGUI 4.0 (and 5.0) in PB 6.1, rather than 9.0, since I count bytes too! But in the end, because it was all written using some powerbasic compiler (EZGUI in 6.1, my customers EZGUI apps likely in PB 9.0), the entire application will still be
extremely small in comparison to what the latest generation of dot.net compilers are putting out.
