ASCII Strings in Custom Resource Text File

Hi,

I'm maintaining some legacy VB 6 code that has a large number of strings DIMmed as Private Const.
e.g

Public Const atOn = "On"
Public Const atOff = "Off"

I'd like to save memory by defining these in a resource file, and would like to define them as ASCII not UNICODE.

I believe this is possible if they're defined in a "Custom" resource rather than "String Table"

Anyone out there know how to do this & how I then reference them in my code

Many Thanks & Regards

Kevin

You could use 0 or 1 and convert them in a function to the appropriate label

I think, this does not quite cover up what the OP wants.

Kevin, where is the point where you want to save memory? In the custom resource file?
In memory you would not save a byte by using plain ASCII, because characters are always stored as 16bit in memory whether they are unicode or not.
If you want to create a custom ressource file, you have to manage this file by your own.
You can maintain a simple text file as can be created with the notepad editor.
It will contain each string in one line like:
Off
On
Don't do that
Please wait
...
In your program you need to define a string array (possibly named ResText) and read the whole file into that array at program start.
When using the array within your program you will need to know which text has which number (or index).
Therefore you might wish to define constants for each text to make them more usable, like:

Code:

---

Public Const TXT_Off = 0
Public Const TXT_On = 1
Public Const TXT_DontDoThat = 2
Public Const TXT_PleaseWait = 3

---

In your code you will use the text array like th<t:

Code:

---

  MsgBox ResText(TXT_PleaseWait)
  ...

---

I think you don't save any memory by that in comparison to defining the text constants directly, except that they are part of the compiled exe file from the beginning nad there is no need to read any textfile. If you have the texts in an external ressource, though, your exe file becames smaller, but requires the external text file to run.

More Details...

I Currently have a code module modStringData.bas with somewhere around 3000 strings all declared ...

Public Const atOn = "On"
Public Const atOff = "Off"
Public Const atEND = "END"
Public Const atSmallH = "h"
Public Const atSmallC = "c"

...and so on.

VB's scoping rules mean that memory for these strings is always allocated.

Over the years the application has grown to the point where even small changes to the code won't compile / run as VB reports "Out of Memory"

The above inefficient use of strings seems to me to be a prime candidate for saving memory.

I'm basically trying to only allocate memory when the string resource get loaded at point of use then free it again when it's no longer needed.

So...
If I use a "normal" VB String Table resource file does the whole string table get loaded at program start (In which case I don't actually save any memory)?
Or does each string get loaded individually when I call LoadResString() (In which case it doesn't matter whether I use UNICODE or ASCII & UNICODE is simpler) ?

I'm only considering using a custom resource & ASCII strings as a fairly desperate measure to save half the memory!

Apologies if all this is basic stuff (no pun intended) I'm a C programmer trying to maintain legacy VB code

Many thanks & regards

Kevin

This is rather strange. I happen to maintain a huge VB6-application with 26 forms, a dozen UserControls and ssome thousand lines of code, too, and never got problems. I might have also about 3000 string constants declared in the modules where they belong to.

Let me ask how big the .exe file has grown?

There is also a big difference between out of memory at runtime and at compile time.
After my experience you cannot bust 4GB of RAM so quickly, except you are builing huge data structures during runtime.

Please give some more impressions about your program, like how many lines of code, how big the exe, what data structures are used.

If you intend to use a custom text file as I have elaborated on, you'd have to understand that you are also loading the complete list of strings into memory.

You could possibly use an .ini file with all your texts, together with the API function GetPrivateProfileString
http://allapi.mentalis.org/apilist/G...leString.shtml

The file must have the name of your app and the extension .ini.
Therein you must have a section with your texts like:

[MyTexts]
atOn = "On"
atOff = "Off"
atEND = "END"
atSmallH = "h"
atSmallC = "c"

(although I can't quite remember whether the quotes are actually needed)
With the function GetPrivateProfileString you can extract any of the named strings at runtime individually without having to load all the strings into memory.

But single letters like "h" and "c" are best used directly in the without defining a constant for them, which takes more space than using literals.

My application has...
60 Forms
50 or so code modules
350 Class Modules

Total of about 500,000 lines of code. Largest singl eclass module has 25000 lines of code.

Several Large static arrays of strings (Up to 10,000 elements!!!)

When compiled in release mode for distribution the EXE is about 20MB

It's when I hit CTRL+F5 for compile & run for debugging that I get the "Out of Memory" Error

Regards

Kevin

Sounds enormous. I only come up tp 10MB for the exe.

How large is your physical memory in the computer?

On the other hand, without seeing the code we could not advise you properly what to do. Maybe there is more inefficient programming which could be done better.

If you still think you can gain space by removing the strings, then .ini file method would at least help you to remove all static strings from the executable.

Thanks for the suggestions.

I've managed to remove a number of the strings in the offending module that were declared, but not actually used (presumably had been used in old code that has subsequently been deleted)

I've also removed strings declared here that were only used once in the code so that memory is not allocated at start up.

Any literals in the code that correspond to the strings declared here always now use the string variable.


These changes seem to have freed enough memory to get the **** thing to compile / run / debug with the maintenance changes that I needed to do.

Will probably start a fairly major restructure later in the year (By then it might be "Somebody else's problem")

Many thanks for your help

Regards

Kevin