** 1 page Suggestive Remarks / 802 words **
Mike Kerslake with some suggestions for better Atari computing and
some ideas for programmers...
In AC#6, I floated the idea of an A to Z sorter, and by AC#8
Matthias Jaap in Germany had come up with A-Z which does the job
admirably. Happily Matthias has continued development and A-Z v2.0
is now available so we've included it on Reader Disk.
A-Z v2.0
** A2Z_MAIN.GIF here **
** On Reader Disk banner/disk here **
A-Z is a GEM utility which can sort ASCII text files from A to Z
or vice versa. Version 2.0 offers the following useful extra
features including:
* Block sorting: Ideal for sorting address lists!
* Variable sorting, using a user definable separator character
* Statistics summary
* Ported to FaceValue and compiled using Licom 1.1
* More GEMscript commands supported
* A-Z can play X32 sound files!
Taking stock
Now to a program suggestion - after all that's what this column is
all about! John Firth in West Yorkshire, England recently sent us
this letter:
I have been using a invoicing, stock control and cashflow program
called SYSTEM 3 for about four years. I recently discovered it's
not compatible with the the year 2000, so invoices, statements and
so on issued after 31st December 1999 will show the date as 89 -
when the program was first written. I contacted DIGITA
INTERNATIONAL who published the original program, but they
informed me it's no longer supported and no upgrade is available.
SYSTEM 3 is a very versatile program. Each customer is given an
account number along with their details. All goods and services
supplied are then entered into the stock control file, each item
given a code number along with a description, quantity, purchase
price and selling price. To issue a invoice you type in a account
number along with the customers name, date and a box to enter
their order number is displayed. The code number for goods
supplied is then typed in, and the description relating to that
item is shown, enter quantity sold and the total price is
automatically calculated for you, along with any VAT payable,
which is shown separately. The printed invoice shows your contact
details along with customers details and items supplied.
Sadly I'm not aware of any other similar supported software so it
seems likely John will be stuck in less than a year's time unless
we can come up with something.
I'm wondering if it would be possible to develop an Auto folder
utility, TOS patch or some combination of both which could take
over date handling at the system level and offer a global fix for
programs like SYSTEM 3.
Maybe there's already a suitable program or an alternative stock
control and invoicing application that will work beyond 2000 - if
you know of anything which may help John please do let me know.
If there's a programmer reading this who has an idea how SYSTEM 3
could be patched, come up with a global fix or is interested in
developing an alternative stock control and invoicing system Atari
Computing would be interested in sponsoring the project - much
like we have with GEMTrade, again please do get in touch if you
can help.
Good manners
Mention of GEMTrade reminds me that there's been a bit of an
interesting discussion recently in the CIX ataricomputing
conference between GEMTrade author Mark Wherry and Andy Giddings
about GEM and new protocols and calls/features for MiNT, MagiC,
NVDI and support for machine-specific features of the Falcon, TT,
and other machines. Mark mentioned he found out that you can't
really use too many of the newer features offered by MagiC/MiNT as
people start moaning at you. Mark used WDIALOG in GEMTrade v2.00
and got complaints!
** WDPD.GIF here **
** caption **
WDIALOG - a mixed blessing?
** /caption **
Programmers might like to bear in mind that although many people
do have quite well specified systems, many others don't, so any
programs they write should perhaps not rely too heavily on other
programs to take care of the basic tasks. It might be an idea for
new stand-alone programs to take advantage of extra facilities
offered by other programs or at least co-exist with them. A good
example is the Everest text editor which can quite happily do its
job without NVDI being installed, but if it detects NVDI it allows
you to use that program's font and print systems.
Just my thoughts anyway, but please do feel free to submit your
suggestions and ideas via the usual editorial address or direct to
me at:
** BC **
mike@ataricomputing.com
** /BC **
Finally, my often promised Help Directory will make an appearance
soon, but it will be incorporated in a new section in the magazine
which will provide help and contact details and details of local
user groups etc as well.
Mike Kerslake