Iconify check
Levien van Zon
What is the best way to check if an AES supports iconification?
-=Levjenno
------
Levien van Zon (lv...@bio.vu.nl)
MALEB Homepage: http://huizen.dds.nl/~levjenno/
(Atari/Amiga/Linux/Therapy?/Red Dwarf/etc.)
------
"Wrong, wrong. Absolutely brimming over with wrongability."
--Rimmer
Annius Groenink
lv...@bio.vu.nl (Levien van Zon) writes:
>What is the best way to check if an AES supports iconification?
That depends on what you mean by `support'. The multitos AES
iconification scheme is worthless, so I wouldn't call it support.
--
Annius V. Groenink .......................................... a...@cwi.nl
Room M233, CWI, Kruislaan 413, 1098 SJ Amsterdam phone +31 20 592 40 77
.. and ZFC/home P.O.Box 15813, 1001 NH Amsterdam phone +31 20 4 208 248
.. z...@zfc.nl ..... www.nl.net/~zfc/ ..... www.cwi.nl/~avg/ ...........
Anthony Jacques
In article <5c2kfi$i...@balaena.bio.vu.nl>, lv...@bio.vu.nl (Levien van Zon) writes:
>What is the best way to check if an AES supports iconification?
appl_tinfo or some such function. [I cannot remember exactly how
right now...]
However, why do you need to check to see if it supports iconify?
All AES versions will just ignore the SMALLER gadget if it doesn't
support it. (ie. wind_create(SMALLER | TITLE...) will just not create
the gadget, and you will never get a WM_ICONIFY message on older
AES versions).
Anthony
--
-------------------------------------+------------------------------
Anthony Jacques IRC: AnthonyJ | STOS Falcon Extension v1.2a
| Generic STOS Fixer v1.3
mailto:jacq...@cs.man.ac.uk | KP Flash and GEM-DEU 0.7c
http://www.cs.man.ac.uk/~jacquesa/ | available from WWW pages
-------------------------------------+------------------------------
New program - KP Flash - Sound 2 Light (literally) for the Falcon
--------------------------------------------------------------------
Update - Generic STOS Fixer 1.3 released - various bug fixes etc.
--------------------------------------------------------------------
John Kormylo
l > What is the best way to check if an AES supports iconification?
appl_getinfo(AES_WINDOW, &wf, &unused, &gadgets, &unused);
if(gadgets & 1) { /* iconify supported */
Of course, you might want to check if appl_getinfo() is supported
first.
___ Mountain Reader II - #00000053
--
|Fidonet: John Kormylo 1:106/7861
|Internet: John.K...@7861.conchbbs.com
|
| Standard disclaimer: The views of this user are strictly his own.
Michael White
Annius V. Groenink wrote
>lv...@bio.vu.nl (Levien van Zon) writes:
>
>>What is the best way to check if an AES supports iconification?
>
>That depends on what you mean by `support'. The multitos AES
>iconification scheme is worthless, so I wouldn't call it support.
Er, what makes it worthless? I use it quite a bit, especially with
CAB. It's great to iconify CAB while it's downloading a slow web
page. It allows you to do other things....
Mike White (mic...@fastlane.net)
Levien van Zon
Anthony Jacques (jacq...@cs.man.ac.uk) wrote:
: However, why do you need to check to see if it supports iconify?
: All AES versions will just ignore the SMALLER gadget if it doesn't
: support it. (ie. wind_create(SMALLER | TITLE...) will just not create
: the gadget, and you will never get a WM_ICONIFY message on older
: AES versions).
Yeah, but my program needs to be able to iconify. And I want to be able to
check if the OS can do it, and if it can't, use the fuller button as an
iconify button (with some iconify routines, ofcourse).
-=Levjenno
------
Levien van Zon (lv...@bio.vu.nl)
MALEB Homepage: http://huizen.dds.nl/~levjenno/
(Atari/Amiga/Linux/Therapy?/Red Dwarf/etc.)
------
"A raccoon tangled with a 23,000 volt line today. The results blacked
out 1400 homes and, of course, one raccoon."
-- Steel City News
Levien van Zon
Michael White (mic...@fastlane.net) wrote:
: >
: >That depends on what you mean by `support'. The multitos AES
: >iconification scheme is worthless, so I wouldn't call it support.
: Er, what makes it worthless? I use it quite a bit, especially with
: CAB. It's great to iconify CAB while it's downloading a slow web
: page. It allows you to do other things....
Well, can anyone tell me how to do it then?
Annius Groenink
mic...@fastlane.net (Michael White) writes:
>Annius V. Groenink wrote
>>lv...@bio.vu.nl (Levien van Zon) writes:
>>
>>>What is the best way to check if an AES supports iconification?
>>
>>That depends on what you mean by `support'. The multitos AES
>>iconification scheme is worthless, so I wouldn't call it support.
>Er, what makes it worthless? I use it quite a bit, especially with
>CAB. It's great to iconify CAB while it's downloading a slow web
>page. It allows you to do other things....
What makes it worthless is that you can only iconify if the user
clicks the SMALLER. There is no way to actively iconify a window.
Also, many applications don't support iconify all, so if someone
control + clicks on the smaller a slot gets reserved, but no
icon appears. The slot will be empty until you reboot.
Truly one of the worst protocols I've ever seen.
Mark Baines
>What is the best way to check if an AES supports iconification?
program (window parts list must include SMALLER and react to any WM_ICONIFY
messages in your evnt_multi.
Slainte mhath
Mark
--
* Mark S Baines * "The Atari A to Z" book *
* Inver, Scotland * An encyclopaedia on all that is Atari *
* * 340 A5 pages, 128,000 words, 2,238 entries, 101 tables *
* 01862 871624 * Only available from me, e-mail me for further details *
Guy Harrison
In article <5c2kfi$i...@balaena.bio.vu.nl>
lv...@bio.vu.nl (Levien van Zon) said:-
>What is the best way to check if an AES supports iconification?
No need to bother. Just implement support for the messages. After all,
you won't get them if they aren't supported.
There is an alternative iconification server which is more powerful
and pretty easy to implement. It comes as an auto folder program and a
cookie called 'ICFS' iirc and thus can work on any system. It is
available for download somewhere but I've lost those details.
Hopefully I've said enough for someone else to know what I'm on about
and fill in the gaps. ;-)
__
Guy Harrison
Email g...@swampdog.demon.co.uk
swam...@dial.pipex.com
Web http://www.swampdog.demon.co.uk/index.html
Michael White
Annius V. Groenink wrote:
>mic...@fastlane.net (Michael White) writes:
>>Annius V. Groenink wrote
>>>lv...@bio.vu.nl (Levien van Zon) writes:
>>>
>>>>What is the best way to check if an AES supports iconification?
>>>
>>>That depends on what you mean by `support'. The multitos AES
>>>iconification scheme is worthless, so I wouldn't call it support.
>
>
>>Er, what makes it worthless? I use it quite a bit, especially with
>>CAB. It's great to iconify CAB while it's downloading a slow web
>>page. It allows you to do other things....
>
>
>What makes it worthless is that you can only iconify if the user
>clicks the SMALLER. There is no way to actively iconify a window.
I'm not sure I understand the issue. Are you saying there's no way
for an application to iconify itself? What do you mean by "actively
iconify a window"?
>Also, many applications don't support iconify all, so if someone
>control + clicks on the smaller a slot gets reserved, but no
>icon appears. The slot will be empty until you reboot.
Don't you just normally click (not control-click) on the smaller button
(the button to the left of the "maximize" button)?
And besides, the smaller button doesn't normally appear on applications
that don't support the iconifcation, right? I've never seen it on, say,
my Prospero C editor. But I do agree that it would be nice if you could
iconify applications that don't explicity handle iconification.
Mike White (mic...@fastlane.net)
Alastair J. Houghton
> >What is the best way to check if an AES supports iconification?
>
> That depends on what you mean by `support'. The multitos AES
> iconification scheme is worthless, so I wouldn't call it support.
That's a bit unfair. It's iconification support is OK... even
under bloatware like Windows, iconification is handled largely
by the program in question.
The best way is to use appl_getinfo(). This function exists if
you find that appl_find("?HAGI") (I think) returns something
other than a failure code (which I guess must be negative).
____________________________________________________________
Alastair Houghton aj...@ic.ac.uk
Imperial College, London
Levien van Zon
Alastair J. Houghton (aj...@doc.ic.ac.uk) wrote:
: > >What is the best way to check if an AES supports iconification?
: The best way is to use appl_getinfo(). This function exists if
: you find that appl_find("?HAGI") (I think) returns something
: other than a failure code (which I guess must be negative).
Could you give some more details? (I don't have any docs on the "new" AES
calls)
Thanks...
-=Levjenno
------
Levien van Zon (lv...@bio.vu.nl)
MALEB Homepage: http://huizen.dds.nl/~levjenno/
(Atari/Amiga/Linux/Therapy?/Red Dwarf/etc.)
------
Q: How many journalists does it take to screw in a lightbulb?
A: Three. One to report it as an inspired government program to bring
light to the people, one to report it as a diabolical government
plot to deprive the poor of darkness, and one to win a pulitzer
prize for reporting that Electric Company hired a lightbulb
assassin to break the bulb in the first place.
Mario Becroft
In <avg.85...@news.cwi.nl> Annius Groenink wrote :
>What makes it worthless is that you can only iconify if the user
>clicks the SMALLER. There is no way to actively iconify a window.
>Also, many applications don't support iconify all, so if someone
>control + clicks on the smaller a slot gets reserved, but no
>icon appears. The slot will be empty until you reboot.
>
>Truly one of the worst protocols I've ever seen.
Luckily all these problems only exist in AES 4.1. Other AES versions (e.g.
N.AES, Geneva...) don't have these problems. In those cases you can iconify
a window without the user having clicked on the smaller, and slots are only
reserved when the window actually is iconified.
--
Mario Becroft Auckland, New Zealand
mbec...@tos.ak.planet.gen.nz _
http://www.pl.net/user/mario/ o( )
Tariland: http://www.pl.net/user/mario/tariland/ / /\
Thomas Binder
Hi!
In article <avg.85...@news.cwi.nl>,
a...@cwi.nl (Annius Groenink) writes:
> [Iconify worthless?]
> What makes it worthless is that you can only iconify if the user
> clicks the SMALLER. There is no way to actively iconify a window.
Not true. Atari post-documented a way to iconfy a window "by code". IIRC it
was wind_set(win, WF_FULLXYWH(?), -1, -1, -1, -1);
> Also, many applications don't support iconify all, so if someone
> control + clicks on the smaller a slot gets reserved, but no
> icon appears. The slot will be empty until you reboot.
That's a bug in Atari's MultiTOS. Clever(er) implementations (like the ones
found in N.AES or MagiC) don't create such empty slots.
Ciao
Thomas
--
Thomas Binder (Gryf @ IRC) bin...@rbg.informatik.th-darmstadt.de
PGP-key available on request! gr...@hrzpub.th-darmstadt.de
Thomas Binder
Hi!
In article <5ckndv$i...@rs18.hrz.th-darmstadt.de>, I wrote:
> Not true. Atari post-documented a way to iconfy a window "by code". IIRC it
> was wind_set(win, WF_FULLXYWH(?), -1, -1, -1, -1);
OK, here's the correct way to do it (thanks to Thomas Much who sent this
correction to me):
-- cut here --
Create a window (or if it's open, call wind_close()),
make a wind_set(handle,WF_ICONIFY,-1,-1,-1,-1) and a
wind_open(handle,-1,-1,-1,-1) call. There you are.
appl_getinfo() tells you if you can use iconification at all.
-- cut here --
Hope that helps ...
Anthony Jacques
In article <5cdboc$p...@news2.nkn.net>, mic...@fastlane.net (Michael White) writes:
>
>Annius V. Groenink wrote:
>>What makes it worthless is that you can only iconify if the user
>>clicks the SMALLER. There is no way to actively iconify a window.
>
>for an application to iconify itself? What do you mean by "actively
>iconify a window"?
Eg. when the user selects under the 'windows' menu 'iconify' the
application is able to iconify its own windows.
>>Also, many applications don't support iconify all, so if someone
>>control + clicks on the smaller a slot gets reserved, but no
>>icon appears. The slot will be empty until you reboot.
>
>Don't you just normally click (not control-click) on the smaller button
>(the button to the left of the "maximize" button)?
>And besides, the smaller button doesn't normally appear on applications
>that don't support the iconifcation, right? I've never seen it on, say,
>my Prospero C editor. But I do agree that it would be nice if you could
>iconify applications that don't explicity handle iconification.
Annius means ICONIFY ALL which is sent when you click on the smaller
icon holding control. This should cause the application to appear to
iconify all its windows down into one icon. Try it. Desktop likes it,
and some programs like it, but others (eg Thing?) will ignore the
WM_ALLICONIFY message which will cause AES 4.1 problems (but not N.AES)
Peter Rottengatter
On 3 Feb 1997, Thomas Binder wrote:
> Hi!
>
> In article <5ckndv$i...@rs18.hrz.th-darmstadt.de>, I wrote:
> > Not true. Atari post-documented a way to iconfy a window "by code". IIRC it
> > was wind_set(win, WF_FULLXYWH(?), -1, -1, -1, -1);
> OK, here's the correct way to do it (thanks to Thomas Much who sent this
> correction to me):
>
> -- cut here --
> Create a window (or if it's open, call wind_close()),
> make a wind_set(handle,WF_ICONIFY,-1,-1,-1,-1) and a
> wind_open(handle,-1,-1,-1,-1) call. There you are.
Why should it be closed and reopened ? From my experience it works
perfect if only the wind_set is called !?!
> appl_getinfo() tells you if you can use iconification at all.
> -- cut here --
>
> Hope that helps ...
Cheers Peter
---------------------------------------------------------------------
Peter Rottengatter pe...@pallas.amp.uni-hannover.de
---------------------------------------------------------------------
Anthony Jacques
In article <5d49en$u...@rs18.hrz.th-darmstadt.de>, gr...@hrzpub.th-darmstadt.de (Thomas Binder) writes:
>Hi!
>
>In article <5ckndv$i...@rs18.hrz.th-darmstadt.de>, I wrote:
>> Not true. Atari post-documented a way to iconfy a window "by code". IIRC it
>> was wind_set(win, WF_FULLXYWH(?), -1, -1, -1, -1);
>OK, here's the correct way to do it (thanks to Thomas Much who sent this
>correction to me):
<snip>
Thanks a lot! :)
A couple of minor points I discovered (yes it does work - it tried it last
night).
* Geneva (005 demo run as a MiNT AES) doesn't support this, and it allocates
an empty slot and looses the window. However, N.AES/AES 4.1 do support this.
Iconify is broken in both XaAES and oAESis atm. so I didn't bother testing
it with them. :)
* When you recieve the WF_UNICONIFY message, you will get -1,-1,-1,-1 as the
position/size of the window, so you will need to have a way of restoring it
to the correct position (put it in the wind_set(...WF_UNICONIFY...) call).
Does anyone know if it works under Magic? (it doesn't really matter, as magic
doesn't even 'have' iconify, as it is < AES 4.0 and appl_getinfo shouldn't be
available < 4.0 so you cannot check for its presence...)
Magnus Kollberg
jacq...@cs.man.ac.uk (Anthony Jacques) writes:
> Does anyone know if it works under Magic? (it doesn't really matter, as magic
> doesn't even 'have' iconify, as it is < AES 4.0 and appl_getinfo shouldn't be
> available < 4.0 so you cannot check for its presence...)
Ehhh... what do you mean with this? MagiC does have iconify and appl_getinfo
should be available. Why its not truely AES 4.1 compatible and report
3.99 as AES version I don't realy understand either. It wouldn't cause to
much work to make it support AES 4.1 fully and it would make me happier.
Andreas Kromke should know.
//Magnus Kollberg
--
+----------------------------------------+
| Falcon040, Bad Mood support team |
| email: Magnus....@emw.ericsson.se |
+----------------------------------------+
Martyn Tidd
Magnus Kollberg wrote:
> should be available. Why its not truely AES 4.1 compatible and report
> 3.99 as AES version I don't realy understand either. It wouldn't cause to
> much work to make it support AES 4.1 fully and it would make me happier.
>
> Andreas Kromke should know.
Now, we've been here before :-)
Regards
Martyn
Magnus Kollberg
Martyn Tidd <etl...@etlxdmx.ericsson.se> writes:
> > should be available. Why its not truely AES 4.1 compatible and report
> > 3.99 as AES version I don't realy understand either. It wouldn't cause to
> > much work to make it support AES 4.1 fully and it would make me happier.
> >
> > Andreas Kromke should know.
>
> Now, we've been here before :-)
We sure have, but it can't hurt to talk about it again. :-)
Alastair J. Houghton
> Does anyone know if it works under Magic? (it doesn't really matter, as magic
> doesn't even 'have' iconify, as it is < AES 4.0 and appl_getinfo shouldn't be
> available < 4.0 so you cannot check for its presence...)
According to my Compendium, AES >= 3.40 have appl_getinfo(); it's just
that
AES < 3.99 don't support modes above 4. But since you can inquire the
maximum
mode number that's supported, this isn't a problem. You should really
check
for AES >= 3.40, then ask which functions are supported. If the
functions
to test for iconification aren't supported, you don't have
iconification.
Otherwise you do. No messing around with checking for version 4.0 and
MagiC
separately.
MagiC supports iconification as of version 3, I think. The AES version
reported is always 3.99 for MagiC (or has been up to now, as far as I'm
aware).
Anthony Jacques
In article <3302E022...@doc.ic.ac.uk>, "Alastair J. Houghton" <aj...@doc.ic.ac.uk> writes:
>> Does anyone know if it works under Magic? (it doesn't really matter, as magic
>> doesn't even 'have' iconify, as it is < AES 4.0 and appl_getinfo shouldn't be
>> available < 4.0 so you cannot check for its presence...)
>
>According to my Compendium, AES >= 3.40 have appl_getinfo(); it's just that
>AES < 3.99 don't support modes above 4.
Well you must have a different edition of the AC. In the copy I have it says
appl_getinfo is present from AES 4.00 and modes above 4 are only supported
on AES >= 4.1 (which makes sense as AES 4.0 doesn't have iconify etc.).
This is also confirmed by my copy of Modern Atari System Software which
says that appl_getinfo is available from AES 4.0 (and doesn't mention AES
4.1 at all, and doesn't mention modes above 4)
I didn't get a chance to check my compendium CD, but I expect this gives the
same.
>But since you can inquire the maximum
>mode number that's supported, this isn't a problem. You should really check
How? I couldn't see any way of doing this?
>for AES >= 3.40, then ask which functions are supported. If the functions
>to test for iconification aren't supported, you don't have iconification.
>Otherwise you do. No messing around with checking for version 4.0 and
>MagiC separately.
Um, well as mentioned above you DONT have appl_getinfo (acording to Atari
Compendium and MASS) < 4.0 so you STILL cannot test without the dirty
hack (sorry, but it is...)
Thomas Binder
Hi!
In article <3302E022...@doc.ic.ac.uk>,
"Alastair J. Houghton" <aj...@doc.ic.ac.uk> writes:
> According to my Compendium, AES >= 3.40 have appl_getinfo(); it's just
> that
> AES < 3.99 don't support modes above 4. But since you can inquire the
> maximum
> mode number that's supported, this isn't a problem. You should really
> check
> for AES >= 3.40, then ask which functions are supported.
The way I use to check for appl_getinfo() is the following:
if ((aes_version >= 0x340) || (appl_find("AGI?") >= 0))
{
< use appl_getinfo() with any mode and respect the return value - 0
means that the requested information is not available, 1 means OK >
}
Note that "AGI?" in the appl_find() is _not_ filled up to 8 characters, so
even if there was an application running with that name, it wouldn't be
found by that call. I don't know whether MagiC supports that "AGI?"-thing,
but at least WINX does, as it implements some appl_getinfo()-modes (but not
all, so it's _important_ to check for the return value of all calls to
appl_getinfo(), no matter what information was requested).
Thomas Much
TB>if ((aes_version >= 0x340) || (appl_find("AGI?") >= 0))
^^^^
The call is appl_find("?AGI")!
TB>I don't know whether MagiC supports that "AGI?"-thing
It does.
bye, Thomas
Mark Baines
>According to my Compendium, AES >= 3.40 have appl_getinfo(); it's just
types are available only. Types 4-14 are only available from AES 4.10.
However, Magic has an AES of 3.99 and it is available there, so you do need
to check for the presence of MagiC apart from AES version.
TAC gets this wrong in many places. On the whole where it refers to 3.40
substitute 4.00.
I have a whole list of TAC errors collated from around the UK which runs to
29K long.