X-FeedAbuse: http://nntpfeed.proxad.net/abuse.pl feeded by 82.66.60.35
Path: ...!news.mixmin.net!proxad.net!feeder1-2.proxad.net!nntpfeed.proxad.net!pasdenom.info!from-devjntp
Message-ID: <kR51FqGqfE5H1BW0akWMWP3RCKo@jntp>
JNTP-Route: news2.nemoweb.net
JNTP-DataType: Article
Subject: Re: Eureka sur la V4SA et MyAES
References: <o5tnYYMDH-muRDxHZCTz4nYWhKo@jntp> <3s3z71h5xjjUsUEm8LfMpojW7lM@jntp> <tjjble$ihs$1@gioia.aioe.org>
 <7AqwwCptJMXG0xtaTTjJx63Rk7g@jntp> <tjlees$1lnh$1@gioia.aioe.org> <ZMjTVq7UHu9E5cX5f8OSSMpF2YI@jntp>
 <tjm8qf$o5$1@gioia.aioe.org> <UEDU9fA9PW9HT4EPQmYslpbtp_Y@jntp> <12xU-l-FDpWnJCungvT8rV0J_n4@jntp>
 <tjmnp8$7ku$1@gioia.aioe.org>
Newsgroups: fr.comp.sys.atari
JNTP-HashClient: Fk6zCRFfSwlJ1FvRpKFKz2aNoyE
JNTP-ThreadID: uZZQ9xP_yLJwJTjTFMLosihSO4o
JNTP-Uri: http://news2.nemoweb.net/?DataID=kR51FqGqfE5H1BW0akWMWP3RCKo@jntp
User-Agent: Nemo/0.999a
JNTP-OriginServer: news2.nemoweb.net
Date: Sun, 30 Oct 22 21:02:10 +0000
Organization: Nemoweb
JNTP-Browser: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:105.0) Gecko/20100101 Firefox/105.0
Injection-Info: news2.nemoweb.net; posting-host="15889b1f102f2d47b8d3be27ea3bd7410e902c45"; logging-data="2022-10-30T21:02:10Z/7378094"; posting-account="69@news2.nemoweb.net"; mail-complaints-to="newsmaster@news2.nemoweb.net"
JNTP-ProtocolVersion: 0.21.1
JNTP-Server: PhpNemoServer/0.94.5
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-JNTP-JsonNewsGateway: 0.96
From: OL <ol.google@lutece.net>
Bytes: 4190
Lines: 43

Le 30/10/2022 à 21:45, Francois LE COAT a écrit :
> Salut,
> 
> OL écrit :
>>>> Le bug concerne bien EB_Dump, qui était inutilisable sous XaAES, et
>>>> non pas sous TOS4, parce que lorsqu'il effaçait sa dernière fenêtre
>>>> active, il perdait le focus, et il devenait impossible à rappeler.
>>>>
>>>> Ça a été corrigé dans XaAES, et le bug concernait à la fois EB_Dump
>>>> et Eurêka 2.12, qui se retrouve aussi parfois sans fenêtre active.
>>>> C'est un cas de "dead lock" c-à-d une situation inextricable ...
>>>
>>> J'ai partielle déjà corrigé le problème de focus, tout tourne 
>>> complètement normalement jusqu'à la fin de la démo, sauf quand je 
>>> reçois l'alert de Record pour me dire que c'est fini et là ce n'est 
>>> pas planté mais je n'ai plus l'acces aux click souris exactement comme 
>>> si j'étais toujours en wind_update(BEG_MCTRL), le menu ne répond plus 
>>> par contre Eureka reçois toujours le clavier la fenêtre apparaît qui 
>>> rappelle les possibilités clavier! Le BEG_MCTRL devrait être bani!
>> 
>> Comprends pas pas l'air d'être un BEG_MCTRL qui traine, tu n'as pas un 
>> rec tout petit pour tester rapidement, c'est long ta démo!
> 
> J'essaye de comprendre ce que tu me dis, mais c'est pas évident. Si il
> intervient un wind_update(BEG_MCTRL), c'est que l'on est dans l'écran
> d'affichage des courbes. Il me semble que si je bloque les interactions,
> c'est que je préserve l'écran d'affichage. Mais si il intervient un
> form_alert() de `RECORD.ACC` c'est que je ne dois plus être sur l'écran
> d'affichage des courbes. Il y a donc une contradiction. Je ne comprends
> pas. Ce que tu me dis me paraît être incohérent. Lorsque `RECORD.ACC`
> affiche ses form_alert(), c'est que le menu est affiché, et le bureau
> GEM est affiché. À moins que tu envoies une vidéo c'est incompréhensible
> 
> Je ne peux pas t'aider. Il faut que tu fasses au mieux, avec ce que tu
> comprends. Mais je ne suis pas à ta place. C'est toi qui est compétent.
> Tu peux essayer de voir ce que ça donne avec le TOS4, la référence qui
> fonctionne. Ça fonctionne aussi maintenant avec EmuTOS. Il faut que
> tu connaisses le résultat attendu, pour comprendre ce qui se passe.

Je connais le résultat attendu. Pas de problème avec BEG_MCTRL écarté, 
en fait cela n’apparaît pas sous V4 mais sous Aranym, c'est truc fou, 
un bug lié sans doute à la synchro des process, coton, je cherche.
As tu un .rec tout petit pour m'éviter de faire 5 minutes de tests à 
chaque fois?