|
Summer 1999
|
I learned after I got the job at “The Total” that other VB programmers were too locked into the mindset of “VB = work with MS SQL Server” to take on a Pick front end project. Lucky for me, as I got this interesting job of breaking new ground.
In mid-1998, Alan Scott (PICKBASIC) and I (VB) had the task of GUI-ising IPLUS, our general-purpose accounting/manufacturing app. I was given the brief to connect via TCP/IP Winsock as terminal emulators do rather than using the Objects or ODBC methods. This was mainly so that existing programs could be adapted rather than replaced, but also because of a lack of standards across platforms for Objects and the time-consuming and difficult experiences we had trying to get ODBC to perform. We soon found ourselves taking an approach which could be used for apps in general, and “PixieLink(TM)” was born.
The Terminal “telnet” TCP/IP connection method is an Internet technology.
So when faced with the challenge of providing a GUI interface we looked to the Internet and found a useful comparison with the World-Wide-Web which delivers a GUI look and feel to what was once a very terminal-like medium by ingenious use of plain text “tags”. We took that same idea of a “protocol” and come up with one to suit the Pick terminal situation, borrowing ideas from both the Web and internet email.
You use it by editing “VBGUI” tags into existing PICK/BASIC output statements, e.g.
| <TEXTBOX,ACTION=NOMINATE,WIDTH=10> | first entry of a code | |
| <TEXTBOX,ACTION=1,WIDTH=36> | first entry/edit field | |
| <TEXTBOX,ACTION=2,WIDTH=24,ROWS=3> | second entry/edit area with 3 associated rows e.g. for addresses |
You can service both legacy terminals and PixieLink clients with the one application using IF ... END ELSE ... END blocks, e.g.:
IF GuiUser = 1 THEN
* Code including tags goes here e.g.:
sForm = sForm:@(22,7):”<TEXTBOX,ACTION=4,WIDTH=30>”END ELSE
* Original code goes here e.g.:
sForm = sForm:@(22,7)END
All along the first principle has been to make me work hard on GUI interpretation to minimise the conversion workload for my PICKBASIC colleagues. The resulting approaches include a co-ordinate system based on the terminal character screens of old e.g. on startup, PixieLink measures the Windows Screen and creates a system for it of 80 units wide by 25 units in height. All size and co-ordinate properties in “PixieLink” are therefore in character equivalent units i.e. HEIGHT, WIDTH, TOP, LEFT, MAXLENGTH …so current position values in legacy code do not need conversion.
The high profile of HTML, the Web, Browsers and all that stuff was a big issue. We did consider trying to get close to HTML in tag keywords and syntax, but some of the basic HTML concepts are too distant from terminal practice to fit in tidily. For example, (x,y) positioning of text on a display is a fairly new development in HTML with methods like “cascading style sheets” that are much more complex than what we need. Instead we went for keywords used in Visual Basic, which will be familiar or at least relevant territory for many of you PICKBASIC punters. We had great debates over details like the comma-as-delimiter versus the space as found in HTML. The comma won on the strength of the need to quote spaces inside tags in some circumstances, e.g. use of tags to set preferences.
Example: Display of text at a defined screen position:
CRT “<POSITION,TOP=5,LEFT=50>Contact Person”
Or, if you are using Term mm-mon or our supplied Term VBGUI:
CRT @(50,5):”Contact Person”
i.e. no conversion required at all!
CRT ‘<SPAN STYLE=”POSITION:ABSOLUTE;TOP:20%;LEFT:62.5%”>Contact Person</SPAN>’
Another HTML issue is the way it was originally designed as part of a system for economical reading of web documents with connection only as needed, i.e. the user connects to the server sporadically for batch exchange of info. That is unacceptable for much data entry practice e.g. risking user anger or despair when a whole page of data entry is done and then gets rejected because the first item was in error! Some reasonable workarounds are starting to appear, ref PixieWeb Chapter 6 for our own latest solution, but why buy into a problem that Pick has never had?!
Tempting as it was to hook into a fashionable thing, the continuous link given by “telnet” and the use of legacy terminal screen layouts as starting points for design, meant that this was not the Web and shouldn’t be squeezed into that mould. “PixieLink” uses client processing power only for the mechanics of translating user actions into a conversation with Pick that is as close as possible to previous terminal conventions. Everything important remains driven by server-side PICKBASIC code: screen layouts, dynamic changes to the screen in response to user actions, and all business rules data processing.
That didn’t stop me from borrowing nice Web GUI conventions. I started with menus and made the menu choices look and act like hyperlinks. I also put in a browser-like navigation control like a history list of previously-used programs for quick return to them (see Figure 1 below). My colleagues heroically kept me on the true path of also continuing to support the previous keystroke interface.
The menus were of course a warm-up for the main course, the “functional form”, or data entry screen. I was quickly learning about “action codes” and building in modes of operation for controlled entry versus freedom of movement. As my PICKBASIC improved so did the syntax, as in I managed to make it simpler as we went. GUI designs need to be defined in advance much more than traditional terminal displays which tend to live in the moment and there are often more rules needed to manage the greater (wilder ?!) range of allowed user behaviour. I’ve managed to translate user entry into the commonly used Pick screen user-movement methods. The main trick or treat is what happens when a user enters data in an “entry control”, usually a “TEXTBOX”. On leaving the field, if there is a change, PixieLink sends the associated code to the Server, and when the Server replies then follows up with the data. This is different to the “point to the field in advance” convention with terminal users, and yet from the Server point of view it seems to be the same and so little or no change is needed to PICKBASIC input routines.
By the end of 1998, we had our first “IPLUS/PixieLink” users and we began to get other developers interested. I started a new learning curve around the amazing variety of approaches that you PICKBASIC developers take towards that terminal screen. Grid-like tabular data, e.g. lines in invoices, loom large in my creative life. I struck, first-up, grid-like screens more complex than what I’ve seen in any PICKBASIC program since, and while it was hard work to model them, at least it has been a case since of “if it can handle that, it can handle anything”. What this has led to with grids and other such elements is that we offer several models, with the idea that you switch on and configure the one closest to your practice.
We also developed a conventional terminal emulation capablility to cover partly converted applications and applications in use while GUI screens are being phased in.
As we got expert in driving the “telnet” line of communication to Pick, so we started to breed other Pixies from that telnetting engine. The Web interest led to “PixieWeb”(TM) which enables the Microsoft IIS Web Server to act like a terminal in conversations with Pick. We originally saw this as useful for limited public access to database info but it is now showing promise as an application-building and delivery system in its own right. We use it with all-new programs which extend the range of the existing app into providing web services. Refer to our PixieWeb Test Drive on http://www.thetotal.co.nz/ for working examples. “PixieEditor”(TM), “PixieMail”(TM) and “PixieTransfer”(TM) have since followed.
I am surprised that few if any inventors have followed this line of enquiry. I’m pleased too because I get to do it! Maybe our group happened to bring just the right combination of interests, directions and ideas together at the right moment. By taking a selection of Web App ideas and combining them with the rock solid established base of telnet communication we are achieving the PICK GUI facelift by enhancements to PICKBASIC code rather than throwing that code away and starting again. You only have to look at “Visual Basic ASP scripts” within “IIS” to see something new, trendy and fashionable which is very like PICKBASIC within Pick with tags thrown in. We too can put tags into PICKBASIC and make it a “thoroughly modern Millie” of a language.
John Calder
The Total Computer Company
John Calder has a varied and colourful background including teaching and
film-making. “Film” covered everything from “alternative cinema”
seen in art festivals to local co-ordinator for a visiting Japanese TV crew
hunting out unusual, comical and bizarre material for offbeat game and quiz
shows. An increasing interest in programming for film/video graphics then education
teaching and admin led to his career change to VB programmer by the late 90’s.
Last Updated: 30 June 1999