Jump to content


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.
Photo

Including String Tables into the Setup


8 replies to this topic

hajure

hajure
  • Members
  • 7 posts

Posted 06 August 2002 - 15:37

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!

Taco Bell

Taco Bell

    IS6 Expert

  • Moderators
  • 1,281 posts

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.  :D
user posted image

hajure

hajure
  • Members
  • 7 posts

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.

Taco Bell

Taco Bell

    IS6 Expert

  • Moderators
  • 1,281 posts

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.
user posted image

hajure

hajure
  • Members
  • 7 posts

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.

:)

Taco Bell

Taco Bell

    IS6 Expert

  • Moderators
  • 1,281 posts

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.
user posted image

hajure

hajure
  • Members
  • 7 posts

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.


:)

Taco Bell

Taco Bell

    IS6 Expert

  • Moderators
  • 1,281 posts

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.
user posted image

hajure

hajure
  • Members
  • 7 posts

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!