views:

246

answers:

2

Hi, I have several Installshield 12 setups (using non-msi Installscript based setups) for several different products. These share some code, which I would like to put into shared .rul files. However, some of that code can report errors or in general show messages to the user.

Is there any way to share strings (and their translations) across projects like you can share the .rul files? I see the string tables are included inside the ism file, and a bit of rtfm-ing and googling hasn't found an easy (or even any) way to do this.

A: 

You can export and import the string tables in either the General Information view or via the automation interface. If you've got more than a couple languages, you'll probably want to do this as an automation script to avoid driving yourself crazy.

Michael Urman
If I understand this correctly, what you say is that before building the installer from the ism, I could run a script that imports the string tables that go with the other .ruls that I'm using into the ism?
Legolas
Correct. If you're running automated builds it should be easy to integrate this sort of step into that. If you're not, it could be a bit of a pain.
Michael Urman
I'm running automated builds, so that should be ok. I just have to find out if the command line client that comes with the premier edition can also do this. Thanks for the idea.
Legolas
A: 

I have a CommonIS folder with .rul & .h files that are shared between projects. Some of those functions refer to strings via @ABC. BTW, I found that the script will compile even if the ABC identifier isn't defined in the project. For any function that a given IS proj references out of my common folder, I manually add the needed string(s) to the ISString table. I dont add new common strings too often so its not horrible.

In a few cases I changed my .rul functions to accept a sz arg instead of embedding @ABC in the function. Then when I invoke that function I specify @ABC as an arg.

There is an automation interface for IS. The purpose (I think) is to allow you to customize the build and maintenance steps (not accessible at run-time, I believe). So, conceivable you could create a new CommonString IS project that is the store. Then use the automation interface to duplicate those stings to the various other IS projects that require them.

Lastly, it is possible to include a IS .ism project into your setup's temp folder, then access the ISString table at run-time using an COM-based XML DOM. The disadvantage might be that you cant use @ABC syntax to access those strings.

GregUzelac