Fifteen years ago, having learned how to write programs using the WIN32 API using the PowerBasic (native 32 bit compiler) programming language, I then built my own GUI engine to make programming easier rather than rely directly on the native WIN32 API in Windows. But the greatest challenge I found was in how to write a Visual Designer. When I first started to learn PowerBasic, the language was a code only language, meaning there was no drag and drop front end to it, but simply a code editor. The community of PowerBasic programmers saw the need for a drag and drop visual designer and efforts were made to write examples of how to do it on the peer to peer forums. Sadly few even knew where to start and the attempts made, quickly demonstrated that it was not an easy thing to do using the WIN32 API. Why was this ?
WIN32 Never Provided An Easy Solution
Simply put, the native WIN32 API never provided an easy solution to accomplish the key tasks in building a drag and drop designer. The first version of Visual Basic was an amazing feat by no means at the time, but looking back it was extremely rudimentary when it came to drag and drop features. Actually it wasn’t that powerful when it came to the drag and drop features, but it was more of a “does the job acceptably” application. Even to this day, the WIN32 API still does not provide the necessary functionality. Higher level GUI engines may provide the functionality, but it appears to have never been designed into the lower level native APIs.
While mainstream programmers may be used to using drag and drop designers, programming language developers often find out that building a WYSIWYG front end for their new language is one of the more difficult challenges. This is quickly seen in the world of BASIC. Yes, BASIC is still alive and even thriving among indie developers. Over the years, I have tried a number of different flavors of BASIC and quite often I found the drag and drop experience to be lacking. The so called Form editor, was often the last consideration in their development. Some have no form editor at all, while some left building it to their end users and the results were often rudimentary at best. Others came with a visual designer but one quickly found them to be wanting. Why?
Not because the developers of such languages were poor programmers. It was because if they wrote their programming languages using the native WIN32 API (i.e., using low level C), they likely found out quickly that the native APIs for even the simplest things needed were missing. Yes, the basic APIs to build it are there, but nothing of a high level nature were there. Likely few books or tutorials on how to use the low level APIs to accomplish this can even be found and I won’t attempt to try to write a tutorial about it here either.
Quickly on the PowerBasic user forums, programmers found it very challenging. Writing even the core features of a visual designer were more complex than simply knowing how to do “rubber banding” or the like. If you would like to see some code examples produced by those efforts, here are some code examples you can download from the PowerBasic web site:
Even in my own experience, I had a lot to learn and it was not until after 10 years I finally came close to having mastered some of the basics. You can download some actual running applications I wrote below (sorry, no source code included) which are freeware designers I created for PowerBasic users (very limited compared to some of my commercial tools, but they demonstrate the progressive steps I had to make).
The above designer didn’t even do basic rubberbanding (ie. of code for rubberbanding can be found here). I have seen a number of indie programming languages which do basically the same thing. Rubberbanding is one of the first things to learn.
In this next generation, you can see I learned how to do basic rubberbanding, but I also learned how to create real drag handles around the controls. This was not simply done by drawing them, which I think is a mistake. I actually created a unique window class for a drag handle control, which implemented the basic drag and drop features. Yet, I still had not mastered multiple dragging for multiple controls at one time. I also have a snap to grid which can be displayed or hidden. I did not yet have the knowledge of how to create my own property listbox control, which came later.
Even in this fourth generation designer, I had not mastered dragging multiple controls at one time. Doing multiple control drag and drop is tricky, because the way most developers do drag rectangles is by drawing one at a time directly into a window DC. Dragging a few controls at one time may not be a problem, but dragging many at one time is problematic. To see this in action, try the following test on a variety of form editors:
Create a form with at least 3 or 4 hundred controls. Now select them all and then try to drag them all together. Poorly designed designers will make a mess of this and you likely will see lag time between each drag rectangle.
I did not master this until the fifth generation of my commercial tools. In the following video, you can see that I finally figured out how do to multiple control dragging (cleanly with no flicker) and I use property listboxes, have a visual boommark feature and more.
Lessons Learned
There is more than meets the eye when it comes to building a visual designer and it takes a lot more than just learning how to do rubberbanding and how to drag or resize controls. Let me give an example. Some who build visual designers use placeholders for each control. I chose to use the actual controls because it gives a more realistic look for the forms. One reason some opt for placeholders is that using real controls come with some problems. A good example is the combobox control. You can’t simply resize it, since the size you want is for both the control and its drop down list. Your rubberbanding must represent the control with its dropdown listbox. Another problem is that real controls are not always mouse friendly for design mode and you end up with strange results like selecting text or an item when you simply are trying to drag a control. So place holders often seem a better solution. I found that I could use real controls, simply by subclassing the controls and then processing the WM_NCHITTEST window message and then fool Windows into how it treats the mouse. But then I had a problem when a control class creates its own child windows. A combox control for example may have a child children of its own (edit control) and the subclassing did not take it into consideration. I then had to add a drill down routine which would then subclass all child controls of the parent control and then process window messages in them. This was very important when I wrote a designer which supported third party custom controls like grid controls, which could have many child controls.
Simply put, there are no easy solutions when writing a visual designer. After one problem is solved, you may find another problem shows up. The key though is to understand how Windows handles low level window messages and how to properly deal with them. While Windows does not offer high level solutions for this in the WIN32, its many low level customizations allow programmers many options and likely each visual designer developer uses different techniques to solve the same problem.
