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 8 Dec 2009 21:15 "Karl E. Peterson" <karl(a)exmvps.org> wrote in message news:ez1E9PHeKHA.856(a)TK2MSFTNGP05.phx.gbl... > Tony Toews [MVP] wrote on 12/8/2009 : > > "Ralph" <nt_consulting64(a)yahoo.com> wrote: > > > >>> So Ralph isn't your real name then? <smile> > >>> > >> > >> Define "real"? > >> > >> <g> > >> > > > > Square root of -1? > > > You're making that up! > Yeah, seems kind of imaginary to me. -ralph
From: David on 9 Dec 2009 17:27 Another option might be keep the string in a database. I recently moved a number of large strings which were being displayed in a Messagebox when a menu item was selected. Initially they were compiled as part of the EXE, but now read the string from the database, and then load it to the messagebox. I'm going on the believe the string memory is recovered when the messagebox is closed. "MM" <kylix_is(a)yahoo.co.uk> wrote in message news:upgkh59tht01jmv199bm2rujpuabgfurb2(a)4ax.com... > 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: MM on 10 Dec 2009 02:51 On Wed, 9 Dec 2009 17:27:10 -0500, "David" <dw85745NOT(a)earthlink.net> wrote: >Another option might be keep the string in a database. >I recently moved a number of large strings which were being displayed in a >Messagebox when a menu item was selected. > >Initially they were compiled as part of the EXE, but now read the string >from the database, and then load it to the messagebox. >I'm going on the believe the string memory is recovered when the messagebox >is closed. Yes, that was always my traditional approach. You wouldn't actually need a database for this project because a simple text file would suffice, since the data is read in once only at program start-up. However, I wanted to investigate other ways of getting the data in *without* the addition of another file. In QuickBASIC days the first port of call was the DATA statement. The resource file approach IS working very well now that I have discovered rc.exe. I've created a batch file to recompile the .res from a .txt file, then I simply replace the current .res file in the project with the latest compiled version. I've already recompiled it a number of times while I work out the fine details of the parameter values needed. MM
From: David on 10 Dec 2009 07:59 The key question for me is memory usage and recovery. After reading all the posts, am I correct in "assuming" the following: 1) String literals that reside and are compiled in the EXE remain in memory. 2) String literals that are loaded at runtime (say from text file or database) can be removed from memory depending on the object they are loaded to. For example if a text file is read into a MessageBox and the procedure where the Messagbox resides is completed, the string is removed from memory. Other objects where strings were read and loaded once set = Nothing would remove the strings. 3) A Resource file is read and memory allocated when the EXE is compiled and the Strings stays in memory -- no memory is recovered. when the object using the resource file is set = Nothing. David "MM" <kylix_is(a)yahoo.co.uk> wrote in message news:3p91i55u6m3qaq9g38h1fktktvtof2pg8t(a)4ax.com... > On Wed, 9 Dec 2009 17:27:10 -0500, "David" <dw85745NOT(a)earthlink.net> > wrote: > >>Another option might be keep the string in a database. >>I recently moved a number of large strings which were being displayed in a >>Messagebox when a menu item was selected. >> >>Initially they were compiled as part of the EXE, but now read the string >>from the database, and then load it to the messagebox. >>I'm going on the believe the string memory is recovered when the >>messagebox >>is closed. > > Yes, that was always my traditional approach. You wouldn't actually > need a database for this project because a simple text file would > suffice, since the data is read in once only at program start-up. > > However, I wanted to investigate other ways of getting the data in > *without* the addition of another file. In QuickBASIC days the first > port of call was the DATA statement. > > The resource file approach IS working very well now that I have > discovered rc.exe. I've created a batch file to recompile the .res > from a .txt file, then I simply replace the current .res file in the > project with the latest compiled version. I've already recompiled it a > number of times while I work out the fine details of the parameter > values needed. > > MM
From: Jim Mack on 10 Dec 2009 10:06
David wrote: > The key question for me is memory usage and recovery. > After reading all the posts, am I correct in "assuming" the > following: > > 1) String literals that reside and are compiled in the EXE remain > in memory. Yes, in virtual memory. > > 2) String literals that are loaded at runtime (say from text file > or database) can be removed from memory depending on the object > they are loaded to. For example if a text file is read into a > MessageBox and the procedure where the Messagbox resides is > completed, the string is removed from memory. Other objects where > strings were read and loaded once set = Nothing would remove the > strings. Correct, except that these are not string literals, but variables. > > 3) A Resource file is read and memory allocated when the EXE is > compiled and the Strings stays in memory -- no memory is recovered. > when the object using the resource file is set = Nothing. It's not that clear-cut. Resources are loaded on demand, and when no longer needed can be discarded by the OS (since they're static and can be reloaded if required). That doesn't mean they _will_ be discarded, only that they can be. Which gets us to the crux: unless you have megabytes of string data, there's really no reason to think about this. Discardable segments will stay in virtual memory unless there's a triggering event like a low memory condition. This is rare these days, and again, unless you have a ton of data, discarding it isn't going to be much help. Except for the fact that resources 'package' the data with the EXE, a separate database or flat file is a better solution, IMO. -- Jim Mack Twisted tees at http://www.cafepress.com/2050inc "We sew confusion" |