Author |
Topic: INI deletions (Read 1504 times) |
|
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
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: INI deletions
« Reply #20 on: Nov 26th, 2015, 1:01pm » |
|
on Nov 26th, 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.
|
|
Logged
|
|
|
|
|
