Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Showing a dialogue only once

0 views
Skip to first unread message

Rob

unread,
Oct 10, 2006, 9:51:02 PM10/10/06
to
This question would probably be best answered by someone who's familiar
with Wise for Windows Installer, as that's what I'm developing my install
with, and the problem concerns a wizard navigation method (Wise Next
Dialog) that WfWI implements in installs developed using it.

I have a dialogue in my install that is shown in the event that the install
is upgrading from a previous non-MSI-based install. It gives the user some
information regarding the nature of the install, which does not really need
to be seen more than once, so I only want to show this dialogue once no
matter how much the user clicks Next and Back in the dialogues. To do this,
I have both the Next and Back buttons in that dialogue set a property
before going to the next or previous dialogue. One of the sub-conditions of
that dialogue showing up is that that property is NOT set. (All of the sub-
conditions are ANDed together.) The intent of this is that the dialogue is
not to be seen again once the user leaves it in either direction. However,
if, while running or testing the install, I click Next to go to the next
dialogue and then Back in the next dialogue, I still see the dialogue. It's
only when I click Back in this dialogue and Next in the one before it that
this dialogue starts getting skipped as intended. What's the best way to
get this to work as intended?

Richard [Microsoft Windows Installer MVP]

unread,
Oct 10, 2006, 10:04:18 PM10/10/06
to
[Please do not mail me a copy of your followup]

Rob <luw...@email.com> spake the secret code
<Xns9858BFC26D6...@199.185.223.74> thusly:

>[...]


>only when I click Back in this dialogue and Next in the one before it that
>this dialogue starts getting skipped as intended. What's the best way to
>get this to work as intended?

Based on what you describe it sounds like the property is only being
set on the control events for the back button on this dialog.

The control event model in MSI is tied to particular controls, but not
to a dialog. So if you want to do things like "do this code when this
dialog first displays or when leaving the dialog", you have to put
that code on all controls that can lead to/from the dialog. It sounds
like you have it handled for one of the controls that leads to/from
this dialog, but not on the other controls (i.e., the Next button).
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>

chrpai

unread,
Oct 11, 2006, 10:59:31 AM10/11/06
to
I'm not sure I like this user interview story, but if this is what you
want:

Create a property such as DialogShown and have it initialized as null.
Then in the back and next button of the dialog, wire up a control
event that sets DialogShown to 1.

Now for the pre and post dialog wire up control events that look like
this

PreDialog | Next Control Event ( Action, Argument, Condition )
NewDialog ShowOnceDialog Not DialogShown
NewDialog PostDialog DialogShown

ShowOnceDialog | Back Control Event
[DialogShown] Yes 1
NewDialog PreDialog 1

ShowOnceDialog | Next Control Event
[DialogShown] Yes 1
NewDialog PostDialog 1

PostDialog | Back Control Event
NewDialog PreDialog 1

Note: The mutex is not needed on the post dialog since you must have
gone through the show once dialog in order to get to the post dialog.

Rob

unread,
Oct 11, 2006, 1:23:37 PM10/11/06
to
legaliz...@mail.xmission.com (Richard [Microsoft Windows Installer
MVP]) wrote in news:e94gQmN7...@TK2MSFTNGP03.phx.gbl:

> Based on what you describe it sounds like the property is only being
> set on the control events for the back button on this dialog.
>
> The control event model in MSI is tied to particular controls, but not
> to a dialog. So if you want to do things like "do this code when this
> dialog first displays or when leaving the dialog", you have to put
> that code on all controls that can lead to/from the dialog. It sounds
> like you have it handled for one of the controls that leads to/from
> this dialog, but not on the other controls (i.e., the Next button).

That's just it. I put control events on both the Back and the Next buttons
to set the property, but it only works if I go back first.

I'm wondering if the Wise Next Dialog event saves an internal list of the
dialogues that have been visited in the forward direction and just uses
that list, ignoring the dialogues' conditions, when reversing through the
sequence. If anyone who's familiar with Wise for Windows Installer can
answer that one, it would be a great help. (Even better if you can suggest
a work around.)

Richard [Microsoft Windows Installer MVP]

unread,
Oct 11, 2006, 1:38:31 PM10/11/06
to
[Please do not mail me a copy of your followup]

Rob <luw...@email.com> spake the secret code

<Xns985969BBA1E...@199.185.223.78> thusly:

>
>legaliz...@mail.xmission.com (Richard [Microsoft Windows Installer
>MVP]) wrote in news:e94gQmN7...@TK2MSFTNGP03.phx.gbl:
>
>> Based on what you describe it sounds like the property is only being
>> set on the control events for the back button on this dialog.
>>
>> The control event model in MSI is tied to particular controls, but not
>> to a dialog. So if you want to do things like "do this code when this
>> dialog first displays or when leaving the dialog", you have to put
>> that code on all controls that can lead to/from the dialog. It sounds
>> like you have it handled for one of the controls that leads to/from
>> this dialog, but not on the other controls (i.e., the Next button).
>
>That's just it. I put control events on both the Back and the Next buttons
>to set the property, but it only works if I go back first.

Well, without debugging your MSI for you, I can't tell you what's
wrong. Open it up in Orca and examine your ControlEvent table
carefully.

chrpai

unread,
Oct 11, 2006, 11:00:51 PM10/11/06
to
Keep in mind that control events have an order. It's possible that
your DoAction control event is fired before the [Property] control
event ever has a chance to fire.

0 new messages