Hi,

In this case, the problem is in the solution registry, where the command
GPII was looking for (to check if NVDA is running) is "nvda", not
"nvda.exe" [0].

The update window was a red herring, however it does raise the issue that
we should be disabling auto-updates for software we onboard, via
configuration. NVDA supports this. (This wouldn't disable auto-updates
completely, only when GPII starts the application).

[0]:
https://github.com/GPII/universal/blob/master/testData/solutions/win32.json5#L1669

Steve




On Sun, Jul 15, 2018 at 10:52 PM, Antranig Basman <
[email protected]> wrote:

> Cheers Gregg - I've written up this report as
> https://issues.gpii.net/browse/GPII-3208 .
> There has been a new behaviour implemented in the system recently
> (combination of Kaspar's last work and a new close handler from Steve
> Grundell) which is intended to handle this situation robustly. The workflow
> is -
> i) Send the application's window a standard quit message
> ii) If it has not responded to this after 15 seconds, kill the application
> forcibly
>
> So we do actually check whether things quit during the 15 second
> transition between i) and ii), and the method used in ii) should work
> immediately. However we should verify how recently the build you were
> testing was made, and whether it incorporates this behaviour, and if it is
> indeed sufficiently recently to include the new implementation, whether
> there is some special reason that NVDA might be unkillable in this
> condition.
>
> Cheers,
>
> Antranig
>
> On 15/07/2018 20:28, [email protected] wrote:
>
>> Hi All
>>
>> You may have discovered this already - and if so great.   But I think I
>> discovered this bug during my plenary presentation today.
>>
>> After pre-testing the auto-personalization a dozen times without problem
>> -  when I key’ed into NVDA on stage - it decided there was an update.
>>  When I tried to key out  — it keyed out but NVDA kept running  and talking.
>>
>> Evidently it doesn't quit when asked if it has an update dialog open.
>> I presume that GPII doesn't yet check to see if things quit  (does it?
>>  will it?)
>>
>> Once it doesn't quit — you can’t use GPII to turn it off of course -
>> because it is running when you key in— so it will be running after you key
>> out  (I presume)
>>
>> At any rate it ran for the rest of the keynote  (I muted it after I
>> thought of it).
>>
>> Is this something that is on the docket to get fixed?
>>
>> thanks
>>
>> Gregg
>>
>>
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://secure-web.cisco.com/14Z5rHZLMh8vTqJsJhZgazw6YHIqvBP
>> k4BLlEj7p5nsEJ0gXeXNfZIOCMa_fQTT07tdqyASBhky6104ErdZs9p5IJuk
>> QjaWskhg_Bb6cB4Rr0Wrl6pei60J5usBhNRNZPOrA-4_
>> FsTbpIRdZU6GSW9u-VD1Da9XrpcngeLYjO-BDGH1ncYXBXa8Pru3kw7A60hC
>> vXgmGyDV7IJOyQlpj5A2nFIcsFunlH3LlBvWqiN6RgI0VwPaVZSRyk9-ZZe5
>> UsSIAuu9hqq0p8idB9vvuGMZAQjabBAY5bS2A5WBth8CM-exDSaLY-yfUoKx
>> e0vgM-rU69zjWw76X1pW69tP9jdJx8Qkg-VFBesN6EbaNyIkjInjUbT-AP7p
>> e9bFgKl4rZX_WrHj5kGNhTB39LO9dLQ8S1Av3DJWKSoODgux9ikzjGp9xPeb
>> vbKdhzYEsJ3r83_vziaXSPUY583IPYpeUwfQ/https%3A%2F%2Flists.gpii.net%2Fmailm
>> an%2Flistinfo%2Farchitecture
>>
>>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://lists.gpii.net/mailman/listinfo/architecture
>
_______________________________________________
Architecture mailing list
[email protected]
https://lists.gpii.net/mailman/listinfo/architecture

Reply via email to