.INI in VB.Net?

[Tommy Long]

I know how to do it in VB6, I have code snippets coming out my ears for VB6,
but with the new framework in Visual Studio 2005, how do you get/put from a
..INI

If I attempt to use a VB6 snippet in Studio 05 it whinges about using the
'as Any' type in my declarations, and it whinges about using the String$()
function when creating a buffer string variable. Infact, it whinges a whole
lot, why my employer got VS05 I'll never know.

Anyway, thanks in advance for any help.

If people have simple alternatives for the use of .ini's for my future
reference, that'd be handy as well. Assumably .xl?

Cheers,
Tommy

 

[Tommy Long]

Found it,

Never mind. Linked below:

http://www.developer.com/net/asp/article.php/3287991

 

[Tommy Long]

I've been using the VB6 Code, I've found an answer but in the interest of
better answers, here are the declarations:

Private Declare Function GetPrivateProfileString Lib "kernel32" Alias
"GetPrivateProfileStringA" (ByVal lpApplicationName As String, ByVal
lpKeyName As Any, ByVal lpDefault As String, ByVal lpReturnedString As
String, ByVal nSize As Long, ByVal lpFileName As String) As Long

Private Declare Function WritePrivateProfileString Lib "kernel32" Alias
"WritePrivateProfileStringA" (ByVal lpApplicationName As String, ByVal
lpKeyName As Any, ByVal lpString As Any, ByVal lpFileName As String) As Long

They both throw multiple errors for their use of the 'Any' variable type.

Additionally, in the following 'GetFromINI' procedure:

Function GetFromINI(sSection As String, sKey As String, sDefault As String,
sIniFile As String)
Dim sBuffer As String, lRet As Long
' Fill String with 255 spaces
sBuffer = String$(255, 0)
' Call DLL
lRet = GetPrivateProfileString(sSection, sKey, "", sBuffer,
Len(sBuffer), sIniFile)
If lRet = 0 Then
' DLL failed, save default
If sDefault <> "" Then AddToINI sSection, sKey, sDefault, sIniFile
GetFromINI = sDefault
Else
' DLL successful
' return string
GetFromINI = Left(sBuffer, InStr(sBuffer, Chr(0)) - 1)
End If
End Function

I receive an error for using the function 'String$(#, #)' which I don't know
a replacement for in VB.NET.

I'm not all that interested in converting to XL* files, though I may in the
future. I believe the link I provided in my initial post contains a link
near the bottom for implementing XL* procedures instead of INI though.

Any help that is better for one reason or another than the class based
solution I posted is much appreciated.

Tommy

 

[rowe_newsgroups]

I've been using the VB6 Code, I've found an answer but in the interest of
better answers, here are the declarations:

Private Declare Function GetPrivateProfileString Lib "kernel32" Alias
"GetPrivateProfileStringA" (ByVal lpApplicationName As String, ByVal
lpKeyName As Any, ByVal lpDefault As String, ByVal lpReturnedString As
String, ByVal nSize As Long, ByVal lpFileName As String) As Long

Private Declare Function WritePrivateProfileString Lib "kernel32" Alias
"WritePrivateProfileStringA" (ByVal lpApplicationName As String, ByVal
lpKeyName As Any, ByVal lpString As Any, ByVal lpFileName As String) As Long

They both throw multiple errors for their use of the 'Any' variable type.

Additionally, in the following 'GetFromINI' procedure:

Function GetFromINI(sSection As String, sKey As String, sDefault As String,
sIniFile As String)
    Dim sBuffer As String, lRet As Long
    ' Fill String with 255 spaces
    sBuffer = String$(255, 0)
    ' Call DLL
    lRet = GetPrivateProfileString(sSection, sKey, "", sBuffer,
Len(sBuffer), sIniFile)
    If lRet = 0 Then
        ' DLL failed, save default
        If sDefault <> "" Then AddToINI sSection, sKey, sDefault,sIniFile
        GetFromINI = sDefault
    Else
        ' DLL successful
        ' return string
        GetFromINI = Left(sBuffer, InStr(sBuffer, Chr(0)) - 1)
    End If
End Function

I receive an error for using the function 'String$(#, #)' which I don't know
a replacement for in VB.NET.

I'm not all that interested in converting to XL* files, though I may in the
future.  I believe the link I provided in my initial post contains a link
near the bottom for implementing XL* procedures instead of INI though.

Any help that is better for one reason or another than the class based
solution I posted is much appreciated.

Tommy

Here's a great site to find the proper API declarations for .NET

http://www.pinvoke.net/

Also, I personally never use .ini files for my .NET applications. I
prefer to use a custom xml file or use the My.Settings code and it's
attached .config files.

Thanks,

Seth Rowe [MVP]
http://sethrowe.blogspot.com/

 

[Herfried K. Wagner [MVP]]

I know how to do it in VB6, I have code snippets coming out my ears for
VB6,
but with the new framework in Visual Studio 2005, how do you get/put from
a
.INI

Complete INI library written in VB based on the Win32 INI functions:

<URL:http://dotnet.mvps.org/dotnet/samples/filesystem/IniLib.zip>

 

[Cor Ligthert[MVP]]

Herfried,

I was waiting for this one,

Strange enough that there is nobody who tells not to use INI files anymore,
I say it here, but I don't go in the discussion, it is discussed to often in
past, and samples for better alternatives are easily to find on Google.

But it seems that the sinse this millenium better alternatives for INI files
are completely missed by some persons.

Cor

 

[SurturZ]

If only Microsoft allowed you to save Application scope settings as well as
User ones in My.Settings!!!

I find it inexplicable that they don't. Maybe it is because with certain
deployments each user login has a separate copy of the app, so changes to
settings for all users on a computer can't be done this way??

Maybe saving/loading a dataset to XML is the way to go.

I've always liked .INI files, but I find the argument list of
GetPrivateProfileString painful. I always end up wrapping it in another
function so I can get an .INI setting in one line of code.

--
David Streeter
Synchrotech Software
Sydney Australia

Herfried,

I was waiting for this one,

Strange enough that there is nobody who tells not to use INI files anymore,
I say it here, but I don't go in the discussion, it is discussed to often in
past, and samples for better alternatives are easily to find on Google.

But it seems that the sinse this millenium better alternatives for INI files
are completely missed by some persons.

Cor

 

[Cor Ligthert[MVP]]

Sutur,

Where you talking about, are you talking about isolated storage?

http://msdn.microsoft.com/en-us/library/bdts8hk0.aspx

I doubt it.

Cor

If only Microsoft allowed you to save Application scope settings as well
as
User ones in My.Settings!!!

I find it inexplicable that they don't. Maybe it is because with certain
deployments each user login has a separate copy of the app, so changes to
settings for all users on a computer can't be done this way??

Maybe saving/loading a dataset to XML is the way to go.

I've always liked .INI files, but I find the argument list of
GetPrivateProfileString painful. I always end up wrapping it in another
function so I can get an .INI setting in one line of code.

--
David Streeter
Synchrotech Software
Sydney Australia

 

[Michael Leithold, WWK]

You can look at this framework for reading config files:

http://nini.sourceforge.net/index.php

It's a more .NET like way to read and write ini files than win32 API.

Michael

 

[Herfried K. Wagner [MVP]]

Strange enough that there is nobody who tells not to use INI files
anymore, I say it here, but I don't go in the discussion, it is discussed
to often in past, and samples for better alternatives are easily to find
on Google.

But it seems that the sinse this millenium better alternatives for INI
files are completely missed by some persons.

Well, it seems that even in this millennium there are thousands of
well-tested and well-established programs in use which still rely on INI
files!

 

[Herfried K. Wagner [MVP]]

I find it inexplicable that they don't. Maybe it is because with certain
deployments each user login has a separate copy of the app, so changes to
settings for all users on a computer can't be done this way??

You are giving the reason why it's not possible to write application-scoped
settings. The current setting would depend on the value persisted by the
user who used the application for the last time. This would not make much
sense.

I've always liked .INI files, but I find the argument list of
GetPrivateProfileString painful. I always end up wrapping it in another
function so I can get an .INI setting in one line of code.

Fortunately a wrapper can be written once and used several times. There is
no need to reinvent the wheel for each application.

 

[SurturZ]

You are giving the reason why it's not possible to write application-scoped

settings. The current setting would depend on the value persisted by the
user who used the application for the last time. This would not make much
sense.

In real-world programming there are plenty of cases where this makes sense.
For example, if there is a report that need to be printed on special
stationery. If the normal "special stationery" printer breaks down, a user
can change the default printer for that report to another printer, and you
want it changed for all users of that PC.

Setting default save directories after installing an application is another
example.

 

[Cor Ligthert[MVP]]

David,

In real-world programming there are plenty of cases where this makes
sense.

I have no idea what you mean with this statement, will you be so kind to
give an example

I cannot bring this subject what is still from the century that people were
using horses to pull a car, with "real world".

Cor

 

[Cor Ligthert[MVP]]

Herfried,

Austria is now a republic, the time from the greath empire is over.



Cor

 

[Dennis]

You can look at this framework for reading config files:

http://nini.sourceforge.net/index.php

It's a more .NET like way to read and write ini files than win32 API.

Is there a framework like this which uses XML to read AND write user
settings?

 

[SurturZ]

I have no idea what you mean with this statement, will you be so kind to
give an example

I already have. Please read my posts in their entirety before trolling.

I cannot bring this subject what is still from the century that people were
using horses to pull a car, with "real world".

Can I recommend "Fowler's Modern English Usage"? Your sentence is completely
ungrammatical.

I my experience, programmers, such as yourself, that are quick to dismiss
old reliable methods in favour of new cutting edge techniques cause the
greatest harm in software projects. (If you don't take my word for it. Take
Dan Appleman's: http://www.danappleman.com/?p=64)

INI files are easily understood by, and modifiable by, non-programmers. They
are reliable and hard to screw up (and easy to fix even if you do screw them
up). To abandon them without first proving that the replacement has
significant advantages is unwise.

Mocking a tried and trusted technique, as you have, just shows how much of a
newbie you are, despite your MVP status.

 

[SurturZ]

LOL, so did you jump on the "store all app settings in the registry"
bandwagon when Microsoft first deprecated INI files, Cor? How many times did
you need to rebuild your computer? How much cruft is in your registry as a
result? :-D

I'd love to hear your explanation of why INI files are bad. I could do with
a laugh.

--
David Streeter
Synchrotech Software
Sydney Australia

Herfried,

Austria is now a republic, the time from the greath empire is over.



Cor

 

[rowe_newsgroups]

First off let me state that it is not my place to speak for Cor, but
frankly your behavior is getting very offensive.

To start, the method Cor and I generally use instead of INI is to use
a DataSet and export/import it as XML. In my opinion, and most other
peoples as well, XML files are better to use and easier on both the
programmer and the end-user (if modifying them is required or
expected) and they allow for much more custom behavior, such as
multiplatform or transmitting over the web.

Can I recommend "Fowler's Modern English Usage"? Your sentence is completely
ungrammatical.

I recommend you learn about the internet and realize that it's a
global thing and not centered in english speaking countries. Cor is
from Germany (if I remember correctly) and we are lucky enough that he
chooses to help out not only in the German speaking newsgroups but
also in the english speaking ones.

I my experience, programmers, such as yourself, that are quick to dismiss
old reliable methods in favour of new cutting edge techniques cause the
greatest harm in software projects. (If you don't take my word for it. Take
Dan Appleman's:http://www.danappleman.com/?p=64)

Because we all know how bad it is to use XML files, shame on Visual
Studio for using them extensively......

INI files are easily understood by, and modifiable by, non-programmers. They
are reliable and hard to screw up (and easy to fix even if you do screw them
up). To abandon them without first proving that the replacement has
significant advantages is unwise.

Xml files are just as easy, if not more-so (given a good xml editor)
to edit than INI files in my opinion.

Mocking a tried and trusted technique, as you have,

I find this humorous since in your post following this one you clearly
mock use of the Registry, another one of those "tried and trusted
technique" that Microsoft uses in almost every one of their programs?
You see, even though it's one of the most basic storage systems and
used extensively by the software giant, you know that there are
problems with it and therefore use a different technique. I, and Cor
and others, have merely suggested you move on to a different technique
then INI files, just like you would do in the case of someone wanting
to use the Registry.

just shows how much of a
newbie you are, despite your MVP status.

Cor is an MVP because he is an expert in Visual Basic .NET, recognized
by his peers and the creators of the .NET platform. Perhaps before you
dismiss his advice and make yourself sound like a fool and a simple
USENET troll, you should take a moment or two and think about what he
is suggesting. You seem new to the .NET platform, so it might do you
some good to listen to what the expert are trying to tell you. In the
end, it doesn't matter to us what technology you use, but you need to
learn to listen and to show some respect, because the last thing you
want is to be labelled as a troll and get kill filed by the people who
answer more questions than anyone else in the newsgroups.

Thanks,

Seth Rowe [MVP]
http://sethrowe.blogspot.com/

 

[SurturZ]

Look I agree that persisted datasets are a better solution that INI files,
but I don't think INI files are dead quite yet. In fact, I wasn't really
talking about INI files at all, I was complaining about the lack of ability
to save application settings with My.Settings - which is quite a new
technology.

As for my rudeness to Cor, I was merely responding in kind to this comment:

I cannot bring this subject what is still from the century that people were

using horses to pull a car, with "real world".

which was (badly) trying to imply something about my character or advice.
There is no excuse for bad English on this board. If you are more comfortable
writing another language, then go to one of the other language boards.

Cor is the one trolling here, and I am just calling him on it. In other
threads he has flamed people asking for advice, which is inexcusable.

--
David Streeter
Synchrotech Software
Sydney Australia

 

[SurturZ]

I agree with you there. Plain XML is fantastic, but once you start adding
namespaces and transformations I think it gets quickly out of hand. The
Dataset XML routines thankfully generate nice, clear XML.