AshLite Possibilities

29 July, 2006
last modified

Using AshLite as an "agent" or "server/client" processor creates many opportunites for creative programming solutions. Following are a few imagined (or even suggested) applications where AshLite would be very convenient.

  • Image Acquisition. A good example of an AshLite utility would be a simple image acquisition program. Such a function is many times easier and less expensive to implement under Windows than UNIX/AMOS.  In fact, you could probably do it with entirely free software that comes bundled with most imaging devices. The only problem is that these programs provide too much user flexibility, making it impractical to standardize and streamline procedures from the application point of view. In contrast, by using the A-Shell Imaging Toolkit, you can easily write a small utility which invokes the imaging device's TWAIN user interface, but which regains control as soon as the image is acquired, allowing it to be saved with the name and format specified by the application. (Note that this example would require licensing of the A-Shell Imaging Toolkit.)
     
  • Image Display. There are plenty of other image display utilities available on a modern Windows workstation, so the only point here would be if you wanted some kind of customized display functionality not easy to get with other applications. One example might be a situation where you wanted to display a selection of several images and allow the operator to select one with the mouse, then transmitting the image name (or associated part number, etc.) back to the host.
     
  • GDI Printing. With relatively little difficulty, an AMOS or UNIX application can now take advantage of A-Shell's GDI printing capabilities. In the case of an A-Shell server with PC's running ZTERM over network connections, this is as simple as adding COMMAND=SBX:GDIPRT to a printer INI on the server.  (In other words, no programming required at all!) In the case of AMOS or serial or non ZTERM connections, a little more effort is needed to transfer the files to the PC, from whence they may be processed by AshLite.
     
  • Windows FAX Service Interface. Same idea as for GDI printing.
     
  • EMAIL Interface. Now that AshLite supports the EMAILI.SBX (Interactive email) interface from the spooler to the local email client, "printing" a file to email is basically the same as any other GDI printing operation (as described above.) The GDIPRT interface is used on the server side to reroute the file being spooled to the PC, where the COMMAND=SBX:EMAILI interface routes it to the local email client. (This requires intervention by the user to specify one or more recipient addresses at print time, and optionally to edit the message, but on the other hand, this means that no changes to the application are needed. For an unattended email interface, use EMAILX.)
     
  • Remote XCALLs. A new generic remote XCALL interface routine, RXCALL.SBX, permits an application on one machine to perform an XCALL that is actually executed on a remote machine. The advantage of this technique over simply launching an executable on the PC is that you bi-directional parameter passing capabilities.
     
  • Indirect COM interface. The RXCALL interface just described allows UNIX/LINUX applications to access the A-Shell/Windows COM (ActiveX) interface.
     
  • Interface to a sound player. Although you can play a sound easy enough by passing the WAV file name to the ZTERM "Shell Execute" function, you have no real control over the options and you are stuck with the currently specified sound application interface. AshLite, on the other hand, can play sounds with no visible interface, can interrupt a currently playing sound, etc. (This might have applications in online help.)
     
  • Interface to portable/handheld devices. Use AshLite to upload, download and synchronize data with portable and handheld devices. For example, PDA's come with Windows synchronization utilities; a host application might tap into these via AshLite to sync data between the handheld and the central database.
     
  • Interface to other technologies. Interface to any other technology that is easier to implement under Windows than UNIX/AMOS. Some examples: signature capture, thumbprint recognition, voice input, iButton!, telephony, Microsoft Agent (animated "assistants"), etc.