The Software Developer

Does this sound like a strange thing to say ?

I don’t think so and here is why.  As a long time WIN32 programmer (using PowerBasic) I at times have tried to look into other programming languages used by the mainstream. I purchased an older version of C# just to play with and decided to watch some beginner videos online to see if I can make sense of how to use it. Remember, that I am a coder. When I say coder, I mean coder. I can build complex applications even without the need for a Visual Designer or a Code editor with a ton of wizards and intellisense.  Now I am not against the use of Visual Design tools. A good RAD visual designer makes UI layout quick and easy and is a must for most development, particularly when an app has a lot of forms in it. But for a simple app with say one form and a limited number of controls there is no reason why a programmer shouldn’t be able to code the entire thing by hand without the need for a Visual Designer. I also feel that library code should be as small as possible so one does not have to always resort to some kind of intellisense based code editor just to be able to use the language.

The sad thing is though is that Microsofts current mainstream programming languages (aka. Visual Studio) are less of a coders tool and more of an application builder where the user does more drag and drop and select from lists (intellisense) than actual coding. Just watching a few videos online trying to learn C# is quite daunting. I have to pose the question. If developers spend more time dragging and dropping and selecting namespaces, classes and methods from drop down lists than actually writing code, how good is the code they eventually have to write ? Personally, I feel that the art of coding may be dying. But does it have to be ?

I find that before using a RAD development tool, a programmer should be able to write a workable app without such an environment. One should be able to write an app using just a simple code editor (no intellisense required) and a minimal help document for reference. One should fully understand how the app really works at a low level, but also how the code execution really flows. Where does you app start ? How does the app create a window and populate it with controls ? How do those controls send events to the app ? How do you respond to those events ? How do you make the controls do something ?

The overuse of OOP has turned programming into a complex mass of classes and objects so that programming itself seems to disappear.

Now you might say, but what I suggest is impossible, nobody would be able to build anything in Windows ! Not only is what I suggest possible but I and my customers do this.

When I designed EZGUI (GUI engine for use with PowerBasic), I designed it do one could actually hand code an entire app. I actually have some customers who prefer to hand code the entire app and they do a very good job of it. I did also add a Visual Designer to the mix, but only because a RAD tool like a visual designer really does make sense, but not as the only option, but simply as an addon for those who need faster development. Yet being able to handle code the app helps one learn how things really work. You understand the code flow better too.

There is another advantage to learning how to hand code things. Programmers who are simply glued to a RAD environment will tend to have too great of expectations of the design environment and will more likely be poorer coders. Why ? Because instead first considering how to write some quick code to solve problems, they will tend to expect more from the RAD tool expecting it to do all the work. Nothing surprises me more when an end user requests some new feature for the RAD environment which could easily be done with justa  few lines of hand written code. If a RAD tool has to solve all problems so programmers don’t even want to write just two or three lines of code, then definitelly “coding is dead” and maybe this is part of the problem with programming today.

I am curious too. Those who strongly defend object oriented programming as the only way to code, do they say this because OOP is so proficient when it comes to coding or possibly do they say this because of one of two other reasons. Reason #1, they want the language and libraries to do all the work, so rather than write some code themselves they simply want a new object to be created to solve their problems (aka. don’t want to write any code themselves). Reason #2, maybe the idea of writing everything using classes and objects is more preferable since so much thinking has to go into design of the object first and this means that actually writing code is a much slower process. One can take all day to create that amazing object class, which only does some simple task, where a procedural programmer who is a real coder would have written 50 or 100 lines of code to do the same task in about 30 minutes.

Ok, maybe what I am saying is a bit strong and surely there are many good coders out there. Yet I do wonder about the state of programming today, when a seasoned procedural style programmer like myself finds even the simplist tutorials on a new language just totally confusing.  I really do not see what all the fuss is about with todays managed languages. Visual Studio is not friendly to new users.  Who came up with XAML anyway ? Have we been forced to go back to scripting languages again ? (XAML is a form of scripting and a very complex one at that) ?

Yes. maybe coding is dead !

Coding can be fun ! Coding is powerful ! Coding can actually be fast too !

Coding need not be overly complex either. It is possible to define a library for coding which is small in size, easy to understand and does not require documentation the size of an encyclopedia.

Computer programming is never easy. There are many challenges we face as programmers in trying to develop software quickly and efficiently. So why is EZGUI professional (current version is 5.0) so different than other methods of coding applications ?

EZGUI was designed with the idea of the “language of simplicity” .

What does that mean ? While I strongly believe in the value of a RAD environment, when it really comes down to it, building quality software depends upon coding. No RAD environment can replace good old code. Code is the glue the holds are application together. Why ?

Programmers can easily get into a mindset of viewing software from a technical point of view. Is the RAD environment they use easy to use ? How can I write as little code as possible ? But no matter what we as programmers have in mind as far as making life easier for ourselves, software is a tool used by our end users. It is designed to do tasks. Our end users think in terms of tasks, not in terms of technology. Does the software do the tasks the end user requires ?

I wrote custom software for local businesses for a number of years and one thing I learned was that I needed to think like my customers, rather than a programmer. One way I did this was by being task oriented. I viewed a software project simply as a set of tasks my customer needed to handle. This effected how I wrote code, because I had to break down the end users higher level tasks into smaller user interface tasks so I could build them exactly what they wanted. The ability to build quality reusable libraries which were task oriented, helped me write software faster and better because I could more easily customize it to exactly the way the wanted it.

The EZGUI runtime engine was designed based on this concept of being “task oriented” and “customization oriented”. When I used Visual Basic, I loved how easy it was to design an application. The RAD environment of Visual Basic was hard to beat. Where I had problems was when something I wanted to do was slightly out of the ordinary  and it went beyond the VB “blackbox” of objects. Other VB programmers must have felt a similiar feeling since it was not uncommon to see VB’ers add Windows API code to their applications so they could go beyond the VB “blackbox”.

When developing EZGUI, I didn’t simply just start creating wrappers for the Windows API nor did I concentrate on the Visual Designer thinking the RAD environment would solve all the problems. I concentrated on tasks. Yes, I viewed EZGUI as a “task library”. It didn’t matter if a task was easy to impliment or hard to impliment. I simply asked myself, what if a programmer wanted to do “this or that” and I then proceeded to build a solution which allowed customization if possible, but was easy to use. This is why EZGUI became more than just a library. It became an engine, a GUI engine.

You see, some tasks may be simple enough so that you can write a simple function which does the task and is then finished. But the more I worked on EZGUI, the more I found that some tasks required a running engine which continued to work even after the initial request for the task. Let’s look at one example which well demonstrates this.

One day I was thinking about how does one build applications which are not rectangular windows, but are odded shaped. The first step was to find a way to make a window non-rectangular. This required a complex window region, but how do you generate that region ? Well, the shape of the window would be based on the background image, so it made sense to write a routine which could convert a Bitmap image into a complex window region and then to be able to pass that region to a window (form). But more is required here. Once you have your window region, you need to be able to draw the bitmap you used as the background, which means you have to be able to process a dialogs WM_PAINT routine. Now you needed an engine to handle that or you would have to code two different tasks, one to create the window region and the other to paint the form background. But this is one task, I decided, not two.

So how does EZGUI handle this ? Let’s look at some code:

     PN$=EZ_LoadPicture("mediabg.bmp")
     EZ_ShapeFormToPicture PN$, -1
     EZ_Form "MPLAY", FParent$, "EZGUI Media Player", 0, 0, 67.875, 20.9375, "C"

In the code above, I load a Bitmap and then with one command EZ_ShapeFormToPicture I tell EZGUI to store a bitmap for the next form created, convert it into a window region and when the form is created set the window region and then process the forms WM_PAINT routine and draw that bitmap to the forms background. Yes, two tasks became one.

It was this concept of “tasks” which molds how EZGUI was designed. This is where EZGUI has the advantage. It was designed to solve problems, to handle tasks and to allow customization of many of those tasks. This is why I has to be a GUI engine rather than simply a set of API wrappers. Some tasks are very complex and let’s look at one. If you create applications with a listview or treeview control, one of the more common tasks you may have to deal with is how to add the ability to drag and drop items. At first glance, you may browse the API docs looking for a single window message or function that does this, but there is none. There are a number of API’s which need to be called and you have to subclass the controls to process the mouse movement. Actually it is quite complex.  EZGUI provides a number of commands to support its drag and drop engine for the listview and treeview controls and it is about 600 lines of code. But this is not something which you can just one or two API’s and then it is all done. It is very complex and requires an internal engine to track the drag icon and to do internal message processing. Now where things get complex is if you need to customize the drag and drop. The listview and treeview are two different controls, so how do you build an engine which treats them as equals (one task, but for two different control types). Also what is you want to drag and itme, not within the control to another control or even to another top level window ? Now what happens if you want to customize the drag icon ? Now what happens if the drag icon goes to a position where you need to change how the icon looks (ie. outside of the control) ? What happens if you want to custom draw the icon dynamically ?

Now to make things even more complex, I quickly realized that any drag and drop code for these controls is useless if you don’t impliment an autoscrolling engine. If the dragged item reaches the top or bottom of the control, then you need to automatically make the control scroll to bring more items into view. Can you see how by viewing this as a task, it can get very complex quickly. In this case I had to impliment something which is very complex and hard to do and it required any engine to do this. So how hard is it to code a drag and drop icon in EZGUI ? Check this out for a treeview control:

     SELECT CASE CMsg&
          CASE %EZ_DragItem
               hTree1&=CVal&
               hParent1&=EZ_GetTVParent("DDROP", MyID&, hTree1&)
               IF hParent1&<>0 THEN
                    EZ_StartDrag -1,-1,8,8, "+++AH"
               END IF
          CASE %EZ_DragItemDrop
               hTree2&=CVal&                                  ' Handle to item it was dropped on, so do something

This impliments the complete drag and drop icon task. Now in the %EZ_DragItemDrop event you decied what to do once you know where the item was dropped and add the code for that. But this code impliments the actual drag icon, mouse tracking, icon drawing and autoscrolling.  A complex task made easy. EZGUI even generates Events for you so you know what to start a drag operation and when it is finished.

Another way EZGUI makes coding easier is the way it handles parameters for many commands. EZGUI has autoscaling built in since it uses its own coordinate system. Forms and controls use character coordinates (floating point so accurate down to the pixel) which it can scale. This means all the coordinates of your forms and controls are scalable. Another way EZGUI simplifies things is to avoid the use of API handles as much as possible. It does use API handles for treeview items and menus, but many other UI elements do not use handles at all. For example forms are given names and there is no need to store a forms handle. This makes coding a lot easier. Common resources like colors (brush) and fonts also don’t require a handle. EZGUI builds internal tables and uses indexes for colors and fonts. This allows you to easily reference a color or font without having to use a global variable with a handle in it. EZGUI allows you to free a color or font, but if you don’t it cleans up when your app terminates.

EZGUI also uses simple, easy to remember, property strings rather than API constants (where you OR bits) in many commands. It makes coding easier. For example, the EZ_DefFont command can create a font and does not need any complex bit flags or API constant. For example consider these examples:

EZ_DefFont 9, "Arial", 12, "BVUIQ"

This defines font #9 (an index) to Arial with a size of 12 points and which is Bold (B), Variable Width (V), Underlined (U), Italics (I) and Letter Quality (Q). EZGUI uses this simple single character type of property strings as much as possible. Also by each property character usually being the first letter of the propety name (ie. B for Bold) it makes it easy to remember, so you don’t have to read the help file as often to remember properties.

You see, while you may be able to quickly lay out a user interface in a visual designer, what really matters is making that UI do something useful. This is where EZGUI’s runtime engine makes the difference, both with its internal engines and its easy to use command set. This is the “language of simplicity” ! I find it interesting when I see Powerbasic programmers struggling to accomplish some task (on the PB forums) and then see EZGUI users say something like “that would be so simple with EZGUI !”.

EZGUI is a GUI engine, not a visual designer, but guess what ? It comes with its own visual designer, so you get a RAD tool also. You get the best of both worlds. And even if the EZGUI designer is a little different than what you are used to and maybe you miss your old Visual Basic environment, it’s when you start coding that you realize the power of the tool you have. Unlike Visual Basic where customization was difficult, EZGUI provides so many high level and low level tools for customization that you won’t really miss that old RAD tool of yours. The power of EZGUI is the GUI engine !

EZGUI is the only GUI engine or GUI framework for use with PowerBasic.

While following a discussion on a programming forum today I came across ,once again, one of the common problems when writing pure Windows API code.

What is that, you may ask ?

The Windows API is quite complex and it has a lot of rules. It takes time to become experienced with the API, so many programmers likely browse the web (or their favorite forums) for examples of code which does what they want. Now here is the common error:

Programmers may simply take the code they find and just copy it “as is” into their applications code (or port it to their programming language as closely to the original as possible).

The first rule of writing software one should follow is:

Never use code you find on the internet (or in books) “as is” ! It doesn’t matter if the code is open source or freeware or public domain. Just because you can (legally or morally) use it, does not mean you should use it.

One should always view such code only as an “example” to learn from and not code to be used. Even if the code is found in Windows documentation, don’t use it “as is”. You should simply use such code to learn the “concept” at hand, then examine each of the API’s used and then read the API docs to fully understand those API’s. Then write the code from scratch yourself making sure you fully debug it.

Why is this so important ?

Let me give you a real world example. When I first was learning how to use DIB (Device Independent Bitmaps) sections in Windows, the code I came across in my research had some serious errors in it. I first went to my favorite programming forum and found some working code, but did not realize it had errors in it. The code worked, but it did call some incorrect API’s which was not good. I then browsed the internet and found code (in C) which was not the same programming language that I use and it uses similar code to what I first had found. Since I never use other peoples code, no matter how trustworthy it may appear, I began to start digging into the API’s used. My first find was that the code was treating the return handle (bitmap) of the CreateDIBSection API function as if it were a Global memory handle and the code was calling Global memory API’s to lock the bitmap memory handle. It seemed to make sense at first, but as I started to read the API docs, I never found any mention of Global Memory with DIBsections. The API docs, while at times quite terse, are at least pretty consistant in warning you of any additional API’s required to use a particular feature. To make a long story short, the code I found on the web was wrong. The amazing thing was, all that C code which was in error, found its way into other programming languages code (on the forums I frequent). Some very experienced API programmers were also using that code, which was many years old by now. The point is that the errors in code, were being perpetutated over the years again and again and even in multiple programming languages.

Where this gets interesting is a strange problem some don’t consider. Some errors when writing API code, may be better tolerated by earlier versions of Windows (ie. 95/98,ME/XP).  This means the code with some errors may actually work on some older versions of Windows. The error may not effect the task at hand (meaning the code appears to do what it is suppose to do), but many errors can cause the operating system to become unstable (or the dreaded GPF). Since older versions of Windows may tolerate the errors, programmers don’t realize the code has a problem until it is run on the next version of Windows. A programmer may say “its worked perfectly on Windows XP, but there is something wrong in Windows 7 which causes it to crash the application”. The programmer assumes the problem is with Windows 7, not realizing that the problem is with their code. They simply didn’t realize the code was in error because Windows XP tolerated the error, while Windows 7 like was more picky about the error and it responded more quickly to it ((ie. crashed the app).

The worse part about this is that such programming errors are often perpetuated year after year by “bad code” on the internet or even in books.

So learn the lesson to never use others code “as is”. Always fully understand the code so you can write it from scratch yourself and read the API docs carefully to make sure the code is written correctly. Then you will have code which will be more reliable and likely will work flawlessly on the next version of Windows.