Classification: Public
I use the Session Message, this is in C# I am not sure if you can use
Session... This will create a message box that is Modal to the MSI
catch (Exception ex)
{
WriteErrorLogInstall(session, "SomeMethod failed: ", ex, true);
// this is a method I
Our installer's logs show that it takes 3 minutes to create a restore point
before our software is installed, between the user
accepting the EULA and the UAC prompting the user for admin rights. The
computers we've tested aren't very old or underpowered
either.
The problem is that, for those 3 m
::MsiProcessMessage() will tell the Windows Installer to show the message
box which will get the correct Z-order. That's why it's *the right way*.
You can see some helper functions around ::MsiProcessMessage() in wcautil
that can make it easier to work with.
On Mon, Mar 25, 2013 at 1:05 PM, gapea
Basically, you're going to have to modify the source code in setupexe.cpp by
commenting out the lines that setup CONFIGURE_ACTION_REINSTALL and
CONFIGURE_ACTION_MINOR_UPGRADE and compile your own custom setup.exe.
--
John Merryweather Cooper
Build & Install Engineer - ESA
Jack Henry & Associates
Why is this *the right way*? Seems way more complicated - besides - how do I
do that in C++?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Any-ideas-on-how-to-solve-MessageBox-focus-can-be-lost-using-Custom-Action-DLL-tp7584319p7584612.html
Sent
Indeed. It automatically handles all the internal message states.
It's also right because the message will be routed to an external UI
handler (like Burn) and be done correctly.
Lots of things start working when done the right way.
On Mon, Mar 25, 2013 at 2:29 PM, Hoover, Jacob
wrote:
> And i
Does the resulting .wxs file have all the necessary registry keys? If so,
then you don't need the regsrv32 call, which is the self-reg call that
usually creates all the trouble.
On Mon, Mar 25, 2013 at 2:43 PM, gapearce wrote:
> Thanks Rob,
>
> I used a heat example I found in a thread here - l
Classification: Public
Oops sorry should have read the chain...
When calling MessageBox.Show(blah); it is not Modal to the MSI Using
session.Message(InstallMessage.User Blah); is modal to the MSI
This worked for me and solved MessageBox not being modal to the MSI so I am
happy with using this..
Now That's a better reason! Good point.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Any-ideas-on-how-to-solve-MessageBox-focus-can-be-lost-using-Custom-Action-DLL-tp7584319p7584621.html
Sent from the wix-users mailing list archive at Nabble.co
Thanks Rob,
I used a heat example I found in a thread here - like this:
"C:\Program Files (x86)\Windows Installer XML v3.5\bin\heat.exe" file
ShellExt.dll -ag -out file.wxs"
Should I not do that?
What do you mean to "Let the Windows Installer manage the registry keys for
you instead." - how doe
And it's the "right" way because session.Message shouldn't display a modal
dialog if you are running in a silent mode.
-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: Monday, March 25, 2013 3:43 PM
To: General discussion for Windows Installer XML toolset.
I'm surprised that no one has commented on this problem. Either is is such
an advanced question that no one has the answer, but it is such a stupid
question that the answer is obvious.
I'm going with the latter - that this must be the most stupid question asked
all day.
Well, I don't get it, a
Self-reg is a bad practice. Let the Windows Installer manage the registry
keys for you instead. Tends to work better in general.
On Mon, Mar 25, 2013 at 1:02 PM, gapearce wrote:
> I'm surprised that no one has commented on this problem. Either is is such
> an advanced question that no one has
I can't begin to count how many developers and architects have told me that
component order does matter because they broke the component rules and then
witnessed the "right" file get installed and how it "isn't" and therefore
the build/installer is broken. :(
-
In a nutshell, ICEs are specialized custom actions that serve as unit
tests. They are stored in specialized MSI databases called CUBs (.cub) (A
type that I wish that WiX had support for.) When you perform validation
the cub is merged with your MSI and all of the custom actions listed in the
Arguments, which was passed to installed product:
MSI (s) (FC:04) [04:30:37:911]: Command Line:
UPGRADINGPRODUCTCODE={66003867-727B-4475-8517-26CB95D2369A} CLIENTUILEVEL=3
REMOVE=ALL
Can I somehow add custom property to this autogenerated property list?
Regards, Alexey.
--
View this message
Hello,
We are generating the msi using wix. Then we are creating executable using
setbld.exe which internally calls the msi.
While installing, double clicking the msi and exe produce same set of dialog as
exe is basically calling msi so we can install using either of these two.
But when the app
When I build my .wixproj, everytime new log event was creating in the
EventViewer->Windows Logs->Aplication section. Apparently msiexec was
running.
Is there an explanation "why"?
Is this an ICE validation requirement?
Regards, Alexey.
--
View this message in context:
http://windows-installer
/>That is a really dangerous design, by the way. /
Yes, unfortunately I got this too late.
Thanks for reply, I read it, but it can not help in this case, cause I can
not change my fist version.
/>One possible hack is to schedule RemoveExistingProducts after
InstallExecute./
It`s a trick, but I ha
19 matches
Mail list logo
