Hi jep,
that's a very interesting way to do it... but I am afraid that when I have all captions, text, messages and stuff in a file for an entire project with 3 or more dialogs and all their respective controls, it will become quite time-consuming to do all the interpretation at run-time.
You may be surpised. I'm using REXX on an ancient Athlon 1.1GHz machine to parse 3 catalog files containing over 90,000 records. The records are in pipe delimited format (plain text) a few thousand characters long per record. It takes about .003 seconds per record to parse. Or .3 seconds per 100 records.
The parsing stage includes finding various information in the data string for each record, (which each of is a few thousand characters long), create a new set of variables for each entry in the record string, create a new set of variables for each set of additional information I am interested in (it's laptop computer descriptions, and lacks specific fields for HDD size, screen size, etc; so the script has to find that information in the description string: "Comes with a 17.1" WXGA LCD screen and a 120GB HDD") - about 40 variables per record, create an SQL insert statement, write that statement to a separate file and repeat for all 90,000+ records.
(after that, I dump the whole file to MySQL to create the database without having to do individual records)
So, I've found, even with the disk reads (across the network from the file on the server to the workstation that is processing it) of the text files and the disk writes (also across the network from the file on the server to the workstation that is processing it) of the SQL command file, that .003 seconds for each record is pretty darn fast.
You may also find that such speeds are sufficient for any file/text parsing you need. I am guessing that if you remove the write stage that you probably don't need, and have the files accessed locally, you would see even better results. That should hopefully offset the unzip time, especially as you can use the unzip dll to only load which files you need.
The bigger concern in either method is that stem access/creation/changing in ObjectREXX is pathetic when compared to the same exact code in cREXX. And introduces memory leaks and eventual "Out of resources" errors with only a small amount of memory used.
While your approach would solve the issue of "how to link" from a control to its needed string resource in a file, it also exposes too much of the program logic to the end-user, which in effect opens the door for errors (or even "security risks") in my mind.
What if the zip file was encrypted? I think the unzip.dll supports reading from encrypted files (but could be wrong).
Okay, the security risk is neglectable on my end perhaps, since it would break the prorgram and make it unusable for the user, so ther is no intention by a user to fiddle with the cfg file.
Nevertheless, the flexibility of the solution has some price to pay at run-time. I would prefer to have simple plain-text input files (also for the translators) and a very small, fast and straightforward "loading" at run-time. In between these phases, a highly complicated process can "compile" the text input to the desired format for runtime.
Regarding the unzip - that's indeed nice as well, however unzipping something into memory at each run-time doesn't make sense to me in this context, also it means trading-off the benefits of using SysGetMessage (this won't work anymore with unzipping into a stem).
Well, it would require a little additional work, but probably could be done.
Jep, don't get me wrong: What you showcased here is highly flexible and a very interesting approach indeed (I never thought of doing it that way). However, for my needs it puts a mis-balance to performance and processing requirements when comparing the main task of the program versus the "feature" of multilingual resource handling.
Basically, the SysGetMessage is almost perfect for my needs. The only drawback is that I would have to know the resource ids (message numbers) by heart when doing the coding of the application.
Nah... just create a "lookup table" and use a variable. When used in a stem, the "sub-variable" becomes the value. I think the same can be done very easily with regular (non-stem) variables.
DialogInfo.DialogOne.Caption for instance can be the name you use in your program, then simply "superclass" the call to SysGetMessage so that you send it the above string as text. It can interpret out the value, file and so on from the stem sections.
I use a similar method to dynamically built variables for a report for a REXX program I have written to calculate data from about 10,000 records. The stem creation and accessing takes fractions of seconds. The calculations on the other hand take a little longer. All in all, it creates the whole report, html and all, in about 8-15 seconds. I doubt you'd be using one hundredth of that number of records, making the time it takes for you to accomplish something probably 1/500th of that time (as I also doubt you will be doing a bunch of math calculations, building a 50,000 line html file in memory, etc).
Best,
Rob