Borland's Kylix: turbocharging Linux development
Finally! Some Actual Code!

Scott Courtney
Monday, April 9, 2001 08:30:07 AM
Less intuitive, at first, was the creation of a main menu and a toolbar. Kylix has
abstracted the concept of an Action List, which contains all of the user-driven action
events that can be handled by the form. Instead of defining the menus and toolbars, and
then filling in their behaviors (the actions) later, Kylix makes you define the
comprehensive list of actions first and then attach them to toolbars or menus. This was
counter-intuitive to me, but once I realized what Kylix expected I had no difficulty
completing the task. Likewise, the little button images (mini-icons) used for the dropdown
menus and toolbars are drawn from an Image List which is created before the menus and
toolbars that use it. In this process, I found a Kylix bug: You are supposed to be able to
re-order the images by dragging them around in the Image List, but I was totally unable to
get this feature to work except for moving one image, one time. I am not sure why it
worked once, but I was unable to make it work again. This was upsetting to my sense of
order that wanted the images to be inside the Image List in the same order they appeared
on the menus of my application. Practically speaking, though, it had no effect because
each Action List item has an integer index into the Image List, and these can be in any
arbitrary order.
Once you have defined the Action List and (if desired) the Image List, creation
of the application's main menu is extremely easy, and
consists only of selecting the blank spaces on the menu and using the context
popup menu to add a new item, then editing its properties to point to the
appropriate action. Creating a toolbar is equally easy and involves much the
same process.
Finally! Some Actual Code!
Once I had the GUI defined, it was time to attach real code to the event handlers. Kylix
uses an object-oriented event model in which the very act of calling a particular function
on a particular object instance implies which object receives the event and which event
type is being received. This is similar to the event model in Java 1.1 and later, although
the notion of an event as an object in and of itself is downplayed. In any event (pun
intended), the model used in Kylix and Java alike is much more elegant than the old "case
statement from hell" approach used in the days of Windows 3.x.
Some of the trickiest operations needed by the text editor application are also
pre-built for you. Kylix includes a selection of common actions such as cut, copy, delete,
and paste, and these can be attached easily to menu items. Additional code required for
clipboard functions: zero.
For the rest of the functions, most notably the File... menu, the code was simple and
straightforward, and typical of what is used in just about any GUI environment. At
various points in the coding, a little code-completion menu will pop up and offer a fairly
intelligent listing of the possible completions of the current syntactic token. For
example, after you have typed the name of an object instance, the popup will show the
method (function) names that apply to that object. As you type the first few letters, the
choices narrow further and further. At any time, you can use the keyboard or the mouse to
select the one you want. Parameter help is also included.
The File...Open dialog is trivial, because it simply invokes a standard dialog
operation (modal) and then reads the result to see if the user actually chose a file. I
did find a bug in this function: If you add an option of "all files" (for file type) and
have a mask of "*", it fails to match anything. Apparently Borland has introduced a
DOS-ism here in that they assume every file will match "*.*" and not "*" by
itself. Hopefully this will be fixed in the next release, but for now it is an annoyance.
The Help...About dialog is also trivial to implement, if you don't want anything
fancy. I was pleasantly surprised to note that a fixed-
text label that exceeds one line automatically wraps, something that some IDEs
do not handle gracefully.
At this stage, I had a working text editor! All the basic clipboard and text selection
features worked as expected. Help...About did what it was supposed to do, and behaved
modally as is typical. Except for the filename masking bug previously mentioned,
File...Open also worked as intended and text files (.txt extension) opened perfectly. It
was interesting to note that there were, by default, no scroll bars in the text editing
area, but the PgUp, PgDn, and arrow keys allowed navigation. I am sure that adding the
scrollbars is simply a detail I overlooked, perhaps only a matter of setting the right
properties on the text area itself.
Next: Non-GUI elements and a usability acid test. »