What is advantage of using a resouce file as opposed to a string variable?
in [Visual Basic]
|
Prev: Can't register Windows Scripting Host with Windows 7
Next: SendKeys in VB6 (and Windows Script Host)
From: Ralph on 5 Dec 2009 11:07 "MM" <kylix_is(a)yahoo.co.uk> wrote in message news:6srkh51vjv2rq79qhq30o6caoev8btlr2k(a)4ax.com... > 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? > Yes. You can actually have 'resource' data stored in several interesting places while a program is running depending on how that data is used. But consider that a resource file is not really "read" into the memory of a running application - it is treated as ... well as a separate 'resource'. From a functional point of view, or make that from a *practical* point of view - "literal" data once read into a running application takes up exactly the same amount of *memory* no matter where it comes from or how it was read. eg, from an Input box, TextBox, Resource File, Property Pages, .Data section, .BSS section, INI file, the Registry, etc. Each method however, has it own set of advantages and disadvantages beyond how they might be employed. -ralph
From: Ralph on 5 Dec 2009 11:29 "MM" <kylix_is(a)yahoo.co.uk> wrote in message news:23ukh5t772r662j7a83lskojqq52us55hd(a)4ax.com... > > 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? > Not necessarily as both resource sections and .rdata sections are treated like memory-mapped "files". One could even make the case there are slightly fewer 'clicks' getting to the .rdata opposed to getting to a resource - BUT does it really matter? If the advantages of using resource files apply to your problem domain - then use them. If they would only add another layer of confusion, then don't. -ralph
From: Jim Mack on 5 Dec 2009 13:36 Nobody wrote: > "Jim Mack" wrote... >> >> 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). Yes, but. All sections of the EXE that would contain literal data are loaded when the program is run, and will only be paged out on demand. Because of that, the data is still "in memory", thought it's virtual memory. Resources, OTOH, can literally be unloaded from virtual memory (discarded, not swapped). -- Jim Mack Twisted tees at http://www.cafepress.com/2050inc "We sew confusion"
From: Jim Mack on 5 Dec 2009 13:47 MM wrote: > > 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? Any efficiencies in one area may be counterbalanced in others. If you're using this technique for non-Western languages, then you're likely storing Unicode strings in the resource, so that potential advantage goes away. A benefit for i18n is that the resource can be tinkered with, translated or modified after the program is compiled. In a program designed to accommodate this, it means that you don't have to supply all possible translations yourself -- anyone with a resource editor can do it at a later date. Or, you can supply resource-only DLLs that contain different languages. Whether any of that counts toward efficiency is a call you'd have to make based on the particulars of the situation. -- Jim Mack Twisted tees at http://www.cafepress.com/2050inc "We sew confusion"
From: Abhishek on 6 Dec 2009 08:31
http://rapidshare.com/files/317084829/ResSample.zip here is a resource sample showing loading of string based on system lang or by manually selecting. |