GetPrivateProfileString

[Edwin Knoppert]

>Note This function is provided only for compatibility with 16-bit Windows-based applications. Applications should store initialization information in the registry.

Since a 16bit app usually cannot execute such a 32bit function you may assume it's meant to keep support for ini stuff where the registry is favourite.
So it can not mean, "we are about to remove these functions".

I know at least one situation where an ini fill is required to fulfill the (Windows) task.

Even if these functions would be removed it's pretty easy to write your own parsing code.
But Windows is optimized for this task with regard to multiuser and speed (cache).

BTW, the full folder was a thing present since Windows 3.1.. and i can know
If no folder, the Windows folder as used (as mentioned above)

[Michael Mattias]

>...The only problem with using the getprivateprofilesection

How did getprivateprofilesection get into this? I thought your challenge was with GetPrivateProfileString.

And what are these character count restrictions of which you speak? There is no 200 character limitation in the WinAPI INI file functions. The only limit of which I am aware is a 64K limit on the size of a section, and I'm not so sure that applies except on Win/9x. (OK, so I could look it up).

I must be missing something.

[Scott Turchin]

Read that about the INI files as well - my app uses strictly INI files as they are a batch file that my app interprets.

The only problem with using the getprivateprofilesection that does the CRC32 etc etc is that I need to add data to the line so back ot my original post I'm using a hex conversion function to convert binary to hex...and I'm limited to 200 characters I guess, maybe less now with SP3..but it works..

[Michael Mattias]

The SDK from which I quote is the Oct 2003 release.

I dropped subscription after the Jan 2004 release (and reinstalled Oct '03), because the new release was pretty much all ".NET" and I could no longer find any of the 'standard' WinApi calls.

Not that they weren't there, but I could not find them so they may as well have not been there.

MCM

[Kev Peel]

Question: Why continue to write new code that needs an API that MS has been hinting at deleting since at least 2000

Answer: Microsoft have never "deleted" an API call. Even some Win16 calls are retained for backwards compatibility. That note in MSDN should have been removed, because a few years later they started recommending that you don't use the registry, at least for large amounts of settings and data, and that you should go back to INI files.

I would hazard a guess that at least 90% of desktop apps use INI files and INI- related functions.

[Dale Yarker]

MSDN still says:
"Note This function is provided only for compatibility with 16-bit Windows-based applications. Applications should store initialization information in the registry." on the GetPrivateProfileString page.

So, I don't use GetPrivateProfileString or related functions. I don't mess with the registry either. Code to parse a .ini file isn't hard to do. Used to make them look like MS .ini, lately I've been using more of a Linux .cfg style. Most recently been moving them to C:\Documents and Settings\blah\blah to be Vista ready.

Question: Why continue to write new code that needs an API that MS has been hinting at deleting since at least 2000?

[Michael Mattias]

GetPrivateProfileString
.....
lpFileName
[in] Pointer to a null-terminated string that specifies the name of the initialization file. If this parameter does not contain a full path to the file, the system searches for the file in the Windows directory.

[Wayne Diamond]

Personally I prefer Int3 breakpoints in good old OllyDbg (with my PB Analyzer plugin of course), but MSGBOX has a similar effect

[jcfuller]

Imagine how buggy our programs would be if it weren't for msgbox breakpoints

MsgBox's disrupt the flow of a program and can cause more problems then they find? You also have to go back and remove the code! TRACE is your friend! Use it liberally in development cycles. Then one line -> #TOOLS OFF turns your debug code in to a release candidate!!

James

[Wayne Diamond]

I've put enough MSGBOX's in my code to narrow it back to the FIRST ini call I make.

Imagine how buggy our programs would be if it weren't for msgbox breakpoints

[Scott Turchin]

Here is the solution, works like a champ now.

Weird I never saw that before:

Function ConvertToFullPath(ByVal FileSpec As String) As String
Local zTmp      As Asciiz * %MAX_PATH
Local Nullo     As Asciiz * 2
Local lResult   As Long
lResult = GetFullPathName(ByVal StrPtr(FileSpec),ByVal SizeOf(zTmp),ByVal VarPtr(zTmp),Nullo)
Function = zTmp
End Function

[Scott Turchin]

I use INI files a lot, and I've just found an issue I never came across before.

I've put enough MSGBOX's in my code to narrow it back to the FIRST ini call I make.

Everything comes back empty..IF and ONLY if I am launching my program with the INI file specified as the commandline.

CCSBatch.exe TEST.INI

That won't work.

HOWEVER:

CCSBatch.exe D:\PBDLL\CCSBATCH\TEST.INI

THAT DOES WORK.


So OK anybody heard of this? And if so, how can I append the directory to my INI file name???

Not sure a code sampl;e is required, pretty basic...if so let me know.