Copy Link
Add to Bookmark
Report
Ictari Issue 21
ICTARI USER GROUP ISSUE 21 April 1995
___ ______ ___ _________ _________ ___
\__\ \ __\ \ \__ \______ \ \ _____\ \__\
___ \ \ \ __\ _____\ \ \ \ ___
\ \ \ \ \ \ \ ____ \ \ \ \ \
\ \ \ \_____ \ \____ \ \__\ \ \ \ \ \
\ \ \ \ \ \ \ \ \ \ \ \
\__\ \_______\ \______\ \________\ \__\ \__\
* m a g a z i n e *
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
I C T A R I U S E R G R O U P
63 Woolsbridge Road, Ringwood, Hants, BH24 2LX Tel. 01425-474415
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
INDEX FOR ISSUE 21
==================
ASSEMBLY Various maths function routines.
RSC Macros and RSC routines.
Joystick routines.
RSC file inclusion in program plus demo program.
C Questions and Answers file.
GFA Football game code.
STOS Text display program code.
Fast sprite drawing routines.
MISC DXF format text file.
Resource file format information.
RSC to source file converter program.
In next months issue of ICTARI (this may change) :-
ASSEMBLY Polyline drawing routines in machine code.
Bezier curve drawing routines.
Shape outliner routine.
Intro demo program code.
Mouse position test routine.
Upper/lower case conversion routines.
C Progress report function.
Tim Oren GEM tutorial. Part 11. GEM hooks & hacks.
BASIC Demo program on disabling menu items.
GFA Picture clipping code.
Bingo card number generator.
GFA Tool Kit book review.
STOS Bank display program code.
Chaos engine.
MISC Using the system clipboard.
GDOS information file.
For future issues :-
Picture compression routine for IMG pictures.
HP DeskJet/LaserJet compression routines (Mode 2 TIFF).
Picture switching techniques.
Printer driver code for printing mono/colour images.
Sorting algorithms.
Using the BitBlit routines.
Code for using the File Selector.
----------------------------------------------------------------------
EDITORIAL
=========
ARTICLES
--------
We still need some articles for the June issue (and beyond) so if you
can provide something, please do or we will have to rely on PD
material for future issues. We would also like to see more programming
questions asked (and answered, of course) so please send them in.
GEM TUTORIALS
-------------
In issues 3 to 7 we published the GEM tutorial series (parts 1-10) by
Tim Oren (who wrote GEM). We have now got parts 11 to 17 which we will
be starting to publish next month. In part 17 there is a reference to
a part 18 which we do not have. If anyone with Internet access can
find this one or any later ones perhaps they could send them on to us.
The filenames used are GMCL11.DOC to GMCL17.DOC for the parts that we
have already.
----------------------------------------------------------------------
CORRESPONDENCE
==============
To: Geoff Smith
From: Mrten Lindstrm
You got the warning "opcode generated for MC68020/MC68030/MC68040"
regarding the assembler instruction:
MOVE.B (A1,D1.W),D0
Try changing this into
MOVE.B 0(A1,D1.W),D0
i.e. insert a '0' before the parenthesis. To be honest I am surprised
that Lattice C (which I don't have myself) complains about the first
expression. It is true that this assembler syntax is strictly correct
only with 68020+ processors, but it should assemble identically for
them, I think, as the latter 68000 line. And e.g. Devpac (both 2 and
3) accepts the former line without complaining even when set to
generate pure 68000 code.
For someone who doesn't know any assembler: What the instruction does
is to interpret the sum of register A1 (long) + lower word of D1 (+ 0)
as an address in memory from which a byte is read and copied into
(lowest byte of) register D0.
To: Steven Gale (and others)
THE GEM CLIPBOARD AND OTHER WAYS TO TRANSFER DATA BETWEEN PROGRAMS
------------------------------------------------------------------
The GEM clipboard became official Atari standard a long time after
most of the ST documentation, still floating around, was written.
Which is probably why you haven't been able to find anything about it.
The clipboard itself is really a folder on disk, the path of which can
be found with the AES call SCRP_READ or, if not already set, set with
SCRP_WRITE. Applications supporting it typically do this within the
context of Macintosh style block editing functions, 'Cut', 'Copy' and
'Paste' (under an 'Edit' menu). The presence of these functions is no
guarantee of clipboard support however (e.g. Devpac 3 which uses an
internal buffer instead).
NOTE: A program that, like Devpac 3, uses an internal buffer for Cut,
Copy and Paste should ideally (though Devpac doesn't) have some means
- e.g. an extra, checkable, menu item 'Use Clipboard' - to toggle
between GEM clipboard and the internal buffer.
Standard keyboard short-cuts, according to both AC and German sources,
are (sadly not adhered to by Devpac):
Cut: Ctrl-X
Copy: Ctrl-C
Paste: Ctrl-V
If the menu item 'Copy' is used then the marked block of text or image
or whatever should simply be written to the clipboard. 'Cut' should in
addition delete the block within the edited document in the program.
'Paste' should cause the contents of the clipboard to be read and
inserted into the edited document (at the position of the cursor or
equivalent).
When there isn't a block selected in the program, then 'Copy' and
'Cut' should ideally be disabled. You might think that 'Paste' should
be similarly disabled when the clipboard is empty, but alas there is
no standard way, that I know of, to tell when the clipboard becomes
updated.
(If for some reason you don't use a menu in your program - e.g. in an
accessory where this isn't easy to implement - I think it should be
quite alright to use the clipboard anyway. E.g. accessed via dialogue
buttons or just with the above keyboard short-cuts.)
To write to the clipboard:
1) Call SCRP_READ to get the path to the clipboard.
If the returned string is empty, no path has ever been defined
since bootup. If so, create a directory \CLIPBRD - on drive C:
if there is one, otherwise on drive A: (or you can ask the
user). I suppose you could alternatively read _bootdev, i.e.
the word at $446 (in supervisor mode) to get the boot drive
(0=A:, 2=C: etc.). Tell the world about the new clipboard by
calling SCRP_WRITE; the path given with this should be on the
format 'C:\CLIPBRD\'.
2) Delete all files SCRAP.* within this folder.
3) Write one or more files named SCRAP.*, where * is a standard
file name extension describing the file format (see below).
IMPORTANT: If you write more than one file, each of them should
contain essentially the same information, though in different formats,
since the idea is that an importing program should only have to choose
one of them.
To read from the clipboard:
1) Call SCRP_READ to get the path to the clipboard. If the
returned string is empty (null) there is of course nothing to
read.
2) Search the clipboard path for files named SCRAP.* with
suitable extensions - corresponding to file formats that your
program supports. Pick the one of your choice (probably the
one of the richest format that your program can digest) and
load it.
Note that the correct format for the scrap path string is
'C:\CLIPBRD\' (with an ending \) but the Atari Compendium warns that
some programs set it wrongly (probably either leaving out the ending \
or else adding a filename 'SCRAP.*'), so some flexibility when parsing
it may be an advantage.
File extensions and corresponding formats are (according to Julian
Reschke - ST Magazin 9/89 - the personal efforts of whom probably did
a great deal to make the clipboard into official Atari standard):
TXT ASCII text where each line is ended with CR/LF (though a
reader should never count on the CR, but be prepared for Unix
style line ends with only LF).
Any space at the end of a line is to be interpreted as a soft carriage
return (i.e. reformatable). (Nothing is said though, about hyphens at
the end of lines.)
ASC ASCII text where only paragraph ends are marked with CR/LF.
(I.e. soft carriage returns aren't marked at all).
1WP First Word Plus
WP Word Perfect
TEX TeX
RTF Rich Text Format
EPS Encapsulated Postscript
Others are, of course, possible. Unfortunately there probably isn't a
an extension defined for Protext format files, considering that
Protext isn't much of a GEM program, but maybe we could just ask Arnor
to decide on one? (Perhaps 'PTX' would be suitable?)
For picture files I think the extensions are obvious, and the same is
probably true for most other types of data.
As a recommended minimum, exported text should always be written to a
SCRAP.TXT file at least and images probably always to a SCRAP.IMG file
(and/or SCRAP.GEM for object graphics).
Some may want a more direct data exchange, memory to memory without
going via the disk based clipboard. Unfortunately there isn't a
standard method defined for this, usable with all programs and OS-
versions. Specifically there IS an official 'Drag&Drop' protocol which
requires MultiTOS, and there are a number of unofficial protocols
defined for specific programs (e.g. Easy Draw and Gemini) which
however will probably NOT work with MultiTOS.
The natural point to start from is in all cases with the AES message
pipe. With APPL_WRITE you can send 16-byte messages to any other GEM
program, including accessories, which gets them the same way it gets
messages from the system, i.e. waiting for them through a call of
EVNT_MULTI or EVNT_MESAG. 16 bytes isn't much however and the first 6
of these are in addition reserved for special purposes; (word0:
message type ID, word1: application ID of sender, word2: 0 - or extra
length of message).
In theory you can send longer messages as well, which could then be
read by APPL_READ, but from what I have heard the AES message system
is so bug-ridden that APPL_READ really is best forgotten, and the
message length at all times kept to 16 bytes to be received by the
EVNT functions only. (As a proof of this Atari themselves chose to use
MiNT pipes for their Drag&Drop protocol rather than fix the existing
AES message system.)
MEMORY POINTER PASSING:
-----------------------
The 16 (or effectively 10) bytes of an AES message may not be much but
it IS more than enough to pass a pointer to some memory block where
more can be found, and this is how it is done I think by programs such
as Easy Draw, Gemini etc. (possibly also by K-Word/K-Roget asked about
by Peter Hibbs).
It may even be possible to define something similar to the MultiTOS
Drag&Drop protocol, but based on pointer passing instead of MiNT
pipes. There certainly would be use for such a protocol, e.g. as a
backup when MiNT pipes aren't available. (Though one complication is
admittedly that the basic AES of most STs and TTs lacks the means to
conveniently determine application IDs for window owners or other
programs.)
The first problem with the protocols of these programs is that they
aren't as widely known as they should be to become real standards. You
need to know message type IDs and structures and whether a receiver is
required to send some reply/acknowledgement etc. (I for one don't know
any of these protocols and would be very grateful indeed for details.)
IF ANYONE KNOWS OF A GOOD (AND FAIRLY WIDESPREAD) PROTOCOL I THINK WE
IN ICTARI COULD MAKE AN ACTIVE EFFORT TO SPREAD IT FURTHER! This is in
my eyes the ideal kind of task for a programmers group such as Ictari.
The second problem is that programs under MultiTOS are not usually
meant to access each others memory areas, and the 68030 processor in
Falcons and TTs can physically enforce that this doesn't happen (e.g.
'logical addresses' means that different programs may see different
things on the 'same' address). Which probably means you HAVE to use
the ordinary Drag&Drop protocol (below) when under MultiTOS.
THE DRAG&DROP PROTOCOL OF MULTITOS
----------------------------------
This, like the clipboard, is official standard which I can describe
fully (drawing on the Atari Compendium and on Julian Reschke of ST
Magazin/ST Computer; I haven't been able to test it myself). The
Drag&Drop protocol however requires the pipelining of MiNT (MultiTOS),
which means it won't work on many present systems.
Like with memory pointer passing, the initial contact is made through
a 16-byte AES message sent with APPL_WRITE. The rest of the communica-
tion takes place in a MiNT pipe.
From a user's point of view, the Drag&Drop protocol allows him to
select a piece of data within the window of one program, drag it with
the mouse to the window of another program and drop it there.
The AP_DRAGDROP message:
The structure of the AES message, to be sent with APPL_WRITE to the
program owning the destination window, is as follows:
W: 63 (AP_DRAGDROP)
W: application ID of sender
W: 0 (No extra length of this message; just 16 bytes)
W: Window handle of destination
W: Mouse X position of drop (probably got from an EVNT call)
W: Mouse Y position of drop - " -
W: Keyboard shift status at drop - " -
2B: The 2-character file extension of the MiNT pipe
16 bytes in all.
NOTE: -1 can be used in place of a window handle if the destination is
a program in general and no particular window. The recipient is then
usually expected to open a new window for the dropped data.
Receiving:
The 'recipient' should do the following as soon as it gets (through
EVNT_MULTI or EVNT_MESAG) an AES message of type 63 (AP_DRAGDROP):
1) Open the 'file' (actually MiNT pipe) 'U:\PIPE\DRAGDROP.xx'
where 'xx' are the two last bytes of the 16-byte Drag&Drop
message.
You open it as an ordinary file with FOPEN.
2) Write one byte to the pipe (with FWRITE): =0 if you are ready
to receive (in this window). =1 otherwise.
Note that even a program that doesn't otherwise support the
Drag&Drop protocol could at least write a 1 byte, since that
will spare the user having to wait for timeout (3 or 4
seconds).
If you write a 1 then immediately close the pipe (with
FCLOSE).
3) If you write a 0, you should follow this with 32 further
bytes. These should be 8 4-byte file extensions (e.g. '.IMG',
'.TXT') corresponding to file formats that your program
recognizes and in order of preference. (Compare with the GEM
clipboard above.) If you recognize less than 8 formats then
write null bytes for the ending ones.
4) Read (with FREAD) one word from the pipe giving the length of
a following header. Then read (again with FREAD) the header
itself:
4B: Format of the data to be transferred (e.g. '.TXT')
L: Length of the data
?B: Null-ended name of data chunk (to label an icon for it)
?B: Null-ended name for an associated file
?B: Possible extra info not yet defined (read it and ignore)
Both data name and filename can be left out (= only one null
byte each).
NOTE: If the return value from FREAD is 0 (zero bytes read)
this means that the sender - 'originator' - has given up and
closed the pipe. You should then do the same at your end of it
(use FCLOSE).
5) Write one byte =
0: if OK, then read as many bytes as length of data and close.
1: to abort instantly, then close.
2: if format not acceptable, then go back to step 4 above.
3: if data too long, then go back to step 4 above.
4, 5 or 6 then close, if drop was on a 'trashcan', 'printer'
or 'clipboard' respectively.
Sending:
Whenever the user has selected and dragged something, a program should
of course 'keep an eye' on the mouse. (Waiting for a mouse button
release with EVNT_MULTI.)
1) When the user releases the mouse button, call WIND_FIND to get
the handle of the window where the drop was made. Then convert
this into the ID of the owning program via a call of WIND_GET,
mode 20 (this wind_get mode doesn't exist in the basic ST and
TT AES versions but should be there in the AES of MultiTOS -
and Falcon). If it's the window of another program then
proceed.
2) Use the MiNT call PSIGNAL ('GEMDOS number' 274) to make any
SIGPIPE (13) message ignored. I.e. call Psignal(W:13,L:1).
This is to avoid your poor little program getting killed just
because no-one is reading its pipe.
3) Create the 'file' (actually MiNT pipe): 'U:\PIPE\DRAGDROP.xx'
where 'xx' could be any two ASCII characters usable in file
names. (The Atari Compendium proposes that you try your
application ID in ASCII characters - e.g. '03' if your ID is
3.) If you fail, you can just try two other ASCII characters
until you succeed.
You use the ordinary FCREATE call (GEMDOS 60) AND MAKE SURE THE
'HIDDEN BIT' IS SET - i.e. the second parameter 'attribute' = 2. (With
pipes this bit just causes reads to return EndOfFile when the other
end of the pipe has been closed.)
4) Now it is time to tell the recipient about the drop and pipe
by sending the type 63 (AP_DRAGDROP) AES message with
APPL_WRITE. See above.
5) Use the MiNT call FSELECT (GEMDOS 285) to wait for the pipe
being ready for reading (meaning that the recipient has
written something) or a timeout of 3-4 seconds.
The call should look something like
FSELECT(L:3500,L:rfds,L:0,L:0) for a timeout of 3.5 seconds,
where rfds points to a longword with only the one bit set, the
number of which = file handle of pipe.
If FSELECT returns 0 then timeout was reached (close the pipe
and abort), otherwise contact has been made.
6) Read one byte from the pipe (with FREAD). This should be
either 0 (= OK, carry on) or 1 (= Abort). In the latter case
immediately close the pipe with FCLOSE.
7) If the byte read was 0, then read 32 further bytes - the
recipient's wish list of formats described above (recipient's
step 3).
8) Decide on a format to send. This doesn't HAVE to be a format
favoured (or even mentioned) by the recipient. The originator
is free to have its views too and should the recipient refuse
to accept the decision, the originator can change it later.
Write the following structure to the pipe:
W: Length of the following header (not including this word)
4B: Format of the data to be sent (e.g. '.TXT')
L: Length of the data
?B: Null-ended name of data chunk (or just one null)
?B: Null-ended name for an associated file (or just one
null)
9) Read the one new reply byte from the recipient. If this is-
0: Write the data to the pipe (FWRITE) and then close it
(FCLOSE).
1: Close the pipe instantly
2: Try another format (repeat step 8) or close the pipe.
3: (Too much data) Try smaller format or close.
4: (Drop on trashcan) Close pipe and delete data within
program.
5: (Drop on printer) Close pipe and print data.
6: (Drop on clipboard) Close and treat like 'Copy' to
clipboard.
ARGS and PATH:
In place of data format specifiers ('.IMG', '.TXT' etc.) 'ARGS' or
'PATH' (no leading stop) could be used. Both of them seem to be
primarily intended for communication with a Desktop or similar
program.
ARGS is simply a command line, i.e. one or more parameters (usually
file specifications) separated by spaces. Note however that spaces
within a parameter are allowed by enclosing it within single quotes.
For an actual single quote character it has to be doubled (''). ARGS
data are transferred exactly like other types of data. (Sent by the
Desktop to a program into whose window the user has dropped file
icons.)
PATH on the other hand REVERSES THE DATA TRANSFER. When the originator
decides that 'PATH' data are to be sent, it is really a request that
the recipient sends the path corresponding to the receiving window. A
recipient that accepts to that with a null byte, should make sure this
is immediately followed by the path - null-ended. The data length
given by the originator should be interpreted merely as a maximum.
NOTE: The last character of the path, before the null, should be a '\'
if the window corresponds to a directory. Should the window correspond
to a file then the filename should of course be included.
(If the destination is a directory I presume that the originator will
follow the Drag&Drop PATH information exchange with a simple file copy
operation to it.)
To: Peter Hibbs
Ictari proposals for Devpac improvements
A very good initiative this is and here are my views:
1) Bug in Mon 3.10: The Ctrl-O option, to switch between colour
resolutions, seems to usually crash the ST (except when
nothing has been loaded).
2) The DC directive: With e.g. DC.B Devpac lets all values in the
range {-256:255} pass without error messages. But only values
in the range {-128:255} could of course possible have been
intended.
(A value of -256 is assembled by Devpac as 0, -255 as 1 etc.)
The corresponding thing applies for word and long values.
This bug annoyed me in Devpac2 and is still there in Devpac3.
Also, Easy Rider (German assembler by Andreas Borchard) offers
an additional directive DSC (where the S stands for Signed)
which is the same as DC but narrowing further the allowed
range of values. E.g. for byte: values {-128:127} and for
word: {-32768:32767}. This is very handy for address offsets
and I would like to see it in Devpac too.
3) More options for STRING HANDLING please. To enable the writing
of more powerful macros.
a) In Easy Rider you can set a symbol to a string with SETSTR.
b) Likewise in Easy Rider there are operations to extract
characters from strings, concatenate strings and to determine
string length and the character position within a string of
another string (1=begins at first character, 0=not found).
There is even a specialized operation to determine the
parameter position of a named (macro) parameter within a
parameter list - both given as strings.
This all makes it much easier to write powerful macros in
general (intelligently analysing their input), and can also be
used for special purposes such as encryption macros, taking
strings as input and producing - at assembly time - something
that is unreadable with a mere disk editor or similar.
(Easy Rider uses $( ) to enclose strings in expressions - e.g.
$(string). 1:$(string) extracts the first character of the
string - 's' in the example. $(str):$(string) finds the
position within 'string' where 'str' is found - =1 in the
example.)
4) Please implement the BETTER OPTIMIZATION OPTIONS of Easy
Rider:
- Instead of the Devpac O12+, which can optimize "MOVE.L
#x,An" to "MOVE.W #x,An", Easy Rider offers the more powerful
change to "LEA x,An" which can then immediately be further
optimized to either short absolute OR PC-relative addressing.
- Similarly Easy Rider can change "MOVE.L #x,-(SP)" into "PEA
x" to be possibly further optimized.
- The E.R. optimization "MOVE #0,ea" to "CLR ea" may be less
obviously useful; whoever would be stupid enough to write
'move #0,ea' rather than 'clr ea'? The answer is: a macro! And
I think it is with macros that optimization is the most useful
anyway.
- Also, the E.R. MOVEQ optimization will work not only on L
sized MOVE instructions but on W sized ones as well, IF no
explicit '.W' has been used. This admittedly may be more a
matter of personal taste, though I find it, again, to be
useful within macros.
- Finally E.R. can, if you want to, optimize branches forward
as well as backwards to short (though it of course makes the
assembly take a longer time since it has to be redone -
possibly several times).
5) Continue the Devpac integration (of assembler, editor and
debugger) by incorporating the LINKER as well. In Easy Rider
(which otherwise lacks in integration) you can use the INCLUDE
directive with object files just as easily as with source
files. As it is now I doubt that I will ever use the Devpac
linker since that would have me leave the integrated
environment of Devpac.
----------------------------------------------------------------------
To: Mrten Lindstrm
From: Mark Baker
" This means that I for instance can write my name 'Mrten
Lindstrm' with Swedish letters, and feel confident, I think, that
it will come up right not just on any Atari computer -
regardless of its nationality - but on any PC compatible too (as
long as the standard character set for these computers is used). "
It works on a PC running DOS. Windows programs use an ISO standard
character set (Americans seem to be under the impression that ANSI is
a world standards organisation and not simply a national member of the
ISO, so they incorrectly refer to ANSI C and the ANSI character set)
" The double s character of German is another problem. Atari
computers reserve character number 158 for this, but still use
a symbol identical to Greek beta (#225). On PC:s (and printers)
character 158 is a Pt character (Pesetas), and Protext simply
replaces Greek beta with German double s. (ST Protext translates any
158 into 225.) "
Many Germans seem to be unaware that esszet (sp?) and beta are
different and assume the button on their keyboard is a beta character.
This looks strange in different fonts that do differentiate between
them, and sometimes get automatically converted to ss in emails!
" Yes, the keyboards ARE different between different nationalities!
I send in a file (KBD_MAPS) with keyboard maps for some nationalities,
which I hope could be extended by people who know more. "
There should be no need for a programmer to know the keyboard map.
" 2) If you do place commands on the main keypad, and you document
the commands as bound to keys with certain characters on them,
then you normally have to check input ASCII NUMBERS RATHER
THAN SCAN CODES. "
For alt shortcuts you need something like:
keytable = Keytbl( (char *)-1, (char *)-1, (char *)-1 ) ;
ascii = *(*keytable + scan ) ;
Atari's style guides tell you not to use alt shortcuts, but I, like
most other people, do because there aren't enough ctrl shortcuts and
most of them have defined meanings.
" Should you put TWO functions on the same key, however, things become
a bit more problematic. A bad example is in Devpac 3, Mon, where
. and , are documented as 'Next/Previous View' while
Shift-. is said to 'Open View' and
Shift-, to 'Close View'.
The key [I had to press] has the < and > on it, and is on my Swedish
keyboard, as I said, different from the , and . keys (but not on the
British one, I know). Bad documentation/programming that is. (Even the
masters aren't infallible.) So, how should Hisoft have done it? "
Well, they could have just put < and > in the menu. But in general it
is not recommended to use shift and a punctuation symbol.
" One simple solution would have been to not use keys on the main
keypad at all, but to use some function keys. (I am surprised that
none of these have been used in Mon.) "
I prefer to have function keys set up by the user.
" Another solution, of course, would have been to document 'Open
View' as '>' and 'Close View' as '<'. But this wouldn't perhaps
look as neat. Apart from letters and keys, I think this is what could
cause the most confusion with the user. If your program prints dates
for any reason .."
I normally get and display dates in the form 24 Mar 95; this is the
normal way for most Europeans and using the name of the month means
Americans aren't confused (where they would be by 24/03/95) but I
believe this could still confuse people from some Scandinavian
countries, who use year/month/day, is this true?
To: Jonathan White
" 0 No icon
1 A diamond with an exclamation mark (Note only)
2 Point down triangle with a question mark (warning)
3 A Hexagon with 'STOP' inside it (are you sure???) "
Apparently AES 4 adds a couple more, an i for information and a disc.
I don't suggest anyone uses them as on older AES versions you will get
various bits of junk including the mouse pointers.
" Note Icon 1 is usually meant for note messages you simply have
to acknowledge - this program won't run | in less than one meg {OK} "
According to Atari's style guide this is for errors or conditions
requiring immediate action. I have in the past used it for program
credits etc, but apparently you should use the i or no icon at all for
this.
" technically against Atari user interface guidelines (which
state buttons should go OK CANCEL OTHERS) "
Actually they state that it should be OK Cancel Others ie. mixed
case for all except OK.
*/ Actually we may have capitalized those words to make them stand out
better but as we don't have the original copy we can't be sure. If we
did we apologise to Mrten. ICTARI /*
" The first step is to call form_center() to set the point on the
screen you wish a particular dialog box to appear. Then you call
form_dial() with the FMD_START parameter to tell the system you are
drawing on the screen and not to do anything while you do so.
Then you use objc_draw() to actually display the dialog on the
screen. "
You also need wind_update() This is not mentioned in the manual for
Lattice C but apparently it has been documented by Atari all along; if
you don't have it your dialogue will in some circumstances be messed
up in a multitasking system.
" Note that because form_dial() intercepts all inputs via
an evnt_multi() inside it, while you have a dialog on the screen,
the rest of your application, and any other applications in a
non-preemptive multitasking environment (errr.. Geneva is the only one
for the Atari, as far as I know) will be frozen. In MultiTOS, the
programs continue running, but the screen is not updated outside your
dialog. "
evnt_multi() does NOT stop the other applications running. In fact it
allows them to, you must have an event library call if you want other
apps to run under Geneva (have I said this before?). The wind_update()
call stops other apps from displaying or receiving input and there is
one built in to form_do().
" First off, define your pointer as OBJECT *(something) Second, use
rsrc_gaddr to point the pointer at the root object of the tree by
using rsrc_gaddr(R_TREE, NAME_OF_ROOT_OBJECT, &(something)) "
^^^^^^^^^^^^^^^^^^^
It should be the name of the tree which is not necessarily the same as
the name of the root object.
To: Mrten Lindstrm
" of it being too basic). Here is one concerning a relatively basic
and fundamental issue: - whether or not MALLOC (GEMDOS 72) could
return memory blocks on odd addresses. Have I missed an official
statement about this? Was there ever an early TOS version returning
odd memory block addresses, or was it just a false alarm from the
start (not unusual in old Atari documentation)? "
I don't think it was specified either way. Perhaps your book may have
read this to mean that any addresses were possible where actually
Atari just forgot to document that it always returns even addresses.
As old TOS versions return even addresses and they couldn't change it
now without breaking too much code - and why should they change it
anyway? - I think you're safe assuming it to be even.
To: Peter Hibbs
" While on the subject of HiSoft's assembler I think that, although
it is very good at assembling, the source code editor itself could
still be improved. For example, I would like to see an option to
export a highlighted block to the 'clipboard' so that the marked text
could be copied into another program such as Harlekin, for
example. I would like to see the first few characters of each
'bookmark' location displayed in the information line of the window so
that I can remember which 'bookmark' is which. I would like to have a
'move block' option where a block of text can be moved in one
operation rather than having to 'copy' and then 'delete'. I could
probably think of a few more as well if pushed. "
I'm sure I could add a few to that list. For example the project files
used in Lattice C could be improved greatly, (although the otherwise
almost identical editor supplied with Devpac unfortunately lacks that
facility altogether)
" If anyone else has any other additions they would like to see,
please send them in and perhaps I will send them all to HiSoft.
They might even implement them if they come from a programmers group,
well you never know ! "
They've apparently stopped developing for the Atari (and for the Amiga
as well???) although they're still selling stuff.
To: Jim Taylor
" To complement the Bezier line drawing routines in my CAD
application I would like some information/C code on Spline curve
generation. "
I can explain exactly what a spline is; I've got information in a
textbook about how to calculate it. I can send you a photocopy if you
want but I warn you it is difficult (I've got maths A levels at grade
A and I can't understand it, if I could I'd have explained it here).
A spline is a piecewise polynomial interpolation, that is there is a
polynomial (normally a cubic) between each point. Unlike using a
single polynomial for all points this method doesn't oscillate between
points. The polynomials are chosen so that the spline is several times
differentiable at the nodes (fixed points). That is there are no
sudden jumps in the spline itself or in it's gradient.
To: Steve Gale
" I am writing a program in which I would like to transfer data to
or from other programs via the system 'clipboard' but there does not
seem to be any information available about this. Is there any
standard format for this transfer, is the data stored in RAM or on
disk, etc. "
It's stored on disc, in any format used for disc files, eg. .IMG for
bitmaps, .GEM for vector graphics, .TXT or .RTF for text etc. You can
have multiple formats so your own application can get more information
from its own format while other apps can read the standard format.
" Does anyone have any information on this subject ? "
I might send an article to Ictari about this. */ Please do. ICTARI /*
To: Tony Harris
"I know there are ways of avoiding some of the standard GEMDOS
calls, that is by going directly to the hardware, but is there any
way of doing this for the file calls, ie, f_open, f_read and f_close?"
Not really. You can go directly to the disc hardware, but this differs
depending on what device it is so it is definitely not recommended.
The bios Rwabs() call avoids using GEMDOS but this too is not
recommended as it doesn't understand file systems and treats the disc
as a series of sectors: if you want to access files on the disc you
need to use GEMDOS. The bios call is useful for writing a sector
editor but that's about it.
" Is there a way of preventing the mouse from entering part of
the screen ? i.e. to prevent corruption when redrawing. At the
moment I turn off the mouse if it strays into the barred area,
but what I really want is the effect of not being able to go any
further. "
Not easily, without hooking into a timer interrupt and repositioning
the mouse if necessary. And even then it could possibly move and
destroy your image before your interrupt runs.
To: Lee Russell
" I am part way through writing a program to crop .IMG format
pictures. Has anybody got some 'C' code they want to donate to save
a block of memory in that format? "
I've got code for uncompressed .IMG files; if anyone has code for
writing compressed files I'd be interested in that myself.
----------------------------------------------------------------------
To: ICTARI
From: Iain Mcleod
Is ICTARI going to be on the Internet? (WWW). If it is/going to be,
could you inform me of its address.
*/ We do not have an Internet address at present although there would
be some obvious advantages if we did. We will investigate the
possibility of joining although the costs of purchasing a high speed
Modem and membership fees may be the deciding factor. We do have a
number of members who have access to the Internet and we hope that
they will look out for any PD articles/software which would be of
interest to programmers and send it on to us. Perhaps these members
could also let us know how to join the Internet, what software and
hardware would be required and how much it all costs. ICTARI /*
----------------------------------------------------------------------
To: *.*
From: Peter Hibbs
Is there any 'legal' way to determine if a menu has been dropped down.
In my current project I am using 'evnt_multi' with a zero timer event
to flash a cursor, etc. When the user moves the mouse into the menu
bar I need to stop the cursor flashing underneath the menu options.
Unfortunately, even though the AES is displaying the drop down menu
items, the timer event is still active and the cursor continues to
flash. To get round this I have defined a 'rectangle evnt' which
covers the area of the menu bar so that when the mouse moves into the
menu the rectangle event code switches off the cursor. I also had to
add another test in the timer event code to monitor the x and y co-
ordinates of the mouse to do the same test because if the mouse was
moved too quickly into the menu bar, the rectangle event did not catch
it. Fortunately the rectangle event function is disabled by the AES
when a menu is dropped down so that even though the mouse is moved
down into the main screen area as the menu items are
hilighted/unhighlighted, the rectangle event code does not signal that
the mouse has moved outside the defined rectangle (which would then
re-enable the cursor). While this system does seem to work quite well
it does seem a bit messy. Is there a simpler way to do this?
Does anyone know how the Canon Bubble Jet printers print out bit map
graphics images? Any information would be very welcome.
I have just purchased an Autoswitch Overscan unit for my STFM (but not
fitted yet) to give me a larger screen area. Does anyone have any tips
on how to write software which will still work properly on larger size
screens. Obviously the screen width and height can be found from the
v_opnwk VDI function but looking through the manual there seems to be
a number of other things which also need to be taken into
consideration. The manual does give some guidance for programmers but
it is very brief and written in broken English (and even lapses into
German a couple of times). Has anyone had any practical experience of
writing software for larger screens, if so perhaps they would like to
let us know how to implement such code.
--------------------------- End of file ------------------------------
