seattle@hydra.unm.edu (David G. Adams) (04/08/90)
Ok, I've tried a few little experiments, but I'm still mystified as to how to get my stupid.c file turned into a stupid.acc file. I've tried cc -VGEMACC -o stupid.acc stupid.c just like it says in my MWC manual, even made sure it didn't exit and all. It doesn't use any windows, so I thought it'd be easy. (stupid me) All it does is print numbers to the screen using Bconin. Well, on boot-up it seems to want to run my program - definately not what I intended. Is there a programming guide for Desk Accessories? (I'm sure someone has asked this before, but... :-} ) Also, I still can't get curses.c to compile with MWC. IF ANYBODY WITH MWC WHO'SE GOTTEN THIS TO COMPILE IS OUT THERE, PLEASE tell me how you did it. Thanks! Dave /|\ | seattle@hydra.unm.edu <> Dadams10@GEnie <> David G. Adams \ < |/\ | LotE | "Modern love is automatic" - A Flock of Seagulls | \| | Live it! | Don't bug the University 'bout nuthin' I've said. /
steve@thelake.mn.org (Steve Yelvington) (04/08/90)
[In article <2225@ariel.unm.edu>,
seattle@hydra.unm.edu (David G. Adams) writes ... ]
> Ok, I've tried a few little experiments, but I'm still mystified as to
> how to get my stupid.c file turned into a stupid.acc file. I've tried
> cc -VGEMACC -o stupid.acc stupid.c just like it says in my MWC manual,
> even made sure it didn't exit and all. It doesn't use any windows, so
> I thought it'd be easy. (stupid me) All it does is print numbers to
> the screen using Bconin.
I hope you mean Bconout. :-)
> Well, on boot-up it seems to want to run my
> program - definately not what I intended.
Yup. That's what it's supposed to do. When the system comes up, it loads
the .ACC files and executes them. It's the DA's responsibility to
initialize itself, then call the Event Manager to return system control to
the AES until it's time to go to work. See below.
There are some other (stupid) restrictions. The desk accessory cannot own
file handles or memory; the system thinks they belong to the current
program. It also doesn't own the menu bar, so if you want to clear the
screen and do generic (vt52) output, you must copy the menu bar manually
and restore it manually.
> Is there a programming guide for Desk Accessories?
Maybe for developers, I don't know. I haven't seen the developer
documentation. I don't want to have to swear out a blood oath never to
tell anyone that Atari exists. (Do you know why you never see lawyers at
the beach? The cats keep covering them up with sand....)
> (I'm sure someone has asked this before, but... :-} )
Occasionally, but probably not frequently enough for the list of questions
that davidli is compiling.
Here is a generic desk accessory skeleton that I posted in this newsgroup
in response to a similar question in April 1989. I wrote it for use with
Sozobon C, but it should compile under MWC with no problem, except perhaps
fullpath(). Sozobon users should note that dastart.o is available by
anonymous ftp from terminator.cc.umich.edu.
(I know nothing about your curses problem.)
O/ cut here
=====O\==================================================================
/*
* accskel.c
* desk accessory skeleton for Sozobon C
* link dastart.o, then this module, then the GEM bindings, then dlibs.
*/
#define MENU_ID "File selector"
#define AC_OPEN 30
/* these arrays are not needed for GEMFAST */
int
contrl[12],
intin[128],
intout[128],
ptsin[128],
ptsout[128];
main()
{
int apid, menuid, msgbuf[8];
apid = appl_init(); /* say hello to the AES */
menuid = menu_register(apid, MENU_ID); /* add me to the Desk menu */
while (1) /* loop forever */
{
evnt_mesag(msgbuf);
if ( (msgbuf[0] == AC_OPEN) && (msgbuf[3] == menuid) )
wakeup(); /* go into active mode */
}
appl_exit(); /* you'll never get here -- supposedly */
}
wakeup() /* Whatever needs to be done. Here we display the fsel ... */
{
char path[128], defult[13] = '\0';
int button;
fullpath(path,"*.*");
fsel_input(path,defult,&button);
}
--
Steve Yelvington at the lake in Minnesota
steve@thelake.mn.org ncastellano@eagle.wesleyan.edu (04/10/90)
In article <A1555240072@thelake.mn.org>, steve@thelake.mn.org (Steve Yelvington) writes: > char path[128], defult[13] = '\0'; My version of Sozobon C would not compile this unless I changed 'char' to 'static char'. This agrees with what I know about sting initialization in C, which is that you can only initialize char strings if they are extern or static. Even after getting it to compile, the desk accessory didn't seem to do anything; it merely exited to the desktop. Any idea what I might be doing wrong? I ld'd the libraries in the order suggested (dastart.o, accskel.o, aesfast.a, vdifast.a, dlibs.a) Any help would be appreciated. > -- > Steve Yelvington at the lake in Minnesota > steve@thelake.mn.org -- ncastellano@eagle.wesleyan.edu ncastellano@wesleyan.bitnet Sinkhole!dEADHEAd@mast.citadel.moundst.mn.org "We are happy. (_silence._) What do we do now, now that we are happy?" -Estragon, _waiting for godot_ by samuel beckett
ncastellano@eagle.wesleyan.edu (04/12/90)
I'm re-posting this since I don't think my last one got out due to this news system here being really deranged. ------------------------------------------------------------------------------ Path: eagle!ncastellano From: ncastellano@eagle.wesleyan.edu Newsgroups: comp.sys.atari.st Subject: Re: DA's and Curses Message-ID: <16567@eagle.wesleyan.edu> Date: 9 Apr 90 21:36:44 GMT References: <2225@ariel.unm.edu> <A1555240072@thelake.mn.org> Lines: 21 In article <A1555240072@thelake.mn.org>, steve@thelake.mn.org (Steve Yelvington) writes: > char path[128], defult[13] = '\0'; My version of Sozobon C would not compile this unless I changed 'char' to 'static char'. This agrees with what I know about sting initialization in C, which is that you can only initialize char strings if they are extern or static. Even after getting it to compile, the desk accessory didn't seem to do anything; it merely exited to the desktop. Any idea what I might be doing wrong? I ld'd the libraries in the order suggested (dastart.o, accskel.o, aesfast.a, vdifast.a, dlibs.a) Any help would be appreciated. > -- > Steve Yelvington at the lake in Minnesota > steve@thelake.mn.org -- ncastellano@eagle.wesleyan.edu ncastellano@wesleyan.bitnet Sinkhole!dEADHEAd@mast.citadel.moundst.mn.org "We are happy. (_silence._) What do we do now, now that we are happy?" -Estragon, _waiting for godot_ by samuel beckett
steve@thelake.mn.org (Steve Yelvington) (04/12/90)
In <16567@eagle.wesleyan.edu>, ncastellano@eagle.wesleyan.edu writes: >In article <A1555240072@thelake.mn.org>, > steve@thelake.mn.org (Steve Yelvington) writes: >> char path[128], defult[13] = '\0'; > >My version of Sozobon C would not compile this unless I changed 'char' to >'static char'. This agrees with what I know about string initialization in C, >which is that you can only initialize char strings if they are extern or >static. Right. I slopped the code together in a hurry and posted it (a year ago!) without testing it. And sure enough, it was hosed up. Arggh! I hate it when that happens. It's pretty hard to make an excuse when you repost a year-old mistake. At least this time somebody actually tried to compile it. :-) >Even after getting it to compile, the desk accessory didn't seem to do >anything; it merely exited to the desktop. Any idea what I might be doing >wrong? I ld'd the libraries in the order suggested (dastart.o, accskel.o, >aesfast.a, vdifast.a, dlibs.a) Any help would be appreciated. You didn't do anything wrong. I typed in a couple of things from bad documentation -- the description of AES messages on page 516 of "Atari ST Application Programming" by Pollack and Weber. The lesson here is twofold: One, don't post untested code, and two, NEVER believe any documentation about the ST* until you have checked it out three ways. (* Same could be said for anything read on Usenet.) AC_OPEN is 40, not 30. And the DA's apid should be found in msgbuf[4], not msgbuf[3]. Corrected code follows. #define MENU_ID " File selector " #define AC_OPEN 40 #ifndef GEMFAST int contrl[12], intin[128], intout[128], ptsin[128], ptsout[128]; #endif main() { int apid, menuid, msgbuf[8]; apid = appl_init(); /* say hello to the AES */ menuid = menu_register(apid, MENU_ID); /* add me to the Desk menu */ while (1) /* loop forever */ { evnt_mesag(msgbuf); if ( (msgbuf[0] == AC_OPEN) && (msgbuf[4] == menuid) ) wakeup(); } appl_exit(); /* you'll never get here -- supposedly */ } wakeup() /* Whatever needs to be done. Here we display the fsel ... */ { char path[128], defult[13]; defult[0] = '\0'; int button; fullpath(path,"*.*"); fsel_input(path,defult,&button); } -- Steve Yelvington at the lake in Minnesota steve@thelake.mn.org
ncastellano@eagle.wesleyan.edu (04/13/90)
In article <A1248990348@thelake.mn.org>, steve@thelake.mn.org (Steve Yelvington) writes: > char path[128], defult[13]; > defult[0] = '\0'; > int button; Again, Sozobon didn't seem to like this. I had to move the "int button;" up above the "defult[0] = '\0';". After that it worked fine. Did this compile on your machine or was it a last-second change made while posting it? (I don't think I'm using the most recent version of Sozobon; some newer compilers do allow declarations in the middle of code.) Anyway, please continue to post source code examples, they are very informative and useful. -- ncastellano@eagle.wesleyan.edu ncastellano@wesleyan.bitnet Sinkhole!dEADHEAd@mast.citadel.moundst.mn.org "We are happy. (_silence._) What do we do now, now that we are happy?" -Estragon, _waiting for godot_ by samuel beckett