1. There are a number of magical properties in the wixstdba that need to be
documented. I'm open to suggestions where the content should go in the
documentation. Adding a new page may make sense to *start* capturing the
properties. It's like the "Burn Built-in Variables" page. Once I created
the page, it was easier for people to maintain. Maybe do the same here.
Anyway, I'm leaning that way... otherwise we'll end up with a huge
WixStandardBootstrapperApplication element with all these dials and knobs.
However, going this path may mean we need to make it easier for users to
find .thm files and to provide their own. Thoughts?
2. Ahh, I really, really like that. Probably should change the WiX BA to do
as you describe to clean it up a bit, eh? I'm not sold on the adjectives
yet "text" and "data" but I don't have great ideas for alternatives.
3. Before pushing, can you verify that you have an assignment agreement
with Outercurve first? Code can't go anywhere until that is in place. If
not, it's an easy form for me to get started for you.
On Mon, Feb 18, 2013 at 9:57 AM, Hoover, Jacob
<[email protected]>wrote:
> Exactly why I was asking, but it has to be a conscious decision to allow
> adding of a named control in the BA theme to turn on behavior. On the down
> side, if there isn’t a schema modification how would I get this mystery
> behavior documented? Would the documentation best fit into “Changing the
> WiX Standard Bootstrapper Application Branding”?****
>
> ** **
>
> As for Text vs Data, Text is only the INSTALLMESSAGE_ACTIONSTART and data
> is everything. By everything a good example would be during CopyFiles
> you’d see every file but for Text you’d just see that we started to copy
> files.****
>
> ** **
>
> In the case of the WixBA, the following code looks like Wix shows “Data”**
> **
>
> ** **
>
> ProgressViewModel.cs:****
>
> ** **
>
> private void ExecuteMsiMessage(object sender,
> ExecuteMsiMessageEventArgs e)****
>
> {****
>
> lock (this)****
>
> {****
>
> this.Message = e.Message;****
>
> e.Result = this.root.Canceled ? Result.Cancel : Result.Ok;
> ****
>
> }****
>
> }****
>
> ** **
>
> If you wanted it to be “Text” you could make the change as:****
>
> ** **
>
> private void ExecuteMsiMessage(object sender,
> ExecuteMsiMessageEventArgs e)****
>
> {****
>
> lock (this)****
>
> {****
>
> If (InstallMessage.ActionStart == e.MessageType)****
>
> {****
>
> this.Message = e.Message;****
>
> }****
>
> e.Result = this.root.Canceled ? Result.Cancel : Result.Ok;**
> **
>
> }****
>
> }****
>
> ** **
>
> ** **
>
> ** **
>
> If you are ok with it, I’ll do some cleanup to remove the schema changes
> and then update my fork and submit a pull request.****
>
> ** **
>
> *From:* Rob Mensching [mailto:[email protected]]
> *Sent:* Monday, February 18, 2013 11:31 AM
>
> *To:* Windows Installer XML toolset developer mailing list
> *Subject:* Re: [WiX-devs] WixStdBA: New feature development****
>
> ** **
>
> 1. Is this necessary? What if we always set the value into the control and
> the owner of the theme can control whether it shows up? That saves us one
> more "bit" of data (I'm mostly thinking complexity exposed to user).****
>
> 2. Cool. This is what makes me wonder if #1 is necessary.****
>
> ****
>
> Overall, seems reasonable. One new question:****
>
> ****
>
> 3. What is difference between "text" and "data". What do those end up
> showing in the UI like?****
>
> ****
>
> ****
>
> On Mon, Jan 21, 2013 at 6:28 AM, Hoover, Jacob <[email protected]>
> wrote:****
>
> 1. I added WixStandardBootstrapperApplication/@EnableActionMessage
> with a new custom type having values of none, text, data. BalCompiler had
> to be modified to read this data and populate an additional column in the
> table for the BA to consume. ****
>
> ****
>
> 2. Logic inside of OnExecuteBegin will set the same options based
> on the existence of the two named controls.
>
------------------------------------------------------------------------------
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
is your hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials, tech docs,
whitepapers, evaluation guides, and opinion stories. Check out the most
recent posts - join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
WiX-devs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wix-devs
