From: Ralph on

"Nobody" <nobody(a)nobody.com> wrote in message
news:%23lO9dAXdKHA.4780(a)TK2MSFTNGP04.phx.gbl...
..
> >
> > There isn't one. "256" is a hard limitation. (INI files are also limited
> > in
> > size - total of all keys and values must be less than 64k)
>
> I found by testing that INI section size is not limited to 64K, at least
on
> NT4/2000/XP/Vista/7. I made a single section and the file size is few
> hundred KB. I tested both read/write to values that reside beyond 64KB in
> these OS'es. All values are unique. I realize that this is undocumented,
so
> there maybe limitations in some systems, or could be limited in the
future.
> Here is sample code. To try it, in Form1, add three buttons with the
> following names.

I'm am aware that one can apparently violate the file size limitation of 64k
bytes.

First ran across this when Win2k was released, but as you noted it
apparently worked in WinNT. At that time there were various articles
suggesting that there was no longer any size limit. Made sense to me -
everything else was growing as well.

At the same time we experienced one of MS's flip-flops on INI/Registry - it
was back to INI files - so our abuse of INI also grew. We discovered that
you can have some huge INI files. Reading and writing to these files was no
problem if used as simple configuration files, but we began to run across
unreliable behavior when these files were shared with frequent.
reads/writes/deletes to the same Section/Keys. (persisting forms/controls)
We reduced the size back to 64k and the problems went away.

It may only be superstition but I've stayed with the 64k limitation ever
since. But it is less an issue any more simply because IMHO if one has that
amount of shared data there is usually an alternative, more optimal way, to
manage it.

-ralph


From: Ralph on
Jimekus wrote:

>>
>> For example, you could simply write your own "INI-like" database -
>> but then it wouldn't be managed by the O/S. (You'd have to create
>> your manager.). It this store is only for persistance - then you
>> might create your own serialization to a file. and so on.
>>
>> -ralph
>
> Thanks. In the meantime for my .Filename list of images from
> a .FileOpen call, I've reverted to the unlimited lengths provided by
> SaveSetting and GetSetting, you know the string of filenames separated
> by quotes.
>
> However, it strikes me that there must be another DLL out there to
> handle longer strings as Google's .Picasa.ini uses the same format for
> storing image lists and captions. I doubt they would restrict captions
> to 128 unicode characters and not tell anybody.

More than likely the picasa.ini is a custom ini file.

You could easily write your own that uses the same protocol. And there are
many examples on the net how to go about that.

The only advantage of using the inherent or WinAPI to access INI files is
that the system then controls the managment of them - they are loaded on a
heap outside of the application, and subsequent requests are managed by the
system. This had advantage in earlier Windows versions as it would save File
Handles (once a limited resource) and subsequent reads and writes where
faster than if you were opening and reading your own file.

If you are not sharing this data with other applications there really isn't
much reason to go there. Write your own.

-ralph


From: Tony Toews [MVP] on
"Nobody" <nobody(a)nobody.com> wrote:

>> I've replaced my registry entries using an ini file, but I've just
>> discovered that I can only have 254 bytes of text stored in a key, or
>> half that for unicode, so without having to use another file
>> structure, I want to find another function that supports greater
>> lengths.
>
>Try XML files.

Is there some good sample code out there for using XML files in VB6?

Tony

--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a free, convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/
From: Ralph on

"Tony Toews [MVP]" <ttoews(a)telusplanet.net> wrote in message
news:i6klh5ps3tlopqrf8c0ea3m4itad86u84p(a)4ax.com...
> "Nobody" <nobody(a)nobody.com> wrote:
>
> >> I've replaced my registry entries using an ini file, but I've just
> >> discovered that I can only have 254 bytes of text stored in a key, or
> >> half that for unicode, so without having to use another file
> >> structure, I want to find another function that supports greater
> >> lengths.
> >
> >Try XML files.
>
> Is there some good sample code out there for using XML files in VB6?
>

It depends on how far you into XML you intend to go.

For what the OP is looking for, (Section, Key, Values), using a ADODB
Recordset and saving as XML would work well.

Or take a peek at ...
http://www.freevbcode.com/ShowCode.asp?ID=2745
Can tweak for other MSXML libraries.

Traditionally XML is handled in VB6 using the DOM ActiveXDocument.

-ralph


From: Karl E. Peterson on
Jimekus presented the following explanation :
> I've replaced my registry entries using an ini file, but I've just
> discovered that I can only have 254 bytes of text stored in a key, or
> half that for unicode, so without having to use another file
> structure, I want to find another function that supports greater
> lengths.

What causes you to assume that limitation? I've never seen it. At
least not since moving to NT. Using my INI wrapper
(http://vb.mvps.org/samples/kpIni), I just did this:

Dim ini As CIniFile
Set ini = New CIniFile
ini.FileName = "d:\code\temp.ini"
ini.EntryWrite "512", String$(512, "O"), "Test"
Debug.Print Len(ini.EntryRead("512"))

The resultant file was exactly as expected, with the 512= line being
516 chars long and 512 being output to the Immediate window.

Disclaimer: I ran that test on Windows 7 x64.

--
[.NET: It's About Trust!]