Showing a Message Box from a CA?
skankwilsonite
result of a "Next" button. Also for the "Next" button, I have a
"NewDialog" event attached to it, but after the CA. However, the
Message box does not show up. Here are my functions to display a
message (see below). I'm certain that GenMessageBox gets called,
because I put up a message box (via MessageBox user32 function) that
displayed "MYMSGTEXT", and the text was correct. Am I missing
something?
extern "C" UINT __stdcall GenMessageBox(MSIHANDLE hInstall)
{
CString strMsg;
DWORD dw = 1024;
UINT uiRet =
MsiGetProperty(hInstall,"MYMSGTEXT",strMsg.GetBuffer(1024),&dw);
strMsg.ReleaseBuffer(); // reclaim the buffer after the GetBuffer()
call.
if( ERROR_SUCCESS!
=MsiMessageBox(hInstall,strMsg,MB_ICONINFORMATION) ) {
MessageBox(GetActiveWindow(),"MsiMessageBox failed.","Test",0);
}
return ERROR_SUCCESS;
}
UINT MsiMessageBox(MSIHANDLE hInstall,LPCSTR pszMsg,DWORD dwOptions)
{
if( NULL==hInstall || NULL==pszMsg ) return -1;
PMSIHANDLE hRec = MsiCreateRecord(2);
MsiRecordSetString(hRec,0,pszMsg);
UINT uiRet =
MsiProcessMessage(hInstall,INSTALLMESSAGE(INSTALLMESSAGE_USER |
dwOptions),hRec);
return uiRet;
- Hide quoted text -
}
![Richard [Microsoft Windows Installer MVP]'s profile photo](https://lh3.googleusercontent.com/a/default-user=s40-c)
Richard [Microsoft Windows Installer MVP]
"skankwilsonite" <skankwi...@gmail.com> spake the secret code
<1170350431.1...@s48g2000cws.googlegroups.com> thusly:
>I have a CA that displays a message box. [...]
Instead of using MessageBox, use MsiProcessMessage to display a
message box. This even works from deferred CAs...
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
skankwilsonite
have a GenMessageBox function that is my CA. It then calls my
MsiMessageBox function that I wrote, that then calls
MsiProcessMessage. I have gotten message boxes to show up before, but
for some reason when I invoke my CA as a result of a "Next" button,
which also publishes a NewDialog event from it, the NewDialog happens,
as well as my CA (from looking at the log)...but the call to
MsiMessageBox does not show up. Additionally, no errors are returned.
On Feb 1, 1:29 pm, legalize+jee...@mail.xmission.com (Richard
[Microsoft Windows Installer MVP]) wrote:
> [Please do not mail me a copy of your followup]
>
> "skankwilsonite" <skankwilson...@gmail.com> spake the secret code
> <1170350431.114145.210...@s48g2000cws.googlegroups.com> thusly:
Richard [Microsoft Windows Installer MVP]
"skankwilsonite" <skankwi...@gmail.com> spake the secret code
<1170390551.2...@a34g2000cwb.googlegroups.com> thusly:
>This is in fact what I am doing. In the code from my original post, I
>have a GenMessageBox function that is my CA. It then calls my
>MsiMessageBox function that I wrote, that then calls
>MsiProcessMessage. I have gotten message boxes to show up before, but
>for some reason when I invoke my CA as a result of a "Next" button,
>which also publishes a NewDialog event from it, the NewDialog happens,
Ah, yes. Don't ask me why, but MsiProcessMessage won't show a message
box when you call it from a custom action invoked from a control
event. Even more frustrating is that MsiProcessMessage doesn't write
to the log when you call it in a similar situation.
What I did to work around this was to create a message dialog that
displayed a property. When I want to do a messagebox type thing, I
NewDialog on the dialog as a control event with a condition controlled
by the code that wants to display the message box. Kinda horky, but
it does work without me making windows outside the context of MSI.
I can provide more details if you need them.
Richard [Microsoft Windows Installer MVP]
(Richard) legaliz...@mail.xmission.com spake the secret code
<ep1YOVoR...@TK2MSFTNGP06.phx.gbl> thusly:
>[...] When I want to do a messagebox type thing, I
>NewDialog on the dialog as a control event [...]
Oops, I think it should be SpawnDialog for a modal dialog whose parent
is the dialog containing the control containing the SpawnDialog event.
Stephen Connolly
processmessage from a controlevent if your CA is in VBS, but not if
it's a DLL\C++ CA. No idea why, but it's true.
skankwilsonite
to publish one NewDialog or one SpawnDialog per control event. And
since I want to both:
a.) Display a warning message
b.) NewDialog to the next dialog in the sequence
When my warning dialog was displayed and "OK" was selected, control
returned to the parent dialog, and my NewDialog for the next page did
not happen. Please let me know if I'm not giving enough detail, but
do you see my dilemma? Could you give more details about the approach
you were proposing? BTW, I'm using WiX to do this, but it shouldn't
make a difference. I figured this was more of a Windows Installer
issue.
On Feb 1, 11:47 pm, legalize+jee...@mail.xmission.com (Richard
[Microsoft Windows Installer MVP]) wrote:
> [Please do not mail me a copy of your followup]
>
> "skankwilsonite" <skankwilson...@gmail.com> spake the secret code
> <1170390551.243445.133...@a34g2000cwb.googlegroups.com> thusly:
mgama
On my Welcome screen, when the user clicks next, I have an Control Event to
SpawnDialog a "LowMemory" dialog warning the user they have less than the
recommended amount of memory. Then after that (using the Ordering column in
the ControlEvent table) I have a NewDialog event which will bring the user
to the next dialog in the wizard.
ControlEvent table:
Welcome, Next, SpawnDialog, LowMemoryDlg, (PhysicalMemory < 64), 1
Welcome, Next, NewDialog, InstallationPathDlg, , 2
If your warning is triggered by the results of a custom action (such as
checking for a database), then either run the custom action earlier in the
InstallUISequence, or add it as another ControlEvent for the Next button
with an Ordering of 1 (and bump the other events Ordering to 2 and 3), then
have your warning Dialog conditioned off a property that your custom action
will either set or clear if the user fixes whatever warning they had.
Example:
ControlEvent table:
Welcome, Next, DoAction, CA_CheckForDB, , 1
Welcome, Next, SpawnDialog, WarngingDBFoundDlg, DBFOUND=1 , 2
Welcome, Next, NewDialog, InstallationPathDlg, , 3
The OK button on your warning dialog should have a ControlEvent of
EndDialog - Return. Example:
LowMemoryDlg, OKButton, EndDialog, Return, 1, 1
Mike
"skankwilsonite" <skankwi...@gmail.com> wrote in message
news:1170770140.2...@a75g2000cwd.googlegroups.com...
Richard [Microsoft Windows Installer MVP]
"skankwilsonite" <skankwi...@gmail.com> spake the secret code
<1170770140.2...@a75g2000cwd.googlegroups.com> thusly:
>The problem that I had with THAT approach was that you're only allowed
>to publish one NewDialog or one SpawnDialog per control event.
I think you mean "per control", but yes I understand what you mean.
If you attempt to put mulitple NewDialog or SpawnDialog events, then
things get wiggy.
However, since the name of the dialog to be spawned is a Formatted
column, then you can parameterize out the name of the dialog into a
property and use set property control events to set the name of the
dialog depending on the different conditions. We use this in an
install I've worked on to manage complex next/back wizard sequences
with lots of branching. The paradigm goes like this:
MyDlg Next [MyErrorMessage] {} 1 1
MyDlg Next [MyErrorMessage] MyErrorMessage1 ErrorCondition1 2
MyDlg Next [MyErrorMessage] MyErrorMessage2 ErrorCondition2 3
MyDlg Next [MyErrorMessage] MyErrorMessage3 ErrorCondition3 4
MyDlg Next [MyDlg_Next] {} 1 5
MyDlg Next [MyDlg_Next] NextDialog1 NextCondition1 6
MyDlg Next [MyDlg_Next] NextDialog2 NextCondition2 7
MyDlg Next [MyDlg_Next] NextDialog3 NextCondition3 8
MyDlg Next SpawnDialog MyErrorDialog MyErrorMessage 9
MyDlg Next NextDialog [MyDlg_Next] NOT MyErrorMessage 10
This displays a modal error dialog when any of the error conditions
are true and doesn't advance to the next dialog in the sequence when
an error occurs.
>And
>since I want to both:
>
>a.) Display a warning message
>b.) NewDialog to the next dialog in the sequence
Your situation is similar to the above. In your case, make the
warning dialog a regular dialog in the wizard sequence that is skipped
when the warning condition is false. So use the MyDlg_Next part of
the above paradigm but skip the modal dialog portion of the error
handling above.
You're essentially saying "if some condition is true, then display the
warning dialog before moving onto the next dialog in the sequence,
otherwise just display the next dialog in the sequence". This is a
conditional branch:
Dialog1 ---+-------> Warning Dialog ----------> Dialog 2
| ^
+-----------------------------+
skankwilsonite
SelectServerDlg,Next,[InfoDlgText],Hey, I'm warning you.,1,1
SelectServerDlg,Next,SpawnDialog,InfoDlg,NOT PwdAlreadyWarned AND
USELOCAL,2
SelectServerDlg,Next,[PwdAlreadyWarned],1,USELOCAL,3
SelectServerDlg,Next,NewDialog,VerifyReadyDlg,1,4
But the InfoDlg is never displayed. If I remove the NewDialog event,
the InfoDlg is displayed (but obviously I can't proceed). And yes, my
InfoDlg has a EndDialog,Return,1,1 in the ControlEvent table.
> "skankwilsonite" <skankwilson...@gmail.com> wrote in message
>
> news:1170770140.2...@a75g2000cwd.googlegroups.com...
>
> > The problem that I had with THAT approach was that you're only allowed
> > to publish one NewDialog or one SpawnDialog per control event. And
> > since I want to both:
>
> > a.) Display a warning message
> > b.) NewDialog to the next dialog in the sequence
>
> > When my warning dialog was displayed and "OK" was selected, control
> > returned to the parent dialog, and my NewDialog for the next page did
> > not happen. Please let me know if I'm not giving enough detail, but
> > do you see my dilemma? Could you give more details about the approach
> > you were proposing? BTW, I'm using WiX to do this, but it shouldn't
> > make a difference. I figured this was more of a Windows Installer
> > issue.
>
> > On Feb 1, 11:47 pm, legalize+jee...@mail.xmission.com (Richard
> > [Microsoft Windows Installer MVP]) wrote:
> >> [Please do not mail me a copy of your followup]
>
> >> "skankwilsonite" <skankwilson...@gmail.com> spake the secret code
> >> <1170390551.243445.133...@a34g2000cwb.googlegroups.com> thusly:
>
> >> >This is in fact what I am doing. In the code from my original post, I
> >> >have a GenMessageBox function that is my CA. It then calls my
> >> >MsiMessageBox function that I wrote, that then calls
> >> >MsiProcessMessage. I have gotten message boxes to show up before, but
> >> >for some reason when I invoke my CA as a result of a "Next" button,
> >> >which also publishes a NewDialog event from it, the NewDialog happens,
>
> >> Ah, yes. Don't ask me why, but MsiProcessMessage won't show amessage>> boxwhen you call it from a custom action invoked from a control
> >> event. Even more frustrating is that MsiProcessMessage doesn't write
> >> to the log when you call it in a similar situation.
>
> >> What I did to work around this was to create a message dialog that
> >> displayed a property. When I want to do a messagebox type thing, I
> >> NewDialog on the dialog as a control event with a condition controlled
> >> by the code that wants to display themessage box. Kinda horky, but
mgama
behavior wasn't exactly as I remembered it. Perhaps the behavior has
changed over various versions of Windows Installer. After displaying the
warning dialog, the final NewDialog event wasn't happening. It requires the
user to click Next again, which this time will skip the SpawnDialog warning
message because it is now conditioned out. I don't recall that being the
case, but it has been a couple years since I implemented that feature of the
setup. Hopefully you can live with that behavior.
After attempting to add your extra event where you set the InfoDlgText, it
broke. I had to condition the event where it sets the InfoDlgText to only
happen once. Here is my attempt at achieving what you are after, mixed with
my low-memory dialog, and it seems to work. I was a bit concerned about
your InfoDlgText and PwdAlreadyWarned properties being mixed case (thus
private properties), but it worked fine:
ControlEvent table:
Welcome, Next, [InfoDlgText], Hey you!!!!, PwdAlreadyWarned<>1, 1
Welcome, Next, SpawnDialog, LowMemoryDlg, (PhysicalMemory < 64) AND
(PwdAlreadyWarned<>1), 2
Welcome, Next, NewDialog, InstallationPathDlg, , 3
LowMemoryDlg, OKButton, [PwdAlreadyWarned], 1, 1, 1
LowMemoryDlg, OKButton, EndDialog, Return, 1, 2
Mike
"skankwilsonite" <skankwi...@gmail.com> wrote in message
news:1170946252.4...@m58g2000cwm.googlegroups.com...
Richard [Microsoft Windows Installer MVP]
"skankwilsonite" <skankwi...@gmail.com> spake the secret code
<1170946252.4...@m58g2000cwm.googlegroups.com> thusly:
>I tried this:
>
>SelectServerDlg,Next,[InfoDlgText],Hey, I'm warning you.,1,1
>SelectServerDlg,Next,SpawnDialog,InfoDlg,NOT PwdAlreadyWarned AND
>USELOCAL,2
>SelectServerDlg,Next,[PwdAlreadyWarned],1,USELOCAL,3
>SelectServerDlg,Next,NewDialog,VerifyReadyDlg,1,4
>
>But the InfoDlg is never displayed. If I remove the NewDialog event,
>the InfoDlg is displayed (but obviously I can't proceed). And yes, my
>InfoDlg has a EndDialog,Return,1,1 in the ControlEvent table.
That's because the condition on your NewDialog is '1', so it always
does that. As I say if you want this to be part of the sequence, then
you should do that branching technique using NewDialog.
pob...@gmail.com
[Microsoft Windows Installer MVP]) wrote:
>
Hi,
I'm new here from Hungary, I have the same problem.
I think what skankwilsonite means is the following:
i.e.
I click Next in my LicenseAgreementDlg, then I would like to see an
infodialog
with any info text, then if I click Ok (Event EndDialog Value Return)
in infodialog,
I want to see the next dialog automatically (for example
CustomizeDlg)
But I can do it if I click Next in LicenseAgreementDlg again.
Regards,
pobox77
Richard [Microsoft Windows Installer MVP]
pob...@gmail.com spake the secret code
<1172239571.7...@k78g2000cwa.googlegroups.com> thusly:
>I'm new here from Hungary, I have the same problem.
>I think what skankwilsonite means is the following:
>i.e.
>I click Next in my LicenseAgreementDlg, then I would like to see an
>infodialog
>with any info text, then if I click Ok (Event EndDialog Value Return)
>in infodialog,
>I want to see the next dialog automatically (for example
>CustomizeDlg)
Yes, you can do this, but you can't get this behavior with
SpawnDialog, you have to use NewDialog.
alan
Rich, do you have (or can you recommend) a programmatic way of setting
up the tables for complex dialog sequences, or is it a one-time
hand-coding job?
Richard [Microsoft Windows Installer MVP]
alan <al...@deterministicnospamnetworks.com> spake the secret code
<45DF32BA...@deterministicnospamnetworks.com> thusly:
>Rich, do you have (or can you recommend) a programmatic way of setting
>up the tables for complex dialog sequences, or is it a one-time
>hand-coding job?
You can do it programmatically, which is what I would expect happens
when you have a GUI tool that lets you define the transitions between
dialogs.
However, even a tool like InstallShield X doesn't do this. They just
dump you into the tables most of the time. In fact, their attempts to
simplify things, just make things worse and its far easier to get the
job done in Orca by editing the tables.
We introduced naming conventions for the properties that contain the
name of the dialog that will be displayed next and wrote ICEs to
validate the control events. This was very handy for catching things
like typos in the property names, that all the dialog transitions were
well-defined, and that in next/back sequences each dialog that could
be reached by a next button had a back button that could take you to
the previous dialog.
The ICEs that ship with the SDK check basic things, but I found that
writing my own ICEs that had a knowledge of my naming convention for
properties and what-not made things much more reliable as simple
errors were caught in validation and not through complex testing.
The product I worked on was complex with a large number of dialogs and
complex conditions that take you from one dialog to the next. It is
localized in 8 languages, installs COM objects, .NET assemblies, NT
services, lots of files, and has lots of custom actions. The larger
and more complex the install, the more you need to write ICEs to
validate your own specific application requirements.