Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (5)

Resolved Problem with SetProfileString function

  1. Issue
0
Votes
Undo
  1. Mark Howard
    Mark Howard
  2. PowerBuilder
  3. Friday, 20 September 2019 22:03 PM UTC

I'm using Powerbuilder 12.0 and have run into an issue where the SetProfileString command is being ignored on one particular windows 10 computer.  It does not return a -1 return code,  it just doesn't update the .ini file.

Even setting the .ini file to Read Only does not cause the call to fail.

Has anybody experienced an issue with this function?

Thanks in advance,

Mark

PowerBuilder 12.5.2 - Outlook 365
Regarding Winsock API
Accepted Answer
John Fauss
John Fauss Accepted Answer Pending Moderation
  1. Tuesday, 24 September 2019 02:24 AM UTC
  2. PowerBuilder
  3. # Permalink

I found a fairly concise summary of how the Virtual Store works on the web. Windows intercepts write requests to the Program Files and Program Files (x86) folders when the user does NOT have Admin rights, redirecting the request to the protected, hidden folder that serves as the user's Virtual Store. Similar action is taken by Windows when a read is requested.

So it appears that this behavior has nothing to do with write-protection at either the folder or file level, and everything to do with the UAC and Admin rights.

You might want to refactor this feature in your app to use the Registry instead of an INI file, or write/read the INI file from a user-specific folder, such as C:\Users\(username)\AppData\Local instead of the Program Files (x86) folder.

HTH...John

Comment
David Peace (Powersoft)
  1. David Peace (Powersoft)
  2. Wednesday, 25 September 2019 13:44 PM UTC
John is absolutely correct, under normal windows operation you cannot change the contents on the INI file under Program Files, this will create a user specific copy of the file in their Virtual Store. In a modern windows environment (by that I mean Windows 7 upwards) you should not code in this way. Your INI file should be for global application parameters for all users and cannot be changed in the application. The CurrentUser registry should be use for user specific parameters OR put both in your database and make like simpler.
  1. Helpful
Mark Howard
  1. Mark Howard
  2. Wednesday, 25 September 2019 17:29 PM UTC
Unfortunately, I'm dealing with a legacy system that is using PDF995 to create PDF files on the fly. I works by setting values in the PDF995.ini files, which is under Program Files(X86) of course, to the directory and file name to be saved.

The odd thing is that it is working for several installs but not for one particular user. Any ideas?
  1. Helpful
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Wednesday, 25 September 2019 17:34 PM UTC
Hi David;

I agree with John 100% with using the "C:\Users\(username)\AppData\Local" path instead of local to the App (however the VirtualStore should make that work 100% as well under the "Program Files (X86)" folder).

I would disagree though with the recommendation to use the O/S Registry. There are dangers in the 32 vs 64 side of the registry and even more serious, is the restriction on the Registry Read and/or Write based on a Windows "Policy" restrictions (burned on that myself many times - LOL). The latter being very common where many business users do not have write authorization to the O/S registry. Food for thought.

Regards ... Chris
  1. Helpful
There are no comments made yet.
Responses (5)
John Fauss
John Fauss Accepted Answer Pending Moderation
  1. Thursday, 26 September 2019 02:09 AM UTC
  2. PowerBuilder
  3. # 1

Mark, have you verified the supposition that the behavior experienced the "failing" user is because this user does NOT have Admin rights? That would be my first step.

If this is indeed the case, verify the Admin rights for the other users that are "working".

Once the cause is verified, grant Admin rights to the one user.

Alternatively, does the app and the PDF995 product have to be installed in C:\Program Files (x86)? There are alternative locations, you know.

 

Comment
There are no comments made yet.
Mark Howard
Mark Howard Accepted Answer Pending Moderation
  1. Monday, 23 September 2019 14:33 PM UTC
  2. PowerBuilder
  3. # 2

I did check that the file is writable.  The strange thing is that the SetProfileString function returns a successful return code whether I mark the file as ReadOnly or not.  It's as if the function is completely ignored.

Comment
There are no comments made yet.
Arthur Hefti
Arthur Hefti Accepted Answer Pending Moderation
  1. Saturday, 21 September 2019 03:22 AM UTC
  2. PowerBuilder
  3. # 3

I assume your application doesn't have the right to write in the current folder. Check out the Virtual Store at %localappdata%\VirtualStore. A copy of your ini file is saved there.

If your application resides in C:\Program Files (x86)\MyApplication you will find the INI file in the subfolder Program Files (x86)\MyApplication in the virtual store.

Regards
Arthur

Comment
Mark Howard
  1. Mark Howard
  2. Monday, 23 September 2019 19:03 PM UTC
Thank you Arthur. The .ini file was found to be updating in the VirtualStore on the users computer. Is that a setting specific to a machine that would cause that? We have other users with the same setup that work fine?

i.e. the file is under c:/program files(x86) and while the directory isn't writable, the file is.



thanks again...
  1. Helpful
There are no comments made yet.
Chris Pollach @Appeon
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Saturday, 21 September 2019 02:43 AM UTC
  2. PowerBuilder
  3. # 4

Hi Mark;

  Most likely, the INI file and/or Folder it resides in is "write protected".

Regards ... Chris

Comment
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.