windows on a multi task machine vs single task

[charles]

so im reacquainting myself to the gem windows call...
over the years ive managed to brutalize some code to use a window if I needed one and then just hard coded some command when the program finished to clean up the rendered window .
if not multitask compliant then it didn't matter ,
but now ive furthered refined my insight into how gem handles windows
and have a curiosity as to a couple areas.

first question is this senerio ......if I write an accessory and it uses windows while the program im currently opertng
is also using a couple windows....... whats the correct way to close out the accessories windows on termination?

additionally what would happen if I use a true multi tasking Atari with couple diff programs active and I begin opening windows at random amongst the multitude of programs ???
does this have any outcome on the handles gem assigns? or the windows id ?for each window opened ........?

is it an acculmlative number for handles among all programs or is it internally assigned per ap- instance?

[ThorstenOtto]

whats the correct way to close out the accessories windows on termination?

In SingleTOS, you will receive an AC_CLOSE message. When you get this, the window has already been deleted by AES, so you must make sure you don't use that handle anymore (especially, you must not call wind_close and/or wind_delete), When you receive a WM_CLOSE message, you can react just like in a regular app.

does this have any outcome on the handles gem assigns? or the windows id ?for each window opened ........?

You just should not make *any* assumptions about the window handle (except that it won't be negative or zero)

is it an acculmlative number for handles among all programs or is it internally assigned per ap- instance?

It is a unique number among all running applications.

[charles]

Thorsten I thank you for your answer
ive got one more
in a multi task senerio ,, multiple windows , multiple programs...
does the closing/deleting of a window in a "lower archy" program , cause the entire following windows handle # to shift down (does gem automatically resituate/reassisgn since one of the handles has been deleted )

maybe these actions ive mentioned are never occurring ????

[wongck]

does the closing/deleting of a window in a "lower archy" program , cause the entire following windows handle # to shift down (does gem automatically resituate/reassisgn since one of the handles has been deleted )

Charles, you must be kidding me. SMFH.
If it did, it would be bloody pain wouldn't it?
At least not as bad as "your mouse moved, please reboot to continue".

[charles]

cold boot or warm boot ?

[wongck]

such a simple program, does not matter which, but stretching the arm will works wonders after a long session of coding. so best cold reboot.

[charles]

btw wongck , do u have any of your software on the forum ?

[wongck]

No, AFAIK none of my software are on the forum. They are located elsewhere.

[charles]

any specialties or rarities , source?
so I can adopt some knacks?
you mainily do c if I remember.......

[wongck]

nothing special... lifted the C code for windowing straight out of here.
It's in C, any use for you?

[charles]

wongck= it is now that im more fluent in deciphering c than I have been in the past ,
as for my citations ive been using an assortment of books
-vdi ref and gem ref computes guide
-Atari compendium v1
-gfa manuals
and
-that resource from gfa v2 windows demo
(which is pretty much a gfa v3 demo now that I have it about 95.9 transferred to the new 3.5> gfatt)

tim orens:
ive been reading it last week and this week , and this is why I asked if on a multi task environment with multiple windows opened if closing a lower archy window then checking the currentily opened handles would they shift down

Deleting the window removes its definition from the system, and
makes that handle available for reuse. Always close windows before
deleting, or you may leave a "dead" picture on the screen. Also be
sure to delete all of your windows before ending the program, or your
app may "eat" window handles. The syntax for deleting a window is:
wind_delete(handle);

but from the response ii don't believe they do but cant check no multi tasking Atari present ,, time for a disclaimer my programs may possibly not function properily on a multitasking Atari "

[wongck]

it works the same as any ACC and your program in single TOS.... well it works with what i had from Tim's code anyway.
ACC also opens a window (for example the SpiritEd)... so now you have 2 window program running.

So Atari is Multitasking already... even since I got mine back in the 80s

I have no idea how AES handles and keep track of available window resources, but it is good practice to return stuff you borrow from the OS.
If you don't return, it just others have less to use.

[mfro]

The AES do not shift around window handles. Once you got a valid one, you can trust it doesn't change during program lifetime (unless you change it yourself).

If this is what you were asking for.

[charles]

even in a multi task environment ..ok ill trust it don't : )