Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Problem with GetPrivateProfileString()
1,362 views
Skip to first unread message
Jürgen Knauf
Jul 5, 2016, 2:10:40 AM7/5/16
to
GetPrivateProfileString() is not workiung correctly.
When I try to read an empty value from an INI-File, I do not get the alternate value back.
pszFile := "C:\Program Files (x86)\texManager 8\tm.ini"
pszBuffer := Space(127)
GetPrivateProfileString("PFADE","LOCALAPP","ABCDE",pszBuffer,127,pszFile)
? pszBuffer
In this case it must be "ABCDE", but I get an empty value.
Windows 10 64-Bit, Vo 2.8
Jürgen
When I try to read an empty value from an INI-File, I do not get the alternate value back.
pszFile := "C:\Program Files (x86)\texManager 8\tm.ini"
pszBuffer := Space(127)
GetPrivateProfileString("PFADE","LOCALAPP","ABCDE",pszBuffer,127,pszFile)
? pszBuffer
In this case it must be "ABCDE", but I get an empty value.
Windows 10 64-Bit, Vo 2.8
Jürgen
Arne Ortlinghaus
Jul 5, 2016, 3:41:33 AM7/5/16
to
Hello Jürgen,
Until now I have not seen any problems with Windows 10 64 and VO 2.8.
Perhaps it is better to use Memalloc and copy the psz to a normal string
before verifying as in the example below.
Does another process writes into the ini file at the same time? I have seen
that this can create problems even if other entries of the file are changed.
Arne Ortlinghaus
ACS Data Systems
METHOD GetString (cSection, cEntry, cDefault, cFirmaID) CLASS IniFile
//p Liefert den Wert einer Variablen als String
//a cSection - String: Section
//a cEntry - String: Entry
//a cDefault - String für Defaultwert oder nil
//a cFirmaID - Falls angegeben: Lesen von einer ine speziellen Firma (falls
Firmenverwaltung)
LOCAL ptrBuffer as psz
LOCAL cBuffer as STRING
Default(@cDefault, "")
ptrBuffer := MemAlloc (2049)
GetPrivateProfileString (String2Psz(_cSubSection+cSection),
String2Psz(cEntry), String2Psz(cDefault), ptrBuffer, ;
2048, String2Psz(self:fullPath))
cBuffer := Psz2String (ptrBuffer)
MemFree (ptrBuffer)
RETURN cBuffer
"Jürgen Knauf" <trotte...@googlemail.com> schrieb im Newsbeitrag
news:0a08cc3b-7ab7-4a57...@googlegroups.com...
Until now I have not seen any problems with Windows 10 64 and VO 2.8.
Perhaps it is better to use Memalloc and copy the psz to a normal string
before verifying as in the example below.
Does another process writes into the ini file at the same time? I have seen
that this can create problems even if other entries of the file are changed.
Arne Ortlinghaus
ACS Data Systems
METHOD GetString (cSection, cEntry, cDefault, cFirmaID) CLASS IniFile
//p Liefert den Wert einer Variablen als String
//a cSection - String: Section
//a cEntry - String: Entry
//a cDefault - String für Defaultwert oder nil
//a cFirmaID - Falls angegeben: Lesen von einer ine speziellen Firma (falls
Firmenverwaltung)
LOCAL ptrBuffer as psz
LOCAL cBuffer as STRING
Default(@cDefault, "")
ptrBuffer := MemAlloc (2049)
GetPrivateProfileString (String2Psz(_cSubSection+cSection),
String2Psz(cEntry), String2Psz(cDefault), ptrBuffer, ;
2048, String2Psz(self:fullPath))
cBuffer := Psz2String (ptrBuffer)
MemFree (ptrBuffer)
RETURN cBuffer
"Jürgen Knauf" <trotte...@googlemail.com> schrieb im Newsbeitrag
news:0a08cc3b-7ab7-4a57...@googlegroups.com...
Wolfgang Riedmann
Jul 5, 2016, 5:24:08 AM7/5/16
to
Hi Jürgen,
please pay attention that the program files directory and the windows
directory have special handlings when a process tries to write there.
To be compatible with Windows 7/8/10 you should NEVER write anything
there.
If your program or another program tries this, the following can occur:
1) if the writing program is manifested for Windows 7/8/10, and the
process has not elevated rights, the write will fail.
2) if the writing program is not manifested for newer Windows versions,
the ini or whatever file is written to the virtual store hierarchy of
the current user, so the configuration data is not shared between
different users, and could also not be shared between different
applications.
I don't know if GetPrivateProfileString() is not trying to write and
fails therefore - it is a Windows API function, not a VO function.
My strong recommendation is to never install programs that are using
configuration data or, even worser, application data (like nearly all
my VO programs do) into the Program Files structure - better to install
them in a separate directory.
Programs installed into the Program Files structure should put their
configuration and data in the (hidden) ProgramData structure.
Wolfgang
--
please pay attention that the program files directory and the windows
directory have special handlings when a process tries to write there.
To be compatible with Windows 7/8/10 you should NEVER write anything
there.
If your program or another program tries this, the following can occur:
1) if the writing program is manifested for Windows 7/8/10, and the
process has not elevated rights, the write will fail.
2) if the writing program is not manifested for newer Windows versions,
the ini or whatever file is written to the virtual store hierarchy of
the current user, so the configuration data is not shared between
different users, and could also not be shared between different
applications.
I don't know if GetPrivateProfileString() is not trying to write and
fails therefore - it is a Windows API function, not a VO function.
My strong recommendation is to never install programs that are using
configuration data or, even worser, application data (like nearly all
my VO programs do) into the Program Files structure - better to install
them in a separate directory.
Programs installed into the Program Files structure should put their
configuration and data in the (hidden) ProgramData structure.
Wolfgang
Jürgen Knauf
Jul 6, 2016, 3:55:12 AM7/6/16
to
GetPrivateProfileString() is only reading data.
And is runs since years without any changes.
I think the silent updates of windows 10 are a big problem for programmers. Because the sentence “Never change a running system” is no longer valid!
Jürgen
Jean Raymond
Jul 7, 2016, 8:10:21 AM7/7/16
to
REf:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms724353(v=vs.85).aspx
lpDefault [in]
A default string. If the lpKeyName key cannot be found in the initialization
file, GetPrivateProfileString copies the default string to the
lpReturnedString buffer. If this parameter is NULL, the default is an empty
string, "".
As far as I know, only if the key [LOCALAPP] is not found, then it will
return [ABCDE] default value.
If the key is found, then it will return a NULL_STRING, and this is correct.
No where here they say that if the value is empty, then it will return the
[ABCDE] default value.
My humble opinion...
Jean Raymond
http://www.rayonline.com
/-----------------------------------------------------------------------------------------------------------------------------------
"Jürgen Knauf" wrote in message
news:0a08cc3b-7ab7-4a57...@googlegroups.com...
https://msdn.microsoft.com/en-us/library/windows/desktop/ms724353(v=vs.85).aspx
lpDefault [in]
A default string. If the lpKeyName key cannot be found in the initialization
file, GetPrivateProfileString copies the default string to the
lpReturnedString buffer. If this parameter is NULL, the default is an empty
string, "".
As far as I know, only if the key [LOCALAPP] is not found, then it will
return [ABCDE] default value.
If the key is found, then it will return a NULL_STRING, and this is correct.
No where here they say that if the value is empty, then it will return the
[ABCDE] default value.
My humble opinion...
Jean Raymond
http://www.rayonline.com
/-----------------------------------------------------------------------------------------------------------------------------------
"Jürgen Knauf" wrote in message
news:0a08cc3b-7ab7-4a57...@googlegroups.com...
Jürgen Knauf
Jul 8, 2016, 7:18:19 AM7/8/16
to
you are the best. Thank you.
This was the solution!!
Jürgen
0 new messages