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 opertngis 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?

charles wrote: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?

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 )

charles wrote: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".

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 manualsand -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, andmakes that handle available for reuse. Always close windows beforedeleting, or you may leave a "dead" picture on the screen. Also besure to delete all of your windows before ending the program, or yourapp 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 "

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.