Hi all,
I am working on a common code base for all my Setups.
For the script functions (.rul files) it's easy to include other Files by #include... (fine so far).
Now I want to "include" the coresponding common String constants from the "String Table" into the actual Setup without copying every time all Strings by hand.
How can I solve that.
I appreciate every help.
Thank You!
This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Including String Tables into the Setup
Started by
hajure
, Aug 06 2002 15:37
8 replies to this topic
Posted 07 August 2002 - 01:45
Humm, still no reply, eh? Darn! 'cause I would like to know how to do this for future use.
Posted 07 August 2002 - 10:05
Thanks for reply,
In the next days I'll do some kind of workaround. I'll create some kind of a "MY-Standard-Setup" with all the Strings and includes and so on in it, and use it as "template" for future setups.
But this is not satisfying me, because I will always have to modify a lot.
I'd appreciate any help,
hajure.
In the next days I'll do some kind of workaround. I'll create some kind of a "MY-Standard-Setup" with all the Strings and includes and so on in it, and use it as "template" for future setups.
But this is not satisfying me, because I will always have to modify a lot.
I'd appreciate any help,
hajure.
Posted 07 August 2002 - 19:13
I know you were going for string tables, but another option would be to have a separate .h file which has a bunch of #defines to represent string constants (i.e. #define BOB "My name is Bob."). This would then be accessed with the same #include syntax.
Posted 08 August 2002 - 11:56
Thats a good Idea!
I write down my thoughts, in the hope to find a way out.
I was thinking about defines too, but I didn't manage to find an elegant way of distinguishing among different languages.
I mean, at the moment I am calling the same string in all languages and IS is chosing the right one for the used language.
With defines I would need different names for the same string in different languages, because every define needs its own identifier. Not satisfiying yet!
At this point, I would need/use a 3-dimensional Array (language, String name, string value).
Lets get practical and lets have three languages. With IS I could generate three lists (one for every language). Now I would have to use at runtime a switch between my defined string lists (use SELECTED_LANGUAGE). Now I would have to get the string by Index out of the selected list (ListSetIndex, ListGetNextString). I would write a function for that and feed it only with the index. This seems to be good a start to find something easier.
Now, at this point I have the bright Idea of using three languages and one index. I would extend my defines by an index define.
So I am going from a three dinmensional solution to a four dimensional one.
I am using 4 defines for each string: three for the languages and one extra for the index. I will call the string by this defined Index. But one extra is still needed: the selecting function needs to "know" all the indexes. This means, each time I insert a new string, I have to extend my function by this Index, to enable the functin to do "if [LANGUAGE] and [INDEXDEFINE] then [THISSTRINGDEFINE]". This is a bit ugly , but I may be able to live with it.
Thank You for help.
I write down my thoughts, in the hope to find a way out.
I was thinking about defines too, but I didn't manage to find an elegant way of distinguishing among different languages.
I mean, at the moment I am calling the same string in all languages and IS is chosing the right one for the used language.
With defines I would need different names for the same string in different languages, because every define needs its own identifier. Not satisfiying yet!
At this point, I would need/use a 3-dimensional Array (language, String name, string value).
Lets get practical and lets have three languages. With IS I could generate three lists (one for every language). Now I would have to use at runtime a switch between my defined string lists (use SELECTED_LANGUAGE). Now I would have to get the string by Index out of the selected list (ListSetIndex, ListGetNextString). I would write a function for that and feed it only with the index. This seems to be good a start to find something easier.
Now, at this point I have the bright Idea of using three languages and one index. I would extend my defines by an index define.
So I am going from a three dinmensional solution to a four dimensional one.
I am using 4 defines for each string: three for the languages and one extra for the index. I will call the string by this defined Index. But one extra is still needed: the selecting function needs to "know" all the indexes. This means, each time I insert a new string, I have to extend my function by this Index, to enable the functin to do "if [LANGUAGE] and [INDEXDEFINE] then [THISSTRINGDEFINE]". This is a bit ugly , but I may be able to live with it.
Thank You for help.
Posted 08 August 2002 - 15:28
Fortunately for me, I've never had to deal with multi-language installs. However, I know enough to say that supporting them is certainly a downside with #defines and an upside with string tables.
Posted 08 August 2002 - 19:14
Hi TacoBell00,
you won't believe it, but I did it today for all my commonly used strings and it works!!!.
I had to do a lot of work to finish the filter function because for every string index, there are 9-10 lines of code in it (at the end it were more than 300 lines).
For the future I do not need to copy the common strings anymore by hand into each new project ! Just #include the .h file!
Thats why I did it.
For each new String I will have to add 4 lines as define (3 languages, 1 index). If I would use the string tables I would have to type in this text too.
I will have to extend the filter function by 9-10 lines (if...elseif...elseif) by copy and paste, to find the string.
And I will have to call all common strings by :
SelectTheString(THE_STRING_INDEX_DEFINE)
instead of
@THE_STRING_DEFINE
because the filter function returns the string.
For all common strings I can recommend this solution.
Here is an example for one String:
#define STR1 1 //index
#define STR1_DE "deutsch"
#define STR1_EN "english"
#define STR1_TU "türkiye"
prototype STRING selStr(number);
function STRING selStr(index)
STRING retStr;
begin
switch(index)
case STR1: if (SELECTED_LANGUAGE == 0x0007) then
retStr = STR1_DE ;
elseif (SELECTED_LANGUAGE == 0x0009) then
retStr = STR1_EN ;
elseif (SELECTED_LANGUAGE == 0x001f) then
retStr = STR1_TU ;
elseif
//case....
default: retStr ="blah ERROR";
endswitch;
return retStr ;
end;
Get the string by calling e.g
selStr(STR1) ;
I hope someone can use this. Any improvement is welcome.
you won't believe it, but I did it today for all my commonly used strings and it works!!!.
I had to do a lot of work to finish the filter function because for every string index, there are 9-10 lines of code in it (at the end it were more than 300 lines).
For the future I do not need to copy the common strings anymore by hand into each new project ! Just #include the .h file!
Thats why I did it.
For each new String I will have to add 4 lines as define (3 languages, 1 index). If I would use the string tables I would have to type in this text too.
I will have to extend the filter function by 9-10 lines (if...elseif...elseif) by copy and paste, to find the string.
And I will have to call all common strings by :
SelectTheString(THE_STRING_INDEX_DEFINE)
instead of
@THE_STRING_DEFINE
because the filter function returns the string.
For all common strings I can recommend this solution.
Here is an example for one String:
#define STR1 1 //index
#define STR1_DE "deutsch"
#define STR1_EN "english"
#define STR1_TU "türkiye"
prototype STRING selStr(number);
function STRING selStr(index)
STRING retStr;
begin
switch(index)
case STR1: if (SELECTED_LANGUAGE == 0x0007) then
retStr = STR1_DE ;
elseif (SELECTED_LANGUAGE == 0x0009) then
retStr = STR1_EN ;
elseif (SELECTED_LANGUAGE == 0x001f) then
retStr = STR1_TU ;
elseif
//case....
default: retStr ="blah ERROR";
endswitch;
return retStr ;
end;
Get the string by calling e.g
selStr(STR1) ;
I hope someone can use this. Any improvement is welcome.
Posted 10 August 2002 - 19:47
I have a suggested improvement. You're not gonna be switching languages on-the-fly, so you needent evaluate the language choice each and every time!
Instead you can have a function which you call during OnBegin to load the #defines for the current language choice into a large string array. This string array would be declared as a global variable. You can then use your same indexing scheme to access the string, but without having to call a function. Doing so should also a eliminate a lot of redudant code.
---
On a side note, your script is no longer a .H file since you've added function defintions to it (i.e function STRING selStr(index) ), so it should technically be called a .RUL file or you should move the definition to a separate .RUL file.
This is just a programming convention for filenames though. IS will certainly not force you to live up to this.
Instead you can have a function which you call during OnBegin to load the #defines for the current language choice into a large string array. This string array would be declared as a global variable. You can then use your same indexing scheme to access the string, but without having to call a function. Doing so should also a eliminate a lot of redudant code.
---
On a side note, your script is no longer a .H file since you've added function defintions to it (i.e function STRING selStr(index) ), so it should technically be called a .RUL file or you should move the definition to a separate .RUL file.
This is just a programming convention for filenames though. IS will certainly not force you to live up to this.
Posted 19 August 2002 - 09:11
Thank you for the suggestion.
It might result in a better performance. I would have to detect the language in every setup at the begin and write this info into a variable. Hmm , I`d have to take care that, the variable is initialized correctly, each time.
Concerning the programming convention for filenames: I surely did so, and split the code up into different files, my functions are .rul files and the defines are in a .h file. This way I get a better overview over the code. Each file is big enough anyway.
Now, where I've already done it, I`m quite satisfied with this solution.
----------
The sample code sniplet in my posting is just a sample.
Thanks again!
It might result in a better performance. I would have to detect the language in every setup at the begin and write this info into a variable. Hmm , I`d have to take care that, the variable is initialized correctly, each time.
Concerning the programming convention for filenames: I surely did so, and split the code up into different files, my functions are .rul files and the defines are in a .h file. This way I get a better overview over the code. Each file is big enough anyway.
Now, where I've already done it, I`m quite satisfied with this solution.
----------
The sample code sniplet in my posting is just a sample.
Thanks again!