CONSTANTS versus separate table for 'messages' etc.

[Nifrabar]

In a recent thread I was adviced to not used Constants for statusbartext but instead use seperate table holding all that information.
Q: For when should we need an include-file and when is it adviced to use table with messages.
Both are as far to my knowledge usefull :
- to get consistent namings throughout the application
- to be able to simply switch to other language for users
TIA for your contribution on this topic.
-Bart

 

[StewartUK]

Bart,

I would never use constants for messages that the user would see.

Constants are built into the application (that is, the constant name is replaced with the value of the constant) at the point when you build it. So if you ever needed to change a message you would need to rebuild the exe. If you ever came to the point where you want one to user to see a slightly different message from another user, you couldn't do that with constants.

I think constants are primarily of use to you the developer so that rather than ahve "magic numbers" in various places you have a constant with a meaningful name. This helps you, and anyone else, to understand & remember what's happening as you read your code.

Having an include file means that you can set up all the constants you might need to use in your application without having to define then in every form and program. You also then get consistency in the names of your constants.

I hope that's a helpful explanation. I've never done anything with switching languages so can't help you there, sorry.

Stewart

 

[Nifrabar]

Stewart, thanks for information.
I can see your point which sounds usefull to me.
Are you also using a table for messages contents?
KR
-Bart

 

[StewartUK]

Glad you found it useful Bart.

Yes I do use a table for messages to users.

I also use it to hold other data that the application needs such as dates when an event last happened, lists of users who should be informed when certain things happen and so on.

The structure is in the form of, what I think is called, key-value pairs. One field contains the key and the second field contains its value, such as a date, which is actually stored as character type.

The program that accesses it converts the character value into the correct data type when returning it and converts it back to character when writing it.

Stewart

 

[Imaginecorp]

Bart;
Let me first say; include files, constants like "LOC_FILE" etc etc are overrated and more a PIA than they are worth in real life. Using a table for names, messages etc is equally useless, now you have to do a Seek every time you need a "Constant" Or you create a public object to hold these “constants” which again uses memory. With Both, you have to remember the “Constant” name to use it. If you are creating tables to hold these why not use a Header file its less overhead...supposedly.
If you are looking for "Meaningful" names create meaningful Local variables. Trust me the memory hit is minor.

Constants for statusbartext

Why Not, The statusbartext for each control will never change, Statusbartext, as we use it, is more of a mini-help to guide the user than anything else. Better way to display the statusbartext, again as we do, is to write it in the comments of the table, i.e. comments for the field in the table itself. Now the statusbartext for a particular field is in every form that the field is dropped on. Then in the init of the class i.e. textbox etc etc, put the following:

 this.StatusBarText = this.Comment
The only drawback here is you have to drag the field from the table onto the form

to get consistent naming throughout the application

Sure its textbook programming and everyone recommends it but In a 10,000+ line app are you really going to remember what each "name" is for without doing a lookup? Whats the value in this? Now everytime you create a form, program etc you have to check you table or header file for the "Constant" name, this takes time... Time wasted

to be able to simply switch to other language for users

If using constants would make that easy, I would have been a billionaire. It is NOT easy to switch an app to another language and NO software or framework in the market will help you accomplish that... easily. It involves a complete interface rewrite which involves practically rewriting 80% of the application...

Again all of this is just my opinion...

 

[Mike Lewis]

I agree with Stewart and Imaginecorp. I seldom use constants, for the reasons stated. Except perhaps to hold a "magic number" (such as an RGB() colour code), and then I only do it locally.

However ....

you have to remember the "Constant" name to use it.

Don't forget you can type zdef into the editing window to have Intellisense bring up a list of your constants. But that's not an argument in favour of using them.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[Olaf Doschke]

Imaginecorp, you're missing the point that applications could be international and localizing means you CAN'T put a statusbar text into the statusbar property, because it is NOT static and it WILL change.

Waht is static is, that you want a certain text in it, in english, french, german .....

So a way to achive that is to use a constant and have different header files for each language, but then you need to recompile for each language.

You can of course read in .h files at runtime and parse out the constants, but then you're not using them as constants, but as data. And therefore, have a dbf and lookup translations by an original text, that is the easiest way to handle this.

Bye, Olaf.

 

[Imaginecorp]

So a way to achive that is to use a constant and have different header files for each language, but then you need to recompile for each language.

I am Not disagreeing with you Olaf, But is it worth the hassle? I do not know if Bart's company is an international one, if not its a waste of time and effort, dont you think, if his app is being sold locally.

Now lets say I am selling my app in France, USA, Mexico, China, India and Germany. Would not my interface have to be in those languages? Which means a different interface for each language, If I am translating each applicable interface would it not be easier for me to Type in the StatusBartext, Messages etc in the control's properties rather than create different header files which in this scenerio would mean absolutely nothing as I am redoing the interface anyway.

"zdef", learnt something new today, thanks Mike

 

[Nifrabar]

Gentlemen,
Thanks for all your opinions about this subject.
From the answers I have to find my own way.
One thing I learnt again is that it's not always that easy to remain consistent in all siuation.
As already many times mentioned in '1001 things': it all depends on the particular situation.
Once again; thanks for your input.
-Bart

 

[Olaf Doschke]

Imaginecorp,

what other reason is there than internationalisation to want to use a constant to preset a property???

Plus I'm NOT recommending using different headers, because of the hassle with them, because of the need to recompile for each localisation. I'm recommending using data.

Bye, Olaf.

 

[coldan]

I use a CSV for messages in 4 languages ( in columns) stored in App Data folder - which is inserted into a table when the exe runs.

I use a lookup with a column number code to get the correct language.

HTH

 

[Olaf Doschke]

If I am translating each applicable interface would it not be easier for me to Type in the StatusBartext, Messages etc in the control's properties rather than create different header files which in this scenerio would mean absolutely nothing as I am redoing the interface anyway.

Why would you redo the interface/GUI anyway? No you'd have the same layout only differnt label captions etc. But you don't need to rewrite the whole GUI just for changing captions.

Bye, Olaf.

 

[Imaginecorp]

Hello Olaf; Sorry did not see this earlier...

Why would you redo the interface/GUI anyway

As you know, most words are not the same length in most languages, anytime you take an interface written in the English language and then try to translate the labels; the controls as well as the labels have to be repositioned to accommodate the new length (size). Now think, if the interface was being converted from English to Arabic or Urdu (right to left)
All messages have to be re-written.
All status bar text has to be re-written.
All pre-defined choices in dropdowns have to be rewritten.
Some validations that are dependent upon some text being entered have to be rewritten.
Report labels have to repositioned and rewritten.
Complete Help has to be rewritten.

Well, you get the idea...

Now multiply all the above by about 350+ forms and 100+ reports and I don’t know how many messages (at least 5 in each form), Every control in the 350+ forms for statusbartext and quite a few lines of code...(our app)

Now think about maintenance and support...

Trust me; 6 years ago we tried to convert our app into Spanish for a prospective client in Mexico... It was a horror story and after 4 months I scrapped the project and lost money on the deal...Never Again

So just creating constants or keeping data in a table is not enough...Sure I had even thought of making the complete app "data driven"... was young and foolish in those days...

 

[Olaf Doschke]

Sorry Imaginecorp,

while I see you have valid points, if an app is planned to be international you can reserve enough space for each language and define labels to autsize and eg to align right instead of left, you can work with abbrevetions, and Steven Blacks INTL Toolkit and several application frameworks supporting it for the internationalisation speaks for itself. In my 10 years experience, in which a german/english localisation played an early role I'm not on your side and did data driven internationalisation successfully, even though the same applies: german does mostly take more space than english.

Regarding arabic or other Right-To-Left languages, you truly have a point in that you're not done in setting the .RightToLeft property. At least not unless you run in an appropriate windows version (see help on right to left).
What does not automatically change is that form layout is mirrored, but such an operation is doable.

Bye, Olaf.

 

[Imaginecorp]

Hello Olaf:

Everything and everything is do-able.

In programming as in life you are only bound by your imagination...

If from the start you are planning to "internationalize", it’s a little easier as you now have the big picture and can code accordingly, but to take an existing app and convert...It’s just not worth the hassle and effort unless the payoffs are huge. In our case they were not...

 

[Olaf Doschke]

Well, on the other hand you must have been very wise and have not put much code into forms. Which I think is quite impossible, you need at least to have a call to some bizobject method in each buttons click and often enough those methods gather at the form level and not in a seperate non gui object, even if you use foxpro application frameworks. So when you do a complete GUI change, you maintain identical code in two projects. I doubt a bit, even though in the idealism of n-tier design there would be quite no code in forms and you could redo the GUI quite effortless.

Bye, Olaf.