Author |
Topic: INI deletions (Read 1508 times) |
|
joker
Global Moderator
member is offline
Gender: 
Posts: 157
|
 |
Re: INI deletions
« Reply #5 on: Nov 25th, 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! 
|
|
 Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: INI deletions
« Reply #6 on: Nov 25th, 2015, 5:51pm » |
|
on Nov 25th, 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 25th, 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 25th, 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:
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 25th, 2015, 8:02pm » |
|
on Nov 25th, 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.
|
|
|
|
joker
Global Moderator
member is offline
Gender:
Posts: 157
|
|
Re: INI deletions
« Reply #10 on: Nov 25th, 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 25th, 2015, 9:17pm » |
|
on Nov 25th, 2015, 8:55pm, pnlawrence wrote:
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 25th, 2015, 10:30pm » |
|
Detail? Me?
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 25th, 2015, 11:04pm » |
|
on Nov 25th, 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.
|
|
|
|
Rod
Full Member
member is offline
Gender:
Posts: 110
|
|
Re: INI deletions
« Reply #14 on: Nov 26th, 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 26th, 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!
|
|
Logged
|
|
|
|
tsh73
Full Member
member is offline
Gender:
Posts: 210
|
|
Re: INI deletions
« Reply #16 on: Nov 26th, 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:
found: in %windir%
EDIT
in win2000 on virtual machine. That's what I have just now. That is,
c:\winnt
|
| « Last Edit: Nov 26th, 2015, 11:02am by tsh73 » |
Logged
|
|
|
|
joker
Global Moderator
member is offline
Gender:
Posts: 157
|
|
Re: INI deletions
« Reply #17 on: Nov 26th, 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.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: INI deletions
« Reply #18 on: Nov 26th, 2015, 11:51am » |
|
on Nov 26th, 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... 
Richard.
|
|
|
|
joker
Global Moderator
member is offline
Gender:
Posts: 157
|
|
Re: INI deletions
« Reply #19 on: Nov 26th, 2015, 12:09pm » |
|
Quote:| 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. |
|
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.
|
|
Logged
|
|
|
|
|
