The Software Developer

Let me start with why I designed EZGUI the way I did. No matter what anyone says, writing Windows applications is not easy. For those who are engulfed in writing software using mainstream development tools (aka. Visual Studio) everything revolves around the development environment. From intellisense to drag and drop design, the idea appears to be “make things easier for the programmer”. I agree with the sentiment, but disagree with the method.

For programmers like myself who are engulfed into the world of the WIN32 API’s, programming can be just as complex. The Windows API is by no means simple. I recently downloaded two of the better Visual Designers (demos) created by the PowerBasic community and I have seriously considered how they differ from the approach I have taken with EZGUI. One designer attempts to emulate classic Visual Basic in many ways,  while the other appears to be taking some cues from Visual Studio, with a design environment similar to Microsofts Blend designer. I was impressed with the designer which emulates Blend, but at times I found it bit overwhelming, which is the same experience I have felt using Blend with XAML. I have a good bit of experience with graphic designers for 2D and 3D drawing and for me, I just don’t view visual design of a graphic user interface to be the same thing and I prefer the more old fashioned classic Visual Basic style of laying out of forms. So in this case something more akin to Visual Basic is likely more user friendly.

Now as far as working with code, the two worlds I have to compare are the WIN32 world of PowerBasic developers and the Object Oriented World of Visual Studio. I don’t think WIN32 is easy, but compared to all the OOP stuff in Visual Basic (dot.net) and the huge dot.net framework, even the complex WIN32 is easier in my opinion. If you want some of my feelings about OOP read some of my other blog posts (  ie.   http://cwsof.com/blog/?p=612  )

So back to PowerBasic and the WIN32

The Visual Designers for PowerBasic which have been developed, do a great job of building a powerful front end. One weakness, in my opinion,  though is their dependency upon the Windows API and WIN32 coding. As applications get larger and larger with more complex user interfaces, I find that the WIN32 API’s are like a dangerous iceburg just waiting underneath the water ready to sink the ship. When working with the Windows API, I don’t want any surprises. This means that I personally am more inclined to want to build reusable library code and use it, rather than keep writing (or generating) more WIN32 API code. EZGUI was not originally designed to be a commercial product. It was designed as an inhouse library so I could keep myself as far away from the Windows API as possible. To me this was a more reliable method of coding.

If there is one thing I put far above “ease of use” in my software, it is reliability. I like to use the term “solid as a rock” when I describe my goals for EZGUI. No matter how fancy the user interface or the tools we use to build them, software has to be reliable. This is one of the reasons I don’t like the WIN32 API’s because of the huge set of include (header) files required. One slight change in a new version of the headers and you can break a lot of code. This is why when I created EZGUI using PowerBasic, when I got started using PowerBasic 6.0 I determined to keep the original header files (includes) from that compiler as my core headers. Then as I needed anything which may be missing, I modified my own include files, rather than use the new versions provided with the compiler. I didn’t want any surprises. Also I also determines to write all my own code for the library. No copying others code (even open source or freeware) to save time either. I had to fully understand all the stuff I was doing with the Windows API, before I added new code to EZGUI’s runtime. The library had to be rock solid, “no surprises”.

The Windows API is also not intuitive, in my opinion. Tasks which should have been easy, often are complex or tedious. Why couldn’t the API’s be simpler and easier to use ?

To be honest, I find it confusing that most of the third party developers of Visual Designers for PowerBasic, have preferred to generate SDK (pure WIN32 code, much like old fashioned C) style code, rather than to take advantage of the GUI command set built into the compiler (called DDT or Dynamic Dialog Tools) which does a decent job of simplifying the Windows API and it produces more reliable code in my opinion (it may be simple, but it just works). There needs to be a balance between access to the power of the Windows API and ease of use and reliability. DDT does some nice tricks to make coding easier to read and reliable.

I have considered building a full Visual Designer for use with DDT, but I really don’t want to compete directly with the PowerBasic PB Forms designer. I have a utility designer I sell for generating DDT code, but that is as far as I currently plan to go with DDT. DDT does its job well and PB Forms supports a good portion of the PowerBasic users. For me, I chose a totally different route.

A GUI Framework

I don’t find working with the Windows API, directly, reliable, so building a Visual Designer which concentrates more on the drag and drop experience which generates pure WIN32 code is out of the question. PowerBasics DDT GUI command set is quite usable for many smaller to medium sized applications which have a minimal user interface, so there is little reason for me try to out do PowerBasics own PB Forms designer for those users.

My own needs and goals are far more extensive than that. I wanted to be able to build as large an application as I wanted, with as complex a user interface as possible. One goal was that I didn’t want to be dependent upon a bunch of third party custom controls (like classic Visual Basic programmers). I wanted everything to be possible with just one system. It had to be easy to use, powerful, extensible, reliable and have as small a footprint as possible. While a drag and drop design environment was vital, the designer experience would not be the key to the product. The real power would be in the GUI engine or framework. The framework would be so easy to work with that one could even write applications without the benefit of a Visual Designer if need be (and a number of my customers actually prefer to write apps that way). How many programmers today can write a complex Windows application using just a simple code editor, a single source code file for most of the source code and be able to design the user interface only with code ?

With this idea, EZGUI was born. The Visual Studio world has its framework, dot.net, so why shouldn’t the PowerBasic community have its own GUI framework ? Well, it does and it is called EZGUI (for Easy GUI). But there is one problem ! The Windows API is a complex and large set of API’s. How can you keep a GUI framework small and tight, while tapping into as many features as possible ? I decided on the old 80/20 rule (or close to that ratio). The principle goes like this. That 80 percent of users only use about 20 percent of the features available. I found this true with using the Windows API. So in my mind, the goal was to try to tap into that smaller 20 percent of the Windows API, so it would provide mostly what is needed for 80 percent or more of what a developer needs, to be able to build a complex user interface.

There was a key though which was important. What if a developer needed something not found in that 20 percent ? This is why making the GUI framework extensible was vital. I designed it so it was easy to integrate pure WIN32 code when it was necessary to solve a problem. This is exactly what my customers have done. I encourage them to use only the framework if possible, but in the few instances where something they needed was missing, I explain to them how to extend the GUI framework using the WIN32 API. I even show them how to avoid having to use any of the WIN32 header (include) files when they do this. EZGUI has its own header file which basically has the entire command set declared in it. Most applications can be written without the need for a single Windows API header file. This was by design. EZGUI applications compile very fast because they are not dependent upon a huge number of API headers. The primary EZGUI header file is only 92 KB in size. That is tiny compared to the typical WIN32 application requirements. Previous versions of PowerBasic put the majority of API include (header) code in a single file about 1 megabyte in size. The current version (10.0) uses multiple header files more similarly layed out like Microsofts C headers and it amounts to more than 1 megabyte in size and spans multiple files. EZGUI has its entire command set declares in just three include files which total about 97 Kilobytes in size (primary one is 92 KB and the other two are very small). That is one tenth the size of the include files needed using any other methods of coding using PowerBasic. Compile time is significantly faster and less prone to error.

Compile times for EZGUI applications are very fast, because there is minimal code to compile. Another factor contributes to faster compile times. That is the unique GUI command set in EZGUI. Unlike the WIN32 API’s many tasks only require a single line of code and the syntax of most EZGUI commands have been designed for minimal characters to be typed into the code editor. For example, the code necessary to create a Toolbar control, with all the buttons defined using one of the built in system Bitmaps would look like this:

EZ_Toolbar 50, “#LargeSTD”, “BBBBBBBBB|{New File |Open|Save|Close|Cut|Copy|Paste|Print|Redo}”, “ALONF24X24{1}VT”

By defining certain aspects of the toolbar using simple macro property strings, the amount of code is minimal. The GUI engine handles interpreting the property strings into meaningful API calls internally. The above code defines a toolbar using the large standard bitmap system images, with nine buttons, each with a text string in them and defaults to using the images (indexes) in sequential order for the image icons. This command can even define image indexes which are not sequential, using a single character per button. The images are 24 x 24 pixels and the last string parameter defines all the properties of this control.

Better than XAML, the GUI command set allows you to manually define a user interface but using a syntax which requires minimal code, but is still dynamic since these are actual sub/function calls into the GUI framework. The parameters could be passed variables instead.

Now new EZGUI users actually find there is a difficult learning curve at first. Not because EZGUI was not designed to be easy to use, but because it is so different than what they may have been used to. Once they understand the common syntax of the command set and how things work, often the learning cycle speeds up significantly.

The secret to a GUI framework

One of the secrets to the EZGUI framework is something so simple and obvious, programmers often fail to appreciate its importance. As programmers we get so used to “plug and play” we may find ourselves not wanting to write much code. It is so much easier to just pop in that third party custom control (typically OCX with Visual Studio) rather than create something ourselves. Maybe we want the Visual Designer to do all the work and simply add a little code here and there in some event routines. But you may say, “I don’t have time to write a custom control from scratch” and I would agree with you. But there are problems in being too dependent upon a number of third party controls. Every new third part component added to a project, adds the possibility of some incompatibility between components. Second, most component models today are based on COM (ie. OCX) so the components may need to be registered with the operating system, which prevents apps from being truly portable. The size of the applications also tends to increase significantly. So what I decided for EZGUI was this. First if a third party custom control must be used, I would encourage users to opt for those in DLL form which don’t need any special kind of system registration. This would make them portable, so you can just copy and run. EZGUI’s own framework is built of just DLL’s and they are all portable. Just copy them into the same folder as the application and they will work.

Second, why not design the GUI framework itself to have an extensive set of customization features built in, so you could simply create new controls by using existing ones and simply use some sort of customization feature. Actually, this was a perfect thing to impliment, since the WIN32 API’s already had this built in (albeit not that easy to do), so I could tap into these features in the Windows API, make them easier to use so developers would have almost limitless choices for customization. I chose to impliment both OwnerDraw and CustomDraw for controls which supported them. I provided the mechanisms to use these methods of customization, such as a graphic drawing engine.

The key to EZGUI’s nearly limitless potential is customization. Add to this, access to many low level features in Windows, but made easier, such as subclassing, superclassing, using worker threads and syncronization (critical sections). There are three different Graphic engines, one for the Canvas control, one for the printer and the other for low level drawning into any Windows DC (this is used for ownerdraw).

Filling in the gaps

The interesting thing about the Windows API is that while there is a great deal of power in it, often it is either not easy to accomplish certain tasks or there is no medium or high level ways to accomplish some tasks, which really should have been in the operating system from the beginning.

With EZGUI, I chose to fill in some of those gaps. First, tasks which were a bit difficult using the Windows API’s, I found ways to simplify them or even automate them. For example, there are two sets of ownerdraw commands in EZGUI. Once is more low level, but still much easier than using the Windows API alone. There is also a “simplified” version of the ownerdraw command set, which with just one line of code allows you to draw using a variety of ownerdraw features. For example, I impliment a simplified ownerdraw command set for 2D and 3D colored button controls. Customization need not always be overly complicated.

But the customization features alone were not enough. There were many things missing in the Windows API or at least no medium or high level ways to accomplish some tasks. These I had to build myself. I took on this challenge in a variety of ways. First, I created new controls which simply didn’t exist in Windows. True some of these may exist in the dot.net world, but that is because they are using a large GUI framework, instead of the Windows (WIN32) API. Somebody had to create these new controls, because they didn’t exist before.

I started with easier control concepts, but progressively added more and more to handle a variety of common tasks. Again the the 80/20 rule applied. I wanted new controls which were more generic in their use, but would cover a larger variety of common tasks. I created an MCI control, because multimedia is important. I created my own Canvas control because it was the most useful graphic oriented control to create. I wrote my own Files Listbox and Property Listbox controls.

More was needed though

The downside to the 80/20 rule is that programmers could easily get into a rut using only the more popular and simpler controls. There was a need to actually break the 80/20 rule and find ways to encourage programmers to push the envelope when it comes to user interfaces. One of the downsides of the new Metro interface in Windows 8 is that it tends to encourage conformity, when at times there is a need for something new and fresh which better handles the task. It is not a matter of simply breaking the rules just for the sake of breaking the rules. At times something better may really be needed. To illustrate, most birds fly since that is the norm for birds, but penguins don’t. Why not ? Because they serve a different purpose. They are birds, but they swim in the water like other birds fly in the air. They are a beautiful bird in their own right, but they are different and in their case different works, because they have a different purpose. So too with designing user interfaces. Doing something different just because it is different does not make sense. But what happens when there is a better design, by doing it differently ? Maybe the different task or purpose requires something different, something better.

While in versions 1.0 to 3.0 of EZGUI, I concentrated on the 80/20 rule, with EZGUI versions 4.0 and 5.0 it was time to break the mold. It was time to provide the tools so developers could push the envelope a bit. At a time when the devices we run Windows on are changing more and more, there is a need for more choices in software, not less.

While previous versions of EZGUI contained a built in drag and drop command set, it was time to push it beyond the basics. I needed the drag and drop for building my visual designer, but my customers also benefit from using it too to build WYSIWYG style applications. I improved the drag engine so it could drag multiple objects (controls) at one time, with speed and minimal flicker. Try selecting a couple hundred controls in your favorite designer and drag them all around together and see how difficult a task that is. This is a very useful feature for building enterprise and commercial applications which need the ability to do real drag and drop.

More and more PC users are using multiple monitor setups, so it was important to add that functionality. Because of the different device sizes which applications may have to run on, I added a new AutoSize engine for automatically resizing controls when a Form changes size. This autosize engine is very sophisticated, even with some unique customization features to handle many of those situations where a simple rules based system won’t handle it. I added a number of features to improve the graphics engine. Starting with EZGUI 4.0 I added a 2D sprite engine. Sprites have been around since the days of the Commodore 64 and Atari home computers, so why didn’t Windows have them ? I built my own sprite engine and embeded it into my Canvas control. Sprites can do more than just games, but have many business applications as well. EZGUI does this also without the need for DirectX too.

In EZGUI 5.0 I added a new superclassing engine, which I used to build the latest new control which is the glCanvas control, a hybrid control based on my Canvas control but which adds a 3D scripting language on top to display OpenGL based 3D objects. Now 3D is easier than ever. No need to learn the OpenGL API, the control handles it all via its extensive 3D scripting language.

The point is that, a GUI framework like EZGUI pushes the limit of software development, but it has one more significant benefit.

Windows 8, the desktop and tablets

With Windows 8, all the emphasis is on the Metro (or Windows Store) side of Windows. But the desktop is not only still alive, it can be more powerful than ever. The challenge of building Windows 8 desktop applications, which are not only fast and fluid, but are also emersive and exciting is being able to break out of the mold and being able to design something totally different and something dynamic as well. EZGUI was designed for this challenge (and more will be added in a future version). First, the entire EZGUI framework is only about 1 megabyte in size. The core runtime engine DLL is only 700 KB. Because EZGUI uses only DLL’s in its framework it is portable and you can create applications where you simply copy and run. Because the size of framework is so small and the executables which use the framework are significantly smaller too, you can build applications with an amazingly small footprint. This makes a difference when drive space may be a premium on a tablet. Applications can even be run using SkyDrive. Just copy and run, no installation needed. How about installing them on a jump drive and run anywhere ?

One problem many face is how do you support older legacy computers, while still support Windows 8 ? Applications built using EZGUI will also run on a variety of versions of Windows. Because the GUI framework was designed to be as universal as possible, it will run on Windows XP to Windows 8, dynamically changing itself when possible for the latest versions of Windows. Actually EZGUI applications can run even on Windows 95/98/ME and 2000 also (some features only available on 98 or later and some only on XP and later). System requirements for applications are minimal, so you can write software which will run on more Windows devices, even with as little memory as 256 megabytes or less. How many XP computers are still being used, even in the Enterprise, which only have 256 meg ram ? EZGUI applications can handle it.

At a time when software needs to be more dynamic and be able to run on a greater variety of devices (x86 only though), EZGUI 5.0 provides an amazingly large feature set but with a minimal footprint. All of this is only possible with a GUI framework. This is why I chose to build a framework, rather than simply a Visual Designer front end. But don’t worry. EZGUI comes with its own drag and drop Visual Designer, designed specifically for this unique framework. So whether you are designing for Windows XP, Vista, Windows 7 or Windows 8, EZGUI provides a framework up to the task. EZGUI keeps the desktop alive in Windows 8 and makes writing small footprint applications for tablets much easier.

Having been writing software since the days of CPM (and before) I can appreciate how far computers have come. If anyone thinks an Atom CPU is slow, try writing software for the Commodore 64 with a CPU which was only 1 mhz in speed. Yet despite all the changes in computers over the years, to me it is still just a matter of working with bits and bytes. Ascii text are just bytes. Numbers are just bytes. Graphics is simply moving a lot of bytes around really fast. I know, that sounds a bit over simplistic, but it leads to a point.

In the old days, operating systems were simply a set of API’s which encapsulated basic functionality one could build upon. They provided access to the hardware (ie. keyboard, mouse, screen). They provided basic user interface elements (anyone remember Geos for the Commodore 64). They were the building blocks of which software was based. Even Windows from the days of 16 bit Windows was simply a set of API’s which you could build upon.

Something changed though over the years. Object oriented programming took over and it wasn’t enough to just use it to build higher level abtractions on top of the operating system, but it began to take the place of simple API’s in the core of operating systems.  I believe that object oriented programming may be at the core of what makes operating systems and software too complex so that each new generation requires more and more powerful hardware just to keep up.

While I appreciate the goals of OOP, such as code reuse, I am not so sure that it really accomplishes what it was intended to solve. What can make software and even an operating system powerful is simplicity, not complexity. Just for a moment consider the inherent complexity of OOP. Just ask someone to explain the meaning of common terms of OOP and you quickly find that was is suppose to be simple is actually an overly complex concept. For example was is abstration ?

Just do a Google search to find the answer and rather than a clear cut answer one finds that there really isn’t a clear definition. Here is one discussion where someone asks this question and just take a look at the variety of answers he gets:

http://programmers.stackexchange.com/questions/16070/what-is-abstraction

Now, define something like subroutine or function. Not too difficult is it. Subroutines and functions are the simplist constructs of reusable code. Early API’s where simply a set of prewritten subroutines or functions of which software could build upon.  Need a font ? Call a simple operating system API like CreateFont and you get an index (or handle) to an available font. What could be simpler ?

Now some may feel the objects are the necessary higher level contructs of which modern software must be built upon, but is this true ? I don’t think so. Why do I say that ? Because as a developer of tools for programmers, my job is to design higher level constructs to make programming easier for other programmers and after spending ten years building a GUI engine (in its fifth generation now) I have come to the conclusion that one can build high level GUI libraries without object oriented programming and guess what happens when you do ? You get smaller, less resource hungry software.

Yes, with so much emphasis today on mobile platforms, we need smaller, less resource hungry software. So how can one provide the higher level functionality that programmers require, without using object oriented programming ?

The three tiered building block approach.

Have you ever played with Lego blocks ? The amazing thing about Legos is that with a good assortment of different blocks one can build an almost unlimited variety of models. The blocks come in different degrees of complexity from just rectangular blocks to wheels, windows, etc. Most blocks are totally reusable too.

Building software, even an operating system, can be done in a similar fashion. The difference with software though is that the less complex building blocks can be used to build the more complex blocks for the ultimate in code reusability. I will refer to this as a “three tiered” design. What is that ?

Basically the three teirs are:

• low level functions (or subroutines)
• medium level functions (or subroutines)
• high level functions (or subroutines)

All operating systems must have some low level functionality to build upon and one can build an API to provide the lowest level of functionality available to all software that runs on it. Some may feel that one must build this functionality upon objects, but it need not be so. True, data types which the core operating system (even higher level apps too) will use to track tasks may need some structure, but simple types or structures which most programming languages provide is sufficient for this. The core set of API’s can be very low level. Low level functions should be of a single task nature, for example, create me a font or a drawing brush.

The next step is to build the medium level API’s, which are built upon the low level API’s. Medium level API’s will combine multiple tasks together to provide more complex user interface features. For example in Windows, if I wanted to prepare a drawing surface (a memory DC with a bitmap selected into it) it requires multiple steps (create a DC, create a bitmap, select a bitmap into the DC). Yet, the Windows API doesn’t provide this functionality in a simple API. It should have though (and that is the kind of thing I write into my GUI libraries).  It is this medium design which may be lacking in operating systems. By building even more complex user interface features into this medium level, it provides programmers with even more choices and makes software development faster.

Lastly, with an extensive medium level set of API’s (which build upon the low level), now we can start building the higher level API’s. High level API’s should provide functionality which would have taken hundreds of lines of low level or dozens of lines of medium level code. The more extensive the low level and medium level API’s are, the more high level API’s can be created.

By using a procedural based approach using such a three tiered system, I strongly believe that operating systems could be designed to be simpler, faster and smaller, which is exactly what we need today for our mobile platforms.

Does this approach work ?

Yes it does. While I don’t develop operating systems, I do develop GUI engines that sit on top of the operating system. To me, the WIN32 API’s are the low level functions I build upon and my job is to build the medium level and high level constructs on top. By using this three tiered approach with purely procedural style coding (API’s upon API’s) and avoiding the use of objects I find I can software with an amazingly small footprint which requires minimal hardware resources. I design software with the mindset of “write it so it can fit on a floppy disk”. Ok, we don’t use floppies anymore, but you can get the picture. Small is beautiful and efficient !

There are a number of open source operating systems in development and likely more coming. But has anyone ever considered this more simplistic approach ? If they did, I would not be surprised to someday see small tablets which are super thin and with multiple days of battery life, but are full blown computers rather than simply an ebook. The three tiered approach lends itself to the “smaller, faster” goal which Bob Zale (creator of TurboBasic and PowerBasic) always encouraged.  Maybe those old timers knew something which todays programmers haven’t learned yet. While I am not saying that OOP should never be used, the above three tier approach could lead to faster, smaller operating systems and software.

Many are likely wondering about the next generation of my flagship product EZGUI. Such questions as “when will it be released”, “what new features will it have”, etc. are on some peoples mind.

First, let me say that my goal is to release EZGUI 5.0 some time within the first quarter of 2011, more likely the latter part of it.

EZGUI 5.0 is already in use by some customers via the PreRelease program right now and the reports are good. So what is a PreRelease program ? Rather than have a beta testing program, where users can only “play” with a product, instead of actually use it in real world development, the Computer Workshop provides a small subset of its customers the opportunity to purchase an upgrade to the new version in PreRelease form. They get the next version now, can distribute apps they write with it now and then when the official release version is ready they get a copy of that as well. The PreRelease version is version 4.5 and the official release version will be 5.0.

So how does this work and aren’t users worried about bugs ?

First of all, I don’t use customers for debugging my software. Any who have participated in the PreRelease program before will likely comment about how stable all PreRelease versions are. I do extensive testing inhouse and only want PreRelease users to have access to new features, rather than be debuggers. Sure, they may catch a bug I may miss, but that is not the intent of the PreRelease program. The PreRelease cycle is where many new features are added. I do use this development cycle for getting feedback from customers on what new features they require, since you really can’t appreciate your needs unless you are writing real software.  A lot has been developed during the PreRelease cycle.

So what is new ?

One of my favorite features is the new superclassing engine. EZGUI 5.0 will allow you to build new control classes based on existing controls. The new class will inherit all the features of the base class, including automatic recognition by EZGUI commands of the new class. You see, EZGUI commands usually test the window class name to make sure you are using them with the correct control type, so the new superclassed controls will be recognized as if they were the base class. Now superclassing is not too difficult using the Windows API, but EZGUI 5.0 goes much further. It provides a support command set just for building superclassed controls. For example, you can add instance based data storage, both Longs and Strings using new commands.

The first real test of the new superclass engine, was for me to build a new class myself. I chose to build the new GLCanvas control using the new Superclass engine. The GLCanvas control is an OpenGL based control which can animate scenes using 3D objects. What is really exciting about this new control is that it is a hybrid control, which supports all the stuff the normal Canvas control does, plus adds to it 3D animation via a new 3D GL Definition language.

EZGUI 5.0 will also be pushing the limits with 2D graphics as well, with new commands to rotate, scale, alphablend and transparentBlt Bitmaps. There is a new Effects engines for the Canvas control where you can draw on top of the Canvas and then have what is drawn, anti-aliased and alphablended to the Canvas. There is also a new Image Filter engine which comes with over 20 image filters.

There are also two new engines for building your own custom controls so you can reuse code and not keep “reinventing the wheel” so to speak. The Custom Control engine allows you to build controls based on five control classes which support OwnerDraw, the Listbox, Combobox, Label, Tab and Listview controls. You can build one set of code, which can be used by multiple instances of the custom control. You write once and then use over and over again. The nice thing about Custom Controls is the Visual Designer supports them, so you can compile them to a DLL for use in the Designer, but when you generate the code for your application the control will be added via source code.

There is a new Component engine, which uses Page Forms as if they were controls. You build a custom form with all the controls in them and then create a component from it. The component then can be used over and over again and you can even have multiple instances of it. EZGUI will treat the component as if it were a control.

Now one thing needed to make the Component engine more useful was the ability to refer to the form (in the components code) as simply “{ME}” rather than by its name. Components will have their form names autogenerated by EZGUI and in your code you simply refer to them as “{ME}”. To the components parent form, it will be viewed as a control with an ID like normal controls, so externally you will refer to a component using the syntax:

ParentForm$, ComponentID&

just like you do with controls. Now to make components more powerful (as well as normal forms) an AutoSize engine was added to EZGUI, so you can automatically resize the controls on a form using predefined rules. The AutoSize engine has gotten great reports from users of the PreRelease version and while simple to use, it is very powerful.

The Visual Designer is also going through many changes to make it easier to use and more powerful. It also supports the new controls which have been added. There is new support in both the runtime and the designer for Themes. You can even turn Themes on and off for individual controls.

There is a new Splitter control and you can even customize how it looks by custom drawing the control.

OwnerDraw has been improved so you can even draw Themed objects, so controls can have a Themed look.

Suffice it to say that EZGUI 5.0 will have many exciting new features which will differentiate it from other Design tools for use with PowerBasic.

Lastly, there will be a new emphasis on the product by redefining how it is marketed to customers. No longer will EZGUI be refered to as a Visual Designer for PowerBasic. Simply put, EZGUI 5.0 can be summed up with the words:

“EZGUI 5.0 is a GUI Engine, which comes with its own visual designer and code generator”

The emphasis is GUI ENGINE !

That where the power of EZGUI lies!