LB Booster - INI deletions

LB Booster

General

General Board (Moderator: Richard Russell)

INI deletions

« Previous Topic | Next Topic »

Pages: 1 2

Author

Topic: INI deletions (Read 1507 times)

joker
Global Moderator

member is offline

Gender:

Posts: 157

Re: INI deletions
« Reply #2 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.

« Last Edit: Nov 25^th, 2015, 2:23pm by joker »

Logged

Richard Russell
Administrator

member is offline

Posts: 1348

Re: INI deletions
« Reply #3 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.

« Last Edit: Nov 25^th, 2015, 3:12pm by Richard Russell »

Logged

tsh73
Full Member

member is offline

Gender:

Posts: 210

Re: INI deletions
« Reply #4 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}.
;\

Logged

joker
Global Moderator

member is offline

Gender:

Posts: 157

Re: INI deletions
« Reply #5 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

Logged

Richard Russell
Administrator

member is offline

Posts: 1348

Re: INI deletions
« Reply #6 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.

Logged

joker
Global Moderator

member is offline

Gender:

Posts: 157

Re: INI deletions
« Reply #7 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.

Logged

tsh73
Full Member

member is offline

Gender:

Posts: 210

Re: INI deletions
« Reply #8 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.

Logged

Richard Russell
Administrator

member is offline

Posts: 1348

Re: INI deletions
« Reply #9 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.

« Last Edit: Nov 25^th, 2015, 8:05pm by Richard Russell »

Logged

joker
Global Moderator

member is offline

Gender:

Posts: 157

Re: INI deletions
« Reply #10 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.

Logged

Richard Russell
Administrator

member is offline

Posts: 1348

Re: INI deletions
« Reply #11 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.

Logged

joker
Global Moderator

member is offline

Gender:

Posts: 157

Re: INI deletions
« Reply #12 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"

Logged

Richard Russell
Administrator

member is offline

Posts: 1348

Re: INI deletions
« Reply #13 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.

« Last Edit: Nov 25^th, 2015, 11:30pm by Richard Russell »

Logged

Rod
Full Member

member is offline

Gender:

Posts: 110

Re: INI deletions
« Reply #14 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.

Logged

joker
Global Moderator

member is offline

Gender:

Posts: 157

Re: INI deletions
« Reply #15 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

Logged

tsh73
Full Member

member is offline

Gender:

Posts: 210

Re: INI deletions
« Reply #16 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

« Last Edit: Nov 26^th, 2015, 11:02am by tsh73 »

Logged

Pages: 1 2


« Previous Topic \| Next Topic »