** Suggestive Remarks / 832 words **
** Piccies? **

Mike Kerslake with some suggestions for better Atari computing and some ideas for programmers...

First off this issue we have some suggestions from Carl Hafner in the USA who writes: "I use a utility on my iMac called CopyPaste which, among other things, allows you to keep and use 100 clipboards. This has saved me a-lot-of-work when submitting my website URL to the various search engines. I don't recall ever having seen anything like this for the Atari."

I am aware that Katherine Ellis programmed for the Atari a Clipboard utility which gave you some control over Clipboards, and perhaps this is worth checking out first?  However, if anyone wants to develop the idea further, Carl has helpfully provided a web site address to check out, Script Software:

http://www.scriptsoftware.com/

Carl has also thought the idea of the Atari having a dedicated web site devoted to giving out information on latest versions of software would be useful. The Mac has something like this at:

http://www.versiontracker.com/

Well, there are already a number of Atari sites that provide a similar service, but there is perhaps scope for someone to set up a very comprehensive site?

On to programming suggestions now. Like many people I tend to collect a lot of bits of information from all over the 'net and through emails etc. There's no problem saving the files to disk in different folders depending on their content, but often these individual files would be better merged into one file for easy editing, printing and viewing. For example, you have a series of emails about the same subject and would like to merge them into one file. The obvious solution is to use a text editor and merge one file after another, but perhaps a better solution is to have some sort of utility that would automatically append one file onto another - preferably using the Drag and drop protocol. Options to append files in order depending on file date, size and so on would be nice.

Staying with text file manipulation I'm rather taken with the idea of a multiple text file viewer. Viewing programs such as ST-Guide and Textview are excellent, but they restrict you to loading and viewing one file at a time. It would be very useful to be able to select a whole bunch of files from a file selector such as Freedom and load them into a viewer at one go. You could have a keyboard or mouse controlled way of switching between files to be viewed and various options to copy and paste etc. The Revenge Document Displayer is perhaps a model for this sort of utility, but wrapped up in a more modern GEM look. It would also be nice if such a viewer could handle a variety of text formats apart from the usual TXT and ASC ones. Something capable of reading Papyrus or RTF documents and stripping out everything apart from the text would be very welcome.

Millennium Mayhem

Following on from John Firth's problems with SYSTEM3 in AC#12 I've received this response from Roger Burrows:

In your February column, John Firth reported his problems with the SYSTEM3 invoicing program (the February issue was my first look at your excellent magazine).

The fact that dates after 1999 revert to the date the program was written (rather than 1900 for example) helps demonstrate why there is no simple and universal fix to the "Y2K bug".
Faced with the decision on how to handle dates after 1999, programmers can choose to do whatever they like.
If it's just the printed date that's wrong, then it might be possible to fix this by intercepting the print output and changing 1989 to 2000 (assuming no one orders a quantity of 1989, or has a customer number of 1989...).  If the date is always in exactly the same format (for example 31 July 1995), then the printer intercept can look for this, and only change 1989 (to 2000, 2001...) when preceded by the expected string format - which should increase the safety of this approach.

If the date used internally is also wrong, then it's a bigger problem, because the calculation of stock on hand, interest payments, and so on is likely to be wrong. This could be worked around, albeit with a considerable level of inconvenience, as follows:
** UL **
* Set the system clock back 8 years (8 instead of 10 years so leap years are handled correctly) to 1991, with the correct month/day.
* Start a completely new stock control file to avoid the above-mentioned problems with internal date calculations.
* Install a printer-intercept program that will change 1991-1999 to 1999-2007, as described above.
* Prepare to repeat this in 2007!
** /UL **
Except the day of the week will be wrong - oh well, back to the drawing board!

Roger Burrows, Anodyne Software

Finally, this column is open to everyone and it would be nice to have a few more ideas for programmers to get their teeth into.