INI_GetKey problem when ini file name is CLOCK.INI

[ErosOlmi]

Hi all,

I've spent almost an hour getting crazy why INI_GetKey (http://www.thinbasic.com/public/products/thinBasic/help/html/ini_getkey.htm) not working anymore.
I've got a message from Bevan stating that he created a CLOCK.INI file in the same directory of thinBasic script he is doing and he was not able to read any of the keys inside that ini file while he was perfectly able to use INI_GetSectionsList or INI_GetSectionKeyList function. I made some tests and Bevan was right. So a simple


INI_GetKey(app_sourcepath & "Clock.ini", "Setup", "Mininumpregametime", "")

was not returning anything.

The difference between INI_GetSectionsList or INI_GetSectionKeyList function and INI_GetKey is that INI_GetSectionsList and INI_GetSectionKeyList are home made functions while INI_GetKey is a wrapper of GetPrivateProfileString (http://msdn2.microsoft.com/en-us/library/ms724353.aspx) API function.

To get it short, the problem seems ini file name. If ini file name is "CLOCK.INI" GetPrivateProfileString seems to try to take data from somewhere else file or place while using something like the following where ini file name is NOT CLOCK.INI:


INI_GetKey(app_sourcepath & "_Clock.ini", "Setup", "Mininumpregametime", "")

all is working as expected. Note that here we are specifing full ini file path and not just the file name so no way to confuse with other files around.

Does anyone have an idea why? I was not able to find info on Microsoft docs. At this point I suppose CLOCK.INI is a reserved name.

Thanks
Eros

[Michael Hartlef]

Maybe \C as part of the file path is a control character and is interpreted like that?

[ErosOlmi]

Nice idea but it is not because CCLOCK.INI works fine

Anyhow thanks
Eros

[Michael Clease]

Seems to a hangover from win3.1. Its the filename.

http://www.microsoft.com/technet/archive/winntas/maintain/mngntreg/admreg.mspx?mfr=true


How Does Mapping Work?
NT implements mapping by trapping the private profile API routines I mentioned in Chapter 1. Windows applications and components ordinarily use these calls to get and set data stored in INI files, but when there's a mapping entry, the NT kernel first checks for the presence of a mapping key. If one exists, and if it points to a key that contains data, that data is returned to the caller. If there's no mapping key, or if it points to an empty or non-existent Registry key, NT will go ahead and try to read the data from the INI file. The caller need never be aware that the data didn't come from the requested file.

Mapping only occurs when there's a mapping key in place. These keys are stored beneath the HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping subkey. If you look there, you'll notice a number of subkeys with names like Clock.INI, Win.INI, and SYSTEM.INI. These keys tie sections of the old Win 3.1-style INI files to keys in the Registry so that old Windows 3.1 components like the Clock and the original media controller interface (MCI) will continue to find their settings.

[Petr Schreiber]

Good find Abraxas !

This was really tricky problem, good solved so fast

Bye,
Petr

[ErosOlmi]

Thanks a lot Abraxas.
That's what a community is: help each other and exchange ideas and knowledge to have a common bigger shared knowledge.

[RobertoBianchi]

;D this is the reason that I not removed the registry storage from ThinAIR!

Roberto

[Petr Schreiber]

;D

Vampires ? Werewolfes ? Zombies ?

No. The only thing I am really afraid of are Windows Registry :D.
But good thinAIR works with them ok :)


Bye,
Petr