Changing images at runtime on installer using WIX - installation

I am using WIX installer to develop installer.
I want to enhance the installer in terms of UI. I want to change the images at run-time on the same screen (not like billboard) like below
I have fixed 5 features. So there will be no scroll bar and all. I just want to show the current feature being installed and if any error occurs for particular feature red error icon should be displayed.
Is this possible using WIX

You could probably put stack various images on top of each other and set the hide/show conditions based upon some kind of properties that says if the feature is installed/installing/errored
I'm not sure about doing this dynamically such that you could only have to code it for one feature and then it would apply to all features.
Seeings as you only have five features its probably easy to duplicate the code a few times but obviously this isn't a good idea in the long run in terms of maintainability
EDIT: you might be able to design a T4 template that would generate such a UI for you automatically, in this case the code essentially would still be duplicated but it would only exist once in the T4
See WiX tricks and tips for more on T4 generation

Related

building kendo ui with gulp

I am attempting to integrate kendo into my site, and one of the processes I need to do is to build it with gulp.js. I notice that kendo already has grunt.js support, but that isn't what I am using; I tried to reverse engineer its own gruntfile.js to figure out the right way to do this, but have met with nothing but failure.
In general, the main thing I cannot figure out is the order to assemble the files in. I simply cannot find this anywhere. There are so many, I only know that kendo.core.js needs to be first. Is there a list somewhere of the correct order to put all of the other kendo.*.js files in to get the same result as kendo.all.js that I would get from the CDN?
References:
kendo ui gruntfile.js
Try in the order they're listed in here (the complex widgets that are part of commercial and not listed there, e.g. the grid, should go last).

VSCT: Different icons for different VS versions

I am making an extension for both VS2010 and VS2012 that has a toolbar command.
Given the change in icon style between them, I want to provide a separate icon for each.
How do I specify that in .vsct? I assume I might be able to use Condition, but I am not sure if there is already a pre-defined value with VS version.
It seems it is not possible without using an MSI, see "VS Package (VSIX): Having two different toolbar icons for VS2010/VS2012" on MSDN forums.
Ryan Molden (MSFT):
I do not believe you can use VSIX to install or specify target specific resources. VSIX is intended as a very simplistic deployment mechanism, it is in fact just a renamed ZIP file plus an installer with a small amount of logic to process pkgdef files. If you want more complex installs (like laying down different dlls based on your install target) I believe you would need to create an MSI.

Windows Phone: Targets, Branding

i have an app that will be shipped by different providers. So i need to exchange the backgrounds etc, ss there is probably some kind of unique identifier for each app i also need different projects for that. What's the best practice to do this on windows phone ? Do i have to write own "Wrapper"-Projects ? (In iOS there is a concept called targets where i just link relevant branding files, appname, identifiers etc)
Thanks for your help !
In XAML, you can use Styling and Templating to dynamically change the whole look and feel of your application.
The same principal applies to Windows Phone apps as well. Then all you got to do is, maintain different style xaml files and apply them to create unique builds, or once the application launches.
Update: As willmel suggests below, which I forgot to mention, localization techniques mentioned here are a great way to maintain application strings.
Update 2: You can package your 'themes' into separate ZIP files, as demonstrated here and use post build events and VS commands to create different packages. You can always call msbuild from the command line as well and customize your build process even further. You can use different manifests this way as well.
If you have provider information which is language specified, you can download a sample project here:
http://www.pocketpc.ch/windows-phone-7-entwicklung/158405-textbox-string-integer.html#post1381376
or another here, or in VB
Once, you know the provider, you can select your resource file.
That article from Tim Heuer can show how you can work with less work for different situations like used in XCode iOS. Additional to strings you can use image URL as well.

Best way to work with multiple projects / solutions in Visual Studio?

Currently I have 4 solutions that are independent projects, however there is quite a bit of duplicated code when it comes to a few areas of the applications.
At the moment it is simply a few forms and their associated code.
When I want to change or improve something, I have to copy and paste to all relevant projects.
I looked at creating a new project within one of the solutions for the .dll/class library, but I felt that this was incorrect. (Please say if I am wrong).
As it is a component for all the applications, I decided to create a new solution for the .dll/class library and am looking at moving the shared code over to that - but, having never gone down this route before, what are my options from here?
Am I able to then include this solution within the others if I need to make a simple change and have it updated in all the projects or instead, should I always be working on the shared component in a separate instance of Visual Studio, outside of the applications using it?
That's exactly the right way to handle this situation.
You can include projects in multiple solutions by right-clicking the solution and selecting Add Existing Project...
Any changes you then make will appear in all solutions. The only problem this leads to is that it's possible to break one solution from another. This is where automated builds on commit to source control come into their own.
Put shared codes in separate Solution/Project as Class Library,
In post build event of shared projects copy dll's to a specific directory,
Add shared dll's from this directory to other projects/solutions
By doing this each time you build your consumer projects, they will use latest dll's automatically.
Moving the common code into a separate shared assembly is an excellent option.
One thing to think about is to keep your common business logic or business object type code separate from UI related code like custom controls - if you need to then have two common assemblies. This is more work initially, but makes things way easier further down the track when you need to make UI changes or change the control suite you are using.

How Can I Automate Tasks in Xcode?

I'm building an app in Obj-C / Xcode and I'm running into some repetitive tasks. For example if I want to add an image resource to my project I just go through the same identical steps... only difference is the path to the resource.
How can I automate these tasks?
Is there some sort of Xcode macro-recorder like in Photoshop and Excel?
There's definitely no macro recorder, but there are some tools you can use. First, there's Applescript, which is the most likely to be of use for this particular problem. I'm not promising it'll be easy, however. There isn't a rich collection of Applescripts for Xcode that I know of, so you'd need to dig through the Scripting Suite using Script Editor and see what's available.
For text things, there are User Scripts, which you can create from the script menu (it looks like a scroll). You can write perl, python, ruby, or whatever you like to process selected text and turn it into other text.
You can also create text macros (Edit>Insert Text Macro).
Another major repetitive task is setting up your initial project. For that you can create new project templates to be set up as you like them. I have most of a walkthrough of that written up, and should have something posted on Cocoaphony this week or early next as part of my Building the Build System series.

Resources