Clipper 5.2 Problem 1

[mfigueiredo]

Hi

I'm developing an aplication in clipper 5.2. This SW is pretends to be multilingual.
I use arrays for the translations, like this: the module menu.prg uses the header msg_menu.h for the tranlations.
But after placing the translations for the 4 languages when I try to compile it gives me STRING SPACE EXAUSTED!!! I also have ca clipper 5.3 but I still wasn't able to create the linker file!!!

Thanx for any help

 

[circes9]

with all header files included in the compile/build, I think all variables are being defined. Do all header files need to be included in same compile, or could you compile and English version by including just the english header, a Spanish version, etc.
Another thought would be to use a dbf to hold your values to load the arrays with and not use .ch files.

Good luck

 

[GAstrada]

Believe it or not, in (think 1993), CA launched two versions of clipper in a high speed way: February, and March.

I have both. But March's version, often give me a "string space exhausted". The february version doesn't, NEVER. NEVER.

Is there any GURU to explain that ?.

If you want, I'll give the two strange versions !!!

 

[Charmntwain]

i once went the same ordeal as you are right now and i just break down my programs to four(4) small programs and it went on without any hitch try it i hope it helps

 

[mfigueiredo]

GASTRADA,

Can you give me the Frebruary version???

It's very urgent!!!!!

Would apreciatte that!

 

[wfh]

Have you tried table driven menus?

 

[mxPavel]

Maybe you are running out of conventional memory (that one below 640Kb) and you are declaring inline arrays that are too large.

This problem can be resolved by reducing the size and/or
number of strings and arrays that are active at any one time. Probably the most common cause of this error is the declaration of extremely large arrays (e.g., LOCAL aArray[500][300]). Note that every array element requires memory to store -- even if its value is NIL -- and that the number of array elements in an array is determined by multiplying the number of elements in every dimension and adding the sum of all dimensions except for the last. For example, a 500x300 array has (500x300) + 500, or 150,500, elements.

Because every array element in Clipper requires 14 bytes, this amounts to 150,500 x 14, or 2,107,000 bytes -- well in excess of one megabyte and therefore potentially dangerous.

Note: There is no benefit gained by reusing arrays. Clipper is much more efficient when strings and arrays are thrown away and rebuilt often rather than kept around unnecessarily for long durations.

If this doesn´t help you, please post a new message indicating the memory map of your machine (remember the dos command MEM) and comment more about the prg where the problem bombs.

 

[GAstrada]

mfigueiredo, of course I'll send you that February version, but you must give me your e-mail direction to send you !!!, no ??. Where I'll send it. ??

By the way. look closely at mxPavel concepts dated Oct 1, 2001. HE IS RIGHT, and we all should learn, to make our clipper's apps run in a more efficient mode.

But your problem is in compile time, not in run-time time.

your e-mail ? regards.

 

[mfigueiredo]

GASTRADA,

Yes I know you need my email to send me anything ;-)

mfigueiredo@cpcis.pt

This is very urgent!!!!
Thanx a lot, hope this can solve my problem, otherwise I will have to learn how to create the linker file in clipper 5.3!!!
I'm having some problems because I am a Visual Basic programmer, not Clipper but there are times that we need to learn some new ("older&quot stuff to keep working.

BEST REGARDS from Portugal!

 

[mxPavel]

Hello mfigueiredo!

When you declare an inline array like
aArray := { x, v, z ...}

and its too big the compiler fails with the errror space exhausted...

instead, declare it as:
Local aArray[100]
and then assing values later using aArray[ n ] := xValue

This is because at compiler time clipper creates a symbol table, so when your use inline array it tries to figure out the lenght of it parsing the line of code...

Well, if this is not the case, can you post your compiler script or bat file to see how are you compiling the code, and the exact version of your clipper compiler (there is 5.2a, 5.2b, c, d or e)?

Also check if you are using too many #defines nad #translates or if your prg is too large or contains too many functions/procedures.