From: Hoover, J. <Jac...@gr...> - 2015-04-14 02:06:20
|
I could create a named event, and use it to sync... But I fear I'm going way overboard for a "simple" fix. ________________________________ From: Sean Hall [r.s...@gm...] Sent: Monday, April 13, 2015 9:02 PM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] Issue 4512: WiX BA allows multiple clicks of Install button while update check is running It's close, but it needs to be able to prevent clicking on the Uninstall button and then the Repair button. Since the action doesn't even happen until after the update check, I'm not sure if the user should even be able to click Install/Uninstall/Repair until it's finished. On Mon, Apr 13, 2015 at 3:18 AM, Hoover, Jacob <Jac...@gr...<mailto:Jac...@gr...>> wrote: https://github.com/jchoover/wix3/tree/WIXBUG4512 This is a single shot relay command, where the user should not be able to mash the button multiple times for install, repair, uninstall. ________________________________ From: Hoover, Jacob [Jac...@gr...<mailto:Jac...@gr...>] Sent: Saturday, April 11, 2015 11:09 PM To: Windows Installer XML toolset developer mailing list Subject: [WiX-devs] Issue 4512: WiX BA allows multiple clicks of Install button while update check is running http://wixtoolset.org/issues/4512/ Technically any enabled button would allow multiple clicks between DetectBegin and DetectComplete. The question I have, is shouldn't any installation state info passed in DetectBegin also be passed in DetectComplete? I know in 3.x we can't modify the signature, but to me we shouldn't be proclaiming the overall bundle state until after detection is done. In 3.x, either I could introduce a new state indicator, DetectedAbsentInstalling, which would indicate the button was clicked, or a local member variable in the installation view model that would prevent the double invocation. Which ever pattern we favor, I think we should also apply it to the Repair and Uninstall commands. Even with the detected state not being "available" until DetectComplete, it's almost as if we need a OneShotRelayCommand class to only allow a single invocation, and if a user is able to abort out the OneShotRelay should be reset. Thoughts? Thanks, Jacob ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ WiX-devs mailing list WiX...@li...<mailto:WiX...@li...> https://lists.sourceforge.net/lists/listinfo/wix-devs |