I've never heard of any issues like that.
On Thu, Sep 9, 2010 at 11:21 PM, Arockiarajesh Peter <
arajesh.pe...@yahoo.com> wrote:
> Thanks for your response.
> Incase, if my earlier installation fails and MSISERVER runs for next few
> minutes (this what i learnt msiserver runs even after installat
Thanks for your response.
Incase, if my earlier installation fails and MSISERVER runs for next few
minutes
(this what i learnt msiserver runs even after installation completion). Which
may create a problems if the user re-installs the same MSI. If i'm wrong please
correct my understanding
_
1. This is a question more suited for wix-users than wix-devs. Or, better
yet, it is a Windows Installer question more than a WiX one.
2. The MSISERVER service is used by the entire InstallExecuteSequence
sequence and Windows Installer already takes care to deal with two
scenarios:
a. It ensures
Why do you want to stop the Windows Installer when it is installing your
package?
On Thu, Sep 9, 2010 at 6:28 PM, softcoder wrote:
>
> I tried using
> 1. Wait='yes'/> THis takes a while and reports cant be done while
> installing.
> 2. I tried customaction like the one below.
> Valu
I tried using
1. THis takes a while and reports cant be done while
installing.
2. I tried customaction like the one below.
For this i get error, Error 1722.
Any help how do i stop the service before i start my installation? I ran
I definitely will. Getting a "WiX Standard Bootstrapper Application" built
is a task after the engine is functionality complete (after September). When
there is UI displaying, I'd love to get accessibility bugs. Historically,
we've punted all the UI bugs to Windows Installer, now we get to fix them
Hi Rob:
If you want me to look at accessibility, this would be something I’d be willing
to undertake, one I know what to look at *smile*
Regards
Sean.
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: 09 September 2010 18:38
To: Windows Installer XML toolset developer mailing list
Subject:
stdux.dll is designed for testing not typical use. It just shows progress
numbers in nice big font. There is no goal for it to work well with
accessibility until we get a developer working on Burn that requires
accessibility features.
I am working on a few presentations that introduce Burn. Parti
The UX used is supplied by the UX dll you supply when calling the burn tool,
and any/all windows used come from that dll. There is no default UX except
for the tool possibly (I haven't looked) using stdux if no ux is defined.
What receive message are you referring to?
From: Sean Farrow [mai
Hi:
I am assuming I am referring to theto receive message and has nothing to do
with the user interface.
How does one go about replacing the window shown when the executable is run?
Regards
Sean. latter, as I understand it, the former window is just used
From: Blair [mailto:os...@live.com]
Sent:
If you are referring to the window created by stdux, it is created in
src\burn\stdux\StandardUserExperience.cpp, in the
CStandardUserExperience::CreateMainWindow() method, at line 789 (from the
drop on September 6th).
If you are referring to the window used by WiX's own installer, it is
created
Hi:
Having downloaded the first build of v3.6 with Burn, I've found an issue where
by when using the built-in interface supplied with the executable this doesn't
work as well as it should with Access technology (screen readers and the like)
having looked at the source for the stdux dll I carn't
12 matches
Mail list logo
