rosenkra@convex.com (William Rosencranz) (06/19/91)
maybe this is a dumb question but...
is it possible to call VDI routines without writing a full blown GEM
application? ideally, i would like to just use something like v_fillarea
or somesuch. i realize that i need a device handle, so maybe i need
all the other stuff (baggage) too. it would be great to be able to
use VDI in .ttp programs. can u open a device without appl_init?
if it is not possible to write a .ttp with VDI (i suppose it is not
since the extension tells the OS to either prepare for GEM or don't)
then is it possible to read command line args with a GEM program (.prg)?
i.e. one doing appl_init, open workstation, etc. if so, how? i use
alcyon. my shell is gulam. is it possible with gcc/gemfast/etc?
i'd hate to have to do the fill with line A or directly to the screen.
i only need white fills. this makes drawing 3-d xyz datasets (like
FFT maps) easy if u draw from back to front. the fill eliminates hidden
features of the plot (desirable). i have used this in full GEM progs,
but want to use it in .ttp progs where i draw points and lines (with
line A). don't beat me up about line A, either. if/when i get a TT,
i will switch. as far as i know, line A is the ONLY way to draw lines
(other than fixing pixels in Physbase) in a .ttp.
thanx...
-bill
rosenkra@convex.com
--
Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra
Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.comcsbrod@immd4.informatik.uni-erlangen.de (Claus Brod) (06/19/91)
rosenkra@convex.com (William Rosencranz) writes: >is it possible to call VDI routines without writing a full blown GEM >application? ideally, i would like to just use something like v_fillarea >or somesuch. i realize that i need a device handle, so maybe i need >all the other stuff (baggage) too. it would be great to be able to >use VDI in .ttp programs. can u open a device without appl_init? There are good reasons why TTP programs are meant as non-GEM programs. You shouldn't use VDI or AES calls in a TTP program. >if it is not possible to write a .ttp with VDI (i suppose it is not >since the extension tells the OS to either prepare for GEM or don't) >then is it possible to read command line args with a GEM program (.prg)? >i.e. one doing appl_init, open workstation, etc. if so, how? i use >alcyon. my shell is gulam. is it possible with gcc/gemfast/etc? No problem at all. A full-blown GEM program can read a command line just like any other program can. You should, however, use shel_read() to look for a command line passed to your program from its ancestor via shel_write(). If there's no command line in the shel_read buffer, check for a GEMDOS command line in the basepage using the standard argc/argv mechanism. >i'd hate to have to do the fill with line A or directly to the screen. >i only need white fills. this makes drawing 3-d xyz datasets (like >FFT maps) easy if u draw from back to front. the fill eliminates hidden >features of the plot (desirable). i have used this in full GEM progs, >but want to use it in .ttp progs where i draw points and lines (with >line A). don't beat me up about line A, either. if/when i get a TT, >i will switch. as far as i know, line A is the ONLY way to draw lines >(other than fixing pixels in Physbase) in a .ttp. Strictly speaking, it isn't even appropiate to use line A in a TTP. The line A routines were meant as low-level subroutines for the built in VDI screen driver. As such, they are part of the VDI, and if you want to avoid VDI calls, the consequence is not to use line A either in a TTP. As long as you don't want to publish your program in some way, you can, however, stick to the line A method. I think you can even use VDI calls in TTPs without major problems, but as you said before, this isn't the kind of thing you're meant to do. ---------------------------------------------------------------------- Claus Brod, Am Felsenkeller 2, Things. Take. Time. D-8772 Marktheidenfeld, Germany (Piet Hein) csbrod@medusa.informatik.uni-erlangen.de Claus_Brod@wue.maus.de ----------------------------------------------------------------------
micro@imada.ou.dk (Klaus Pedersen) (06/20/91)
csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) writes: >There are good reasons why TTP programs are meant as non-GEM programs. >You shouldn't use VDI or AES calls in a TTP program. Can you give me some of these good reasons? - and why not? The VDI is allways running, isn't it? You can use the VDI from the AUTO folder - before GEM have been installed or more correctly the AES. There are many programs use form_alert(), without an appl_init(), and that is worse isn't it? (because the global array and probaly other structures too haven't been init'd). Klaus, micro@imada.ou.dk
csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) (06/21/91)
micro@imada.ou.dk (Klaus Pedersen) writes: >Can you give me some of these good reasons? - and why not? >The VDI is allways running, isn't it? You can use the VDI from the AUTO folder >- before GEM have been installed or more correctly the AES. I don't think it is documented that you can access the VDI from a TTP program. It _is_ documented, though, that you may use the VDI from an AUTO folder program (note: maybe a reason why AUTO folder programs must have the extension PRG!). To my knowledge, nothing has been said from Atari about this issue, so some clarification from Allan might inject the necessary facts into this thread. TOS or TTP programs should use GEMDOS or BIOS in- and output routines, nothing else. The TOS mode was meant for this, i.e. making ports of character-oriented software easier. >There are many programs use form_alert(), without an appl_init(), and that is >worse isn't it? Certainly worse, you're right. ---------------------------------------------------------------------- Claus Brod, Am Felsenkeller 2, Things. Take. Time. D-8772 Marktheidenfeld, Germany (Piet Hein) csbrod@medusa.informatik.uni-erlangen.de Claus_Brod@wue.maus.de ----------------------------------------------------------------------
healy@cod.NOSC.MIL (Mike Healy) (06/21/91)
In article <1991Jun20.124043.8248@imada.ou.dk> micro@imada.ou.dk (Klaus Pedersen) writes: >csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) writes: >>There are good reasons why TTP programs are meant as non-GEM programs. >>You shouldn't use VDI or AES calls in a TTP program. > >Can you give me some of these good reasons? - and why not? >The VDI is allways running, isn't it? You can use the VDI from the AUTO folder >- before GEM have been installed or more correctly the AES. > >There are many programs use form_alert(), without an appl_init(), and that is >worse isn't it? >(because the global array and probaly other structures too haven't been init'd). > >Klaus, micro@imada.ou.dk I can give you one good reason I determined empirically. A while back I posted a plea for help because a program would run fine from the Laser C shell, but evnt_multi calls would not respond to the mouse, even though they caught keyboard activity. It turned out that the program would also run fine under gulam. But not the desktop. This program was a .ttp that called appl_init and used vdi calls. I renamed it to .prg and voila!, it now runs ok from the desktop. The mouse is now caught by evnt_multi. Since my program is a port from unix and wants a parameter string, I think I'll just create a .ttp front end to pick up the parameters and shel_write them, then Pexec the .prg . Is there a better way? Mike Healy healy@cod.nosc.mil
hvaalde@cs.vu.nl (Aalderen van Harold) (06/21/91)
csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) writes: >There are good reasons why TTP programs are meant as non-GEM programs. >You shouldn't use VDI or AES calls in a TTP program. And how should we treat GEM programs that take parameters? Only way to get the desktop to ask for parameters is to change the extension to TTP Harold van Aalderen (hvaalde@cs.vu.nl)
ue@nathan.ruhr.de (Udo Erdelhoff) (06/22/91)
In <1991Jun20.124043.8248@imada.ou.dk>, Klaus Pedersen writes: >csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) writes: >>There are good reasons why TTP programs are meant as non-GEM programs. >>You shouldn't use VDI or AES calls in a TTP program. >Can you give me some of these good reasons? - and why not? Ok, here' is one: Did you ever use Gemini (or any other cli)? If you start a .TOS (or .TTP) using VDI, you'll have a lot of garbage on the screen. Not to speak of using these programs (TOS with VDI calls) in a multitasking environment (MINT, MultiGem) /s/ -- Udo Erdelhoff smart: ue@nathan.ruhr.de Am Westheck 170 Fido: Udo Erdelhoff on 2:245/52.1 W-4600 Dortmund 12 (FRG) Maus: Udo Erdelhoff @ DO Please keep your replies short - I have to pay for recieving mail
ue@nathan.ruhr.de (Udo Erdelhoff) (06/24/91)
In <3149@cod.NOSC.MIL>, Mike Healy writes: >Since my program is a port from unix and wants a parameter string, I >think I'll just create a .ttp front end to pick up the parameters and >shel_write them, then Pexec the .prg . Is there a better way? Sure, noone has said that .prg couldn't get it's arguments like a TTP via the basepage (or, in C, within the argv/argc variables). /s/ -- Udo Erdelhoff smart: ue@nathan.ruhr.de Am Westheck 170 Fido: Udo Erdelhoff on 2:245/52.1 W-4600 Dortmund 12 (FRG) Maus: Udo Erdelhoff @ DO Please keep your replies short - I have to pay for recieving mail
csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) (06/24/91)
hvaalde@cs.vu.nl (Aalderen van Harold) writes: >And how should we treat GEM programs that take parameters? >Only way to get the desktop to ask for parameters is to change the extension >to TTP That's the reason why Atari came up with a new program type with extension GTP in TOS 2.x and 3.x. Nonetheless, your point is valid. This is a real problem in the old TOS versions. ---------------------------------------------------------------------- Claus Brod, Am Felsenkeller 2, Things. Take. Time. D-8772 Marktheidenfeld, Germany (Piet Hein) csbrod@medusa.informatik.uni-erlangen.de Claus_Brod@wue.maus.de ----------------------------------------------------------------------
<ONM07@DMSWWU1A.BITNET> (06/24/91)
In article <10278@star.cs.vu.nl>, hvaalde@cs.vu.nl (Aalderen van Harold) says: > >csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) writes: >>There are good reasons why TTP programs are meant as non-GEM programs. >>You shouldn't use VDI or AES calls in a TTP program. > >And how should we treat GEM programs that take parameters? >Only way to get the desktop to ask for parameters is to change the extension >to TTP > (1) Most third-party desktops allow this (well, at least Gemini :-) (2) The new Atari Desktop allows this (extension GTP - GEM takes parameters) (3) The GEM application *itself* can prompt the user for a command line. where's the problem? >Harold van Aalderen (hvaalde@cs.vu.nl) ___________________________ cut here _____________________________________ Julian F. Reschke, Hensenstr. 142, D-4400 Muenster, Phone: ++49 251 861241 fast eMail: ONM07@DMSWWU1A.BITNET, slow: jr@ms.maus.de (++49 251 77216) ____________________ correct me if I'm wrong _____________________________
ONM07@DMSWWU1A.BITNET (06/24/91)
In article <1991Jun19.112606.20682@convex.com>, rosenkra@convex.com (William Rosencranz) says: > >maybe this is a dumb question but... > >is it possible to call VDI routines without writing a full blown GEM >application? ideally, i would like to just use something like v_fillarea >or somesuch. i realize that i need a device handle, so maybe i need >all the other stuff (baggage) too. it would be great to be able to >use VDI in .ttp programs. can u open a device without appl_init? > No. At least not a 'virtual' workstation, because you need to know the handle of the currently opened 'physical' workstation used by the AES (use graf_handle() to get it). >if it is not possible to write a .ttp with VDI (i suppose it is not >since the extension tells the OS to either prepare for GEM or don't) >then is it possible to read command line args with a GEM program (.prg)? >i.e. one doing appl_init, open workstation, etc. if so, how? i use >alcyon. my shell is gulam. is it possible with gcc/gemfast/etc? > There is no difference for GEM programs. You can use the usual argc/argv binding. >i'd hate to have to do the fill with line A or directly to the screen. >FFT maps) easy if u draw from back to front. the fill eliminates hidden >features of the plot (desirable). i have used this in full GEM progs, >but want to use it in .ttp progs where i draw points and lines (with >line A). don't beat me up about line A, either. if/when i get a TT, >i will switch. as far as i know, line A is the ONLY way to draw lines >(other than fixing pixels in Physbase) in a .ttp. > The question is: why in the hell do you WANT to use graphics in a non-graphics-oriented program. Why don't you write a GEM program? ___________________________ cut here _____________________________________ Julian F. Reschke, Hensenstr. 142, D-4400 Muenster, Phone: ++49 251 861241 fast eMail: ONM07@DMSWWU1A.BITNET, slow: jr@ms.maus.de (++49 251 77216) ____________________ correct me if I'm wrong _____________________________
pmh@cutie.ka.sub.org (Patrick M. Hausen) (06/26/91)
In article <3149@cod.NOSC.MIL> healy@cod.NOSC.MIL (Mike Healy) writes: > I can give you one good reason I determined empirically. A while back I > posted a plea for help because a program would run fine from the Laser C > shell, but evnt_multi calls would not respond to the mouse, even though > they caught keyboard activity. It turned out that the program would also > run fine under gulam. But not the desktop. This program was a .ttp that > called appl_init and used vdi calls. I renamed it to .prg and voila!, > it now runs ok from the desktop. The mouse is now caught by evnt_multi. > > Since my program is a port from unix and wants a parameter string, I > think I'll just create a .ttp front end to pick up the parameters and > shel_write them, then Pexec the .prg . Is there a better way? If you run it from a shell just leave it named .prg. A program doesnt have to be named .ttp to take parameters. You can pass them anyway. This is only difficult if you try to do it from the desktop. Cheers, PMH -- ||| Patrick M. Hausen | phone : +49 721 699234 (voice and carrier) ||| Gerwigstr. 11 | e-mail: pmh@cutie.ka.sub.org (UUCP) / | \ D-7500 Karlsruhe 1, Germany | uk9u@dkauni2 (BITNET) "Well they say your folks are telling you to be a super star, but I tell you just be satisfied to stay right where you are. Keep yourself alive." (QUEEN)