Richard wrote:
> If its required, shouldn't WiX fail to build such a fragment then?
>
I overgeneralized; it's not required per se but the rules are such that
a simple compile-time check wouldn't be sufficient.
--
sig://boB
http://joyofsetup.com/
---
In article <[EMAIL PROTECTED]>,
Bob Arnson <[EMAIL PROTECTED]> writes:
> Sergey Abakumoff wrote:
> >
> > 1
>
> Control events need a condition. See the MSI SDK doc for ControlEvent.
If its required, shouldn't WiX fail to build such a fragment then?
--
"The Direct3D Graphi
Sergey Abakumoff wrote:
> Yep, it was my obvious fault.
> 1 should be
> used.
> Thank you and sorry for very long discussion around the very simple thing.
>
We've talked about having a warning if the condition is omitted -- or
even putting one in by default. Unfortunately, ControlEvent conditi
Yep, it was my obvious fault.
1 should be
used.
Thank you and sorry for very long discussion around the very simple thing.
Bob Arnson-6 wrote:
>
> Sergey Abakumoff wrote:
>>
>> 1
>>
>
> Control events need a condition. See the MSI SDK doc for ControlEvent.
>
> --
> sig://
Sergey Abakumoff wrote:
>
> 1
>
Control events need a condition. See the MSI SDK doc for ControlEvent.
--
sig://boB
http://joyofsetup.com/
-
This SF.Net email is sponsored by the Moblin Your Move Devel
Richard,
In the first post I mentioned that I use custom action. It was suggested in
the reply that set property event should be used and I started to use that:)
However, it didn't solve the problem as I mentioned.
Richard-45 wrote:
>
>
> In article <[EMAIL PROTECTED]>,
> Sergey Abakumoff
In article <[EMAIL PROTECTED]>,
Sergey Abakumoff <[EMAIL PROTECTED]> writes:
> Actually I use the set property events:
> Control Id="ProgramFilesBrowse" Type="PushButton" X="304" Y="70" Width="56"
> Height="17"
> Cancel="yes" Text="Browse...">
>
> 1
>
> an
Actually I use the set property events:
Control Id="ProgramFilesBrowse" Type="PushButton" X="304" Y="70" Width="56"
Height="17"
Cancel="yes" Text="Browse...">
1
and similar one for SamplesFolder...
Richard-45 wrote:
>
>
> In article <[EMAIL PROTECTED]>,
>
In article <[EMAIL PROTECTED]>,
Sergey Abakumoff <[EMAIL PROTECTED]> writes:
>
> BrowseDlg always shows SAMPLESDIR folder, it doesn't matter that button was
> clicked - ProgramFilesBrowse or SamplesBrowse.
> So it seems that _BrowseProperty always set to SAMPLESDIR and setting it to
> INST
BrowseDlg always shows SAMPLESDIR folder, it doesn't matter that button was
clicked - ProgramFilesBrowse or SamplesBrowse.
So it seems that _BrowseProperty always set to SAMPLESDIR and setting it to
INSTALLDIR in the custom action doesn't have any effect.
Bob Arnson-6 wrote:
>
> Sergey Abakumo
Sergey Abakumoff wrote:
> Unfortunately, this doesn't help..Does anyone have any other ideas?
>
Please explain how it doesn't work. Do you get an error message?
--
sig://boB
http://joyofsetup.com/
-
This SF.Net email i
Unfortunately, this doesn't help..Does anyone have any other ideas?
TIA
Richard-45 wrote:
>
>
> In article <[EMAIL PROTECTED]>,
> Sergey Abakumoff <[EMAIL PROTECTED]> writes:
>
>>
>>
>
> Try this instead:
>
>
>
>
> _BrowseProperty contains the name of t
In article <[EMAIL PROTECTED]>,
Sergey Abakumoff <[EMAIL PROTECTED]> writes:
>
>
Try this instead:
_BrowseProperty contains the name of the property that is to be set
with the path; you are setting _BrowseProperty to the contents of
INSTALLDIR and SAMPL
Richard-45 wrote:
>
>>>Don't use DoAction to change the property, use a property setting
>>>control event.
>
Even though I use property setting control event:
1
1
This doesn't work, browse dialog always shows SAMPLESDIR folder.
Any
In article <[EMAIL PROTECTED]>,
Sergey Abakumoff <[EMAIL PROTECTED]> writes:
> However, BrowseDlg always shows SAMPLESDIR folder, it doesn't matter that
> button was clicked - ProgramFilesBrowse or SamplesBrowse.
Don't use DoAction to change the property, use a property setting
control even
15 matches
Mail list logo