Prev: Can't register Windows Scripting Host with Windows 7
Next: SendKeys in VB6 (and Windows Script Host)
From: MM on 5 Dec 2009 06:32
I've read Karl's article about using a .res file and LoadResData to
store and transfer data, but why is this better than just using a
string variable?

I need to pump a load of data into a user-defined array (88 piano
keys!) once only at startup and in the past I have handled that kind
of task by sticking the data into a string, then using, say, Split to
extract it.

I then set the string to "" to recover memory.

This is a lot less faffing about than using the resource editor and I
can quickly change values in the string on the fly to test. So what's
the advantage with the resource file approach?

MM
From: Jim Mack on 5 Dec 2009 07:21
MM wrote:
> I've read Karl's article about using a .res file and LoadResData to
> store and transfer data, but why is this better than just using a
> string variable?

Internationalization, or other post-compile customization. For
strings, there's no other good reason.

Well, possibly one: for very large sets of strings, you can save space
by storing them as Ansi. If you let VB compile them into the EXE
they'll be Unicode, and so twice the size. And the OS can unload
resources if it needs memory, which won't happen with built-in
strings -- that would require swapping.

> I need to pump a load of data into a user-defined array (88 piano
> keys!) once only at startup and in the past I have handled that kind
> of task by sticking the data into a string, then using, say, Split
> to extract it.
>
> I then set the string to "" to recover memory.

But you don't recover the memory used by the original string. If it's
compiled into the EXE it stays in memory.

--
Jim Mack
Twisted tees at http://www.cafepress.com/2050inc
"We sew confusion"

From: MM on 5 Dec 2009 09:36
On Sat, 5 Dec 2009 07:21:25 -0500, "Jim Mack" <jmack(a)mdxi.nospam.com>
wrote:

>MM wrote:
>> I've read Karl's article about using a .res file and LoadResData to
>> store and transfer data, but why is this better than just using a
>> string variable?
>
>Internationalization, or other post-compile customization. For
>strings, there's no other good reason.
>
>Well, possibly one: for very large sets of strings, you can save space
>by storing them as Ansi. If you let VB compile them into the EXE
>they'll be Unicode, and so twice the size. And the OS can unload
>resources if it needs memory, which won't happen with built-in
>strings -- that would require swapping.
>
>> I need to pump a load of data into a user-defined array (88 piano
>> keys!) once only at startup and in the past I have handled that kind
>> of task by sticking the data into a string, then using, say, Split
>> to extract it.
>>
>> I then set the string to "" to recover memory.
>
>But you don't recover the memory used by the original string. If it's
>compiled into the EXE it stays in memory.

What if the same amount of data is stored in a resource file, does
that stay in memory, i.e. twice, once in the .res and once in the
resultant array?

MM
From: Nobody on 5 Dec 2009 09:46
"Jim Mack" <jmack(a)mdxi.nospam.com> wrote in message
news:u9r63VadKHA.5472(a)TK2MSFTNGP02.phx.gbl...
> But you don't recover the memory used by the original string. If it's
> compiled into the EXE it stays in memory.

According to someone else in this group, paging is used so not everything is
loaded into memory, only the parts that are accessed. Page size is usually
4K or 8K(Newer systems).


From: MM on 5 Dec 2009 10:22
On Sat, 5 Dec 2009 07:21:25 -0500, "Jim Mack" <jmack(a)mdxi.nospam.com>
wrote:

>MM wrote:
>> I've read Karl's article about using a .res file and LoadResData to
>> store and transfer data, but why is this better than just using a
>> string variable?
>
>Internationalization, or other post-compile customization. For
>strings, there's no other good reason.
>
>Well, possibly one: for very large sets of strings, you can save space
>by storing them as Ansi. If you let VB compile them into the EXE
>they'll be Unicode, and so twice the size. And the OS can unload
>resources if it needs memory, which won't happen with built-in
>strings -- that would require swapping.
>
>> I need to pump a load of data into a user-defined array (88 piano
>> keys!) once only at startup and in the past I have handled that kind
>> of task by sticking the data into a string, then using, say, Split
>> to extract it.
>>
>> I then set the string to "" to recover memory.
>
>But you don't recover the memory used by the original string. If it's
>compiled into the EXE it stays in memory.

Using LoadResString, it does work quite nicely.

I've now created a string table with the first few rows as a test:

ID English (United Kingdom)
105 16,0,0,8,1,20,0
107 11,0,0,8,1,20,0
108 6,0,0,9,1,10,0

and

Private Sub Command1_Click()
Dim v
Dim i As Integer
v = Split(LoadResString(107), ",")
For i = 0 To UBound(v)
Debug.Print v(i), IsNumeric(v(i))
Next
End Sub

I assume this is more efficient than storing a very long string
literal?

MM
 |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11
Prev: Can't register Windows Scripting Host with Windows 7
Next: SendKeys in VB6 (and Windows Script Host)