LB Booster: INI deletions

LB Booster
General >> General Board >> INI deletions
http://lbb.conforums.com/index.cgi?board=general&action=display&num=1448454903

INI deletions
Post by joker on Nov 25^th, 2015, 11:35am

In several places it is stated that either an "Entry" or a "Section" will be deleted if a corresponding value is "NULL". This deletion does not seem to be happening in my file today.

I can't find any way to delete a "Section" or an "Entry" other than to edit in a text editor.

I'm curious what has changed from then to now to make this no longer function, and is there a way to make that statement true?

LINK: http://lbpe.wikispaces.com/IniFiles

Quote:

Entry$
Points to a null-terminated string containing the entry associated with the value string. If the entry does not exist it will be created. If this is NULL (""), the entire section is deleted. If you were to read the file in a texteditor this entry would look like this -- the Entry$ followed by an = sign, followed by the String$

Entry=String
...
String$
Points to the null-terminated string value to be written to the file. If this is NULL, (""), the Entry$ entry is deleted from the file.

Entry=String

PS. Posted on the other forum, too.

Re: INI deletions
Post by Richard Russell on Nov 25^th, 2015, 1:05pm

on Nov 25^th, 2015, 11:35am, pnlawrence wrote:

In several places it is stated that either an "Entry" or a "Section" will be deleted if a corresponding value is "NULL". This deletion does not seem to be happening in my file today.

Strange, it seems to be working correctly for me. I ran the program below and both the 'entry' and the 'section' were deleted, by the respective statements (Windows 10, 64 bits):

Code:

    INIfile$ = DefaultDir$ + "\test.ini"
    
    calldll #kernel32, "WritePrivateProfileStringA", "MyApp" as ptr, _
        "MyKey" as ptr, "MyString" as ptr, INIfile$ as ptr, ret as long

    ' delete entry:
    calldll #kernel32, "WritePrivateProfileStringA", "MyApp" as ptr, _
        "MyKey" as ptr, _NULL as long, INIfile$ as ptr, ret as long        
        
    ' delete section:
    calldll #kernel32, "WritePrivateProfileStringA", "MyApp" as ptr, _
        _NULL as long, _NULL as long, INIfile$ as ptr, ret as long

Quote:

If this is NULL ("")

NULL is not "", they are completely different things. If that's what it states at LBPE it is hopelessly confused and should be corrected. Note that LBB will let you write _NULL as ptr (which strictly is correct since NULL is a 'null pointer') but LB won't.

Richard.

Re: INI deletions
Post by joker on Nov 25^th, 2015, 2:18pm

Of course, I'm trying to develop a function. :D

The function works fine in writing to the INI file, but I ran across the text about deleting and decided to test that out. So here I am.

I've tried explicit BYREF on all the string parameters of the function.

I can't see how to pass _NULL in a string variable without a type mismatch.

I tried chr$(0) in a string by itself. That didn't work.

So, it doesn't seem like anything that I pass to the function will accomplish this deletion unless I create the logic within the function by detecting a parameter that passes something ( chr$(0)? ) and then execute the line with "_NULL as long" in it.

What do you think about that?

Code:

function WriteINI(section$,entry$,string$,filename$)
    CallDLL #kernel32, "WritePrivateProfileStringA", _
    section$ As ptr, _
    entry$ As ptr, _
    string$ As ptr, _
    filename$ As ptr, _
    result As long
    WriteINI = result
end function

EDIT: The other forum went in and {halfheartedly} edited the LBPE section that I referenced.

Re: INI deletions
Post by Richard Russell on Nov 25^th, 2015, 3:09pm

on Nov 25^th, 2015, 2:18pm, pnlawrence wrote:

I can't see how to pass _NULL in a string variable without a type mismatch.

You could 'invent' a special unique string (it could be "", or it could be "NULL" or it could be anything at all that you are unlikely to want as the 'real' entry in an INI file, such as "DeleteThis"). Then within your FUNCTION you could test the string parameter to see if it is this special value; if it is you call the WritePrivateProfile... API with _NULL as the parameter and if not you call it normally.

If that doesn't appeal you can turn your question around. Although you can't pass _NULL in a string variable, you can pass a string via a numeric variable (using a NUL-terminated WINSTRING via a STRUCT). A bit messy, but it would work.

Richard.

Re: INI deletions
Post by tsh73 on Nov 25^th, 2015, 4:17pm

Quote:

{halfheartedly}

Haters gonna hate, yeah?

This article was originally posted in LB Newsletter in 2002.
Pretty sure no one tried to delete entry from INI file - that's not they are used for, normally.
So folks just had no idea.

You asked - you got attention of 3 different people never seen each other in real life - and in two hours article was corrected.

And you say {halfheartedly}.
;\

Re: INI deletions
Post by joker on Nov 25^th, 2015, 5:14pm

tsh73, I said {halfheartedly} because the _NULL problem wasn't addressed in a way that would provide a solution. Looks like just the text was corrected.

It wasn't a personal cut, although you could read it that way.

If the article is so important, I think it is, then correct the whole article/code. No one is putting pressure on anyone to do it immediately.

"2002"? Hell, EVERYTHING is from around that era! cheesy

Re: INI deletions
Post by Richard Russell on Nov 25^th, 2015, 5:51pm

on Nov 25^th, 2015, 5:14pm, pnlawrence wrote:

If the article is so important, I think it is, then correct the whole article/code.

I've just checked LBPE myself, and I can't see any part of the article or the included code that is still incorrect. The choice of ULONG rather than LONG for the _NULL value is not one I would have made (obviously both types can hold the value zero, but I always prefer LONG because it is the more 'fundamental' type).

What section of the article do you consider not to have been fully corrected?

Richard.

Re: INI deletions
Post by joker on Nov 25^th, 2015, 6:21pm

When I looked this morning, I didn't see the complete editing.

I should have waited until next month to look and comment, so there's enough time to finish.

Re: INI deletions
Post by tsh73 on Nov 25^th, 2015, 7:20pm

Quote:

tsh73, I said {halfheartedly} because the _NULL problem wasn't addressed in a way that would provide a solution. Looks like just the text was corrected.

OK
Quote:

It wasn't a personal cut

OK
Quote:

If the article is so important, I think it is (...)

I think important bit is this quote from MSDN:
Quote:

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

Re: INI deletions
Post by Richard Russell on Nov 25^th, 2015, 8:02pm

on Nov 25^th, 2015, 7:20pm, tsh73 wrote:

I think important bit is this quote from MSDN: "This function is provided only for compatibility with 16-bit versions of Windows. Applications should store initialization information in the registry".

One of the sillier comments in MSDN! There are several reasons why one might want to use an INI file in preference to the registry:

Easily viewed by the user.
Easily and safely edited by the user.
Easily backup-up.
Easily shared, e.g. on a network server.
Simpler and safer API.
Discussion of registry access forbidden on the LB forum.

Personally I think the registry is best left for use by the Operating System. I do use it, for example BBC BASIC for Windows stores its settings there, but as a general rule I would suggest an application program should use an INI file in preference.

Richard.

Re: INI deletions
Post by joker on Nov 25^th, 2015, 8:55pm

Uh oh.

Quote:

FileName$
Points to a null-terminated string that names the INI file. If this name is a fully-qualified path and file name, it will be used. If there is no path, Windows searches for the file in the Windows directory. If it doesn't exist, it will be created.

The API returns "0".

Why do these things not work for me? I'm always in trouble for bringing them up.

Re: INI deletions
Post by Richard Russell on Nov 25^th, 2015, 9:17pm

on Nov 25^th, 2015, 8:55pm, pnlawrence wrote:

The API returns "0".

By API I assume you mean WritePrivateProfileStruct. If the reason for the failure isn't obvious (and there aren't many things that could be wrong) you can call the Windows GetLastError and FormatMessage APIs to get a more detailed error report. You can borrow the displayError SUB from Anatoly's LBPE article for that purpose.

Quote:

Why do these things not work for me?

Insufficient attention to detail perhaps? Presumably you've checked that the INI file path you are supplying is valid and writable? If in doubt you can always try an ordinary OPEN for OUTPUT using the same path.

Richard.

Re: INI deletions
Post by joker on Nov 25^th, 2015, 10:30pm

Detail? Me? cheesy

I suppose I wasn't clear. I bolded part of the quote in my previous post that states that Windows will find the file or create it.

That finding the file or creating it part doesn't work for me, attention to detail or not.

Please let me know whether you think it should exhibit this behavior or not.

Using this "calldll #kernel32, "WritePrivateProfileStringA", "MyApp" as ptr, "MyKey" as ptr, "MyString" as ptr, INIfile$ as ptr, ret as long"

Re: INI deletions
Post by Richard Russell on Nov 25^th, 2015, 11:04pm

on Nov 25^th, 2015, 10:30pm, pnlawrence wrote:

I suppose I wasn't clear.

You said that the function returned the value zero, and that is what I was responding to.

Quote:

That finding the file or creating it part doesn't work for me

Please list some code which illustrates the problem you are having.

Quote:

Please let me know whether you think it should exhibit this behavior or not.

If you mean does the function create the file if it doesn't already exist, then yes of course it does.

Richard.

Re: INI deletions
Post by Rod on Nov 26^th, 2015, 08:01am

I have asked before that you print out your path and file name string. It will help us debug. If the Windows directory you mention in bold is a protected system directory then you won't have permission to access it. Just keep the .ini file in the project directory you do have access to. But show us the path and file name as it is used in the code.

Re: INI deletions
Post by joker on Nov 26^th, 2015, 09:56am

I am intentionally testing the routine without a path specified to see what happens.

My code works as planned when the path is included.

So, if I take those two sentences from LBPE out of context, what are the words saying?

Quote:

If there is no path, Windows searches for the file in the Windows directory. If it doesn't exist, it will be created.

...

1. "If there is no path" - Got it. I'm testing without a path; just a filename. I know there is no path, but how does the API know there is "no path?"

2. "Windows searches" - Got it. I've turned it over to the API to find the file. Where is it searching? user\appdata\blahblahblah?

3. "in the Windows directory" - That's a specific folder, so hardly a "search". More like will look in the Windows directory for the file.

4. "If it doesn't exist" - Got it. Assuming it means if the filename doesn't exist in the Windows folder.

5. "it will be created." - Got it. Simply put and repeated in this thread. The question is ... created where?

Now, since there is no path specified to the routine, then am I to assume the routine will first look "in place" ... wherever the program file is? And is that where "5. it will be created" happens? Can't do that, because it is protected space.

Or do the words "it will be created" mean somewhere under user\appdata\blahblahblah?

That ambiguity in the words was why I asked the question in the first place. I was concerned that if I give the user control of the path, then I have to know what happens when they don't specify a path. I thought that was part of testing the code that is written.

The API (calldll #kernel32, "WritePrivateProfileStringA" ...) returned a "FALSE" when I didn't include a path with the filename. It didn't "will be created" the file anywhere that I could find.

PS. If the sentences weren't there, then I suppose miscreants and misfits like me wouldn't be asking all these questions, but now the genie is out of the bottle! cheesy

Re: INI deletions
Post by tsh73 on Nov 26^th, 2015, 11:00am

Code:

FileName$ = "strangeFile.ini"  'see: no path
Section$="sect1"
Entry$="user"
String$="John Doe"

result=0

calldll #kernel32, "WritePrivateProfileStringA", _
Section$ as ptr, _    'section name
Entry$ as ptr, _      'entry name
String$ as ptr, _     'actual entry
FileName$ as ptr, _   'name of ini file
result as long

print "result=";result

return value: 1
search in Windows explorer for
Code:

strangeFile.ini

found: in %windir%

EDIT
in win2000 on virtual machine. That's what I have just now. That is,
c:\winnt

Re: INI deletions
Post by joker on Nov 26^th, 2015, 11:18am

I searched for "%windir%" in LBPE, LB help. Even looked for "windir" without success.

I searched my drive with Explorer for the filename without success.

I copied your code to my computer and executed it. "Result=0".

My first posts on the other forum was about the different way Windows(7) treats "users" versus "administrators" and how LB doesn't handle this very well in the installation process.

Apparently, you operate your computer as an admin. I separate the admin account for admin purposes and run in a non-admin environment so I don't suffer at the hands of viri creators.

That is probably why this function fails on my computer. Ok, that is some information that is useful to me that I forgot about.

Re: INI deletions
Post by Richard Russell on Nov 26^th, 2015, 11:51am

on Nov 26^th, 2015, 11:18am, pnlawrence wrote:

Apparently, you operate your computer as an admin. I separate the admin account for admin purposes and run in a non-admin environment so I don't suffer at the hands of viri creators.

By choosing not to take advantage of UAC you are making your life difficult. The benefit of UAC is that you can be logged in as an admin (with the convenience that provides when it comes to installation) without exposing you to the risks of malware.

Quote:

That is probably why this function fails on my computer.

I can't think of any situation when it makes sense not to supply a full path when calling one of the WritePrivateProfile... functions. Even if it could create the file in the Windows directory, you would not want it to. INI files almost invariably go in %appdata%, or a subdirectory thereof, so as long as you supply that as the path you should not encounter any unexpected or unwanted behaviour.

In case you're not familiar with it, the function you should be calling to locate %appdata% at runtime is SHGetSpecialFolderLocation, with the parameter CSIDL_APPDATA (26). I would point you to some LB code but all the examples I can find have a memory leak. I'm sure I've seen a version which has this issue fixed, but it was probably at the forum and there's a problem with me searching that... sad

Richard.

Re: INI deletions
Post by joker on Nov 26^th, 2015, 12:09pm

Quote:

I get notification where I need to approve an action by adding my admin password. It isn't a problem or "difficult".

Apparently, this operation doesn't trigger that process, or I would have understood what was occuring. I don't accept that as a solution that I can propose to my users.

However, I will be making sure there is a valid path specified. There are too many variables, otherwise.

Re: INI deletions
Post by Richard Russell on Nov 26^th, 2015, 1:01pm

on Nov 26^th, 2015, 12:09pm, pnlawrence wrote:

I get notification where I need to approve an action by adding my admin password. It isn't a problem or "difficult".

It can be a problem when installing an application, because it will get installed for your admin account and not for your normal user account. Unless it's one of the few which gives you the choice of installing for 'all users', you can find that it won't run properly because some of the files needed by the application (typically those stored in %appdata%) aren't accessible.

Quote:

Apparently, this operation doesn't trigger that process

Only a program with an appropriate manifest (requestedExecutionLevel = "highestAvailable" rather than the usual "asInvoker") will trigger the prompt.

Richard.