×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Contact US

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Problem with SET DEFAULT TO
2

Problem with SET DEFAULT TO

Problem with SET DEFAULT TO

(OP)
In my app ( written 10+ years ago and now being revised and checked) I have a need to change the default folder on a number of occasions. I use SET DEFAULT TO (cNewfolder) and this works on every occasion except one which I am now trying to resolve. I need to be placed in a certain folder in this instance to make a backup of an ini file before changing the current ini in a certain way - allowing the current ini to be restored later.
I don't know if this is the problem but the path required is like
C:\Users\username\AppData\Roaming\the_target_ini_appnameI am unable to set my default to this folder to backup the ini file which resides there using COPY FILE (file1) to backupfile1.txt.
Can anyone advise me on this?

GenDev
Adelaide
South Australia

RE: Problem with SET DEFAULT TO

What's the actual error and when does it occur? Already when you SET DEFAULT or when you COPY FILE?

Chriss

RE: Problem with SET DEFAULT TO

Try this.

*-- Save current directory
lc_currdir = SET("default") + CURDIR()

DO whatever...
...
...
*-- restore to prior directory
SET DEFAULT TO &lc_currdir

Hope this helps.

Edgar
Integrated Bar Code Systems, Inc.

RE: Problem with SET DEFAULT TO

Hi GenDev,

I hope you changed "username" in your command to the actual name of your user.

Regards, Gerrit

RE: Problem with SET DEFAULT TO

(OP)
Hi Chriss

You said "What's the actual error and when does it occur?"

There is no error generated - observing what happens in the Debugger shows no change in path with curdir() so the copy just has no effect.

Gendev

RE: Problem with SET DEFAULT TO

(OP)
Hi fitedgar

My problem is that my system will not set default to the required folder as specified.

Hi Gerrit
Of course <G>


Gendev

RE: Problem with SET DEFAULT TO

(OP)
I have set up a list of set default statements to test the operation and output the result of curdir() after the command.
Allworks as expected except the last statement which is the one I have quoted above. As you can see the path is not changed and curdir() returns the previous path still.


GenDev

RE: Problem with SET DEFAULT TO

(OP)
I am obviously unable to do what I was trying to do so I have found another way to accomplish what I was trying to do - thanks to all who replied.

Gendev

RE: Problem with SET DEFAULT TO

Quote (gendev)

no change in path with curdir() so the copy just has no effect
Werll, that's interesting. Because if the directory doesn't change, then either SET DEFAULT would error "Invalid path" or COPY FILE would error "File not found", because how could the copy not error when trying to copy an ini that's not in the path, which you proved is not changing to the Roaming user profile directory.

So I assume you do something like ON ERROR *, suppressing errors. That way you don't find and fix errors.

Well, as you found a solution, it's not necessary to dive deeper.

Chriss

RE: Problem with SET DEFAULT TO

(OP)
Hi Chriss,

I have no intention to hide errors - the only error report I have ever seen has been Table Error.
The bad path and FILE COPY just jumped past in the deugger with no visible output.


My errorhandler which I found and copied from this forum 10+ years ago is

Procedure errHandler
Parameter merror, Mess, mess1, mprog, mlineno
Local myMessage,myactualpath

myactualpath = Curdir()


myMessage=;
'Program with error: ' + mprog + Chr(13);
+'Error number: ' + Ltrim(Str(merror))+ Chr(13) ;
+ 'Error message: ' + Mess + Chr(13) ;
+ 'Line of code with error: ' + mess1 + Chr(13);
+ 'Line number of error: ' + Ltrim(Str(mlineno))+ Chr(13);
+ 'Current Path in Use : ' + myactualpath;




myReport =Chr(13)+ Chr(10) + Dmy(Date())+ ' ' + Time()+ Chr(13)+ Chr(10) ;
+'Error number: ' + Ltrim(Str(merror))+ Chr(13)+ Chr(10) ;
+ 'Error message: ' + Mess + Chr(13)+ Chr(10) ;
+ 'Line of code with error: ' + mess1 + Chr(13)+ Chr(10);
+ 'Line number of error: ' + Ltrim(Str(mlineno)) ;
+ Chr(13) +Chr(10);
+ 'Program with error: ' + mprog + Chr(13) + Chr(10);
+ 'Current Path in Use : ' + Curdir() + Chr(13) + Chr(10);
+ '***********************END*****************************';
+ Chr(13)+Chr(10);


If ! Empty(Alias())
myMessage = myMessage + Chr(13)+Chr(10) + ;
'Current ALIAS in Use : ' + Alias()
Do Case
Case Eof()
myMessage = myMessage + Chr(13)+Chr(10) + "EOF"
Case Bof()
myMessage = myMessage + Chr(13)+Chr(10) + "BOF"
Otherwise
myMessage = myMessage + Chr(13)+Chr(10) +;
"RECNO: " + Alltrim(Str(Recno()))
Endcase

Endif


=Messagebox(myMessage,16,"ERROR !!!")

If File('errors.dat') && Does file exist?
Strtofile(myReport,'errors.dat',.T.)
gnErrFile = Fopen('errors.dat',12) && If so, open read-write
Else
gnErrFile = Fcreate('errors.dat') && If not, create it
Strtofile(myReport,'errors.dat',.T.)
Endif


If gnErrFile < 0 && Check for error opening file
Wait 'Cannot open or create output file' Window Nowait
Else && If no error, move to eof write to file
= Fseek(gnErrFile, 2)
Strtran(myMessage,myMessage," ")
=Fwrite(gnErrFile , myReport)

Endif
=Fclose(gnErrFile ) && Close file


logging(myReport)
Set Defa To (myactualpath)
Endproc

called in main.prg by

On Error Do errHandler With ;
ERROR( ), Message( ), Message(1), Program( ), Lineno( )


RE: Problem with SET DEFAULT TO

(OP)
Chriss,

As it happens I just got an error and an error message


So my errorhandler works correctly - so why no message when I tried to change to the path mentioned above and the COPY FILE command.

Strange.

GenDev

RE: Problem with SET DEFAULT TO

Do you also log these messages, or just display them? You can easily click on OK as reflex action or even just have SPACE in the keyboard buffer and therefor "click" OK without consciously perceiving such messages.

Good, that you have such an error handling. It seems you have a lot of pathing issues not finding files. Are you aware that on older systems (Win 95/98/XP) you don't have C:\Users? You might fail on assuming the profile location. There are system functions to determine system paths. What is unfortunate is that those functions changed also when the system paths changed, so having code that would work in XP and earlier wouldn't work on Vista and later, that makes it quite cumbersome, but you also have the GETENV("USERPROFILE") value that works on all OS versions to at least give the profile base path. I'm not sure the roaming part always is in the \AppData\Roaming\ subdirectory from there, though. The other thing to make use of is VFPs function OS(), that you can use to make the correct declarations of API functions and calls to determine system directories depßending on which OS your EXE runs. Not the simplest topic.

Edit: Another issue I see is that roming profiles are not necessarily enabled/existing. I assume you know you can work with a roaming profile, though, and you want to use that user specific system directory. GetEnv("APPDATA") might be better usable in any case. To me it is indeed my profiles roaming subdirectory, indepent of OS version it is the directory where applications should create their own application and user dependent directory and files within that. I'm not sure that you can always write into that directory.

Chriss

RE: Problem with SET DEFAULT TO

Thinking somewhat "outside the box" here :) Have you ever considered NOT using Windows stupid directory system?
At my around 50 installations all over Sweden, everything is on a directory on a server.
Inside that directory I have subdirectories like for example:

DATA
REPORTS
IN
OUT

And so on. All of those are found by the app by SET PATH TO

My 2 cents...

RE: Problem with SET DEFAULT TO

gendev,

Sorry, I overlooked your erorr handling code. It is appending to an error.dat file. Have you looked into that?

Chriss

RE: Problem with SET DEFAULT TO

It would also be helpful to see the code chaging default and copy file in a bigger context. Does it run within a TRY CATCH block?

Before you answer "no", be aware that doing something like

CODE -->

TRY
Do some.prg
CATCH
*
ENDTRY 
Any error happening in some.prg would be catched by the catch block in this code section, which obviously can be in any other PRG.

Chriss

RE: Problem with SET DEFAULT TO

(OP)
I now find that my solution to my path problem did not work out.
As a test of getting to the required path I used CD to walk down the required path.
That worked perfectly until it got to the required folder when it again didn't move to the folder.
I am trying to modify an ini file that is used by TMG ( saving/modifying/restoring).
Using the full path name does not work in a COPY FILE so I need to be in the folder I can't get to.
<sigh>

GenDev

RE: Problem with SET DEFAULT TO

Hello,

I remember a limit of folder depths + filename : 256, maybe you hit it

regards
tom

RE: Problem with SET DEFAULT TO

Quote:

Using the full path name does not work in a COPY FILE
Wrong, COPY FILE allows you to provide a fully qualified file name (i.e. with path).

It can also be relative to the current directory, therefore the pure file name works, when you first SET DEFAULT or CD (they both do the same, by the way, there is no difference of CD to SET DEFAULT)., but you don't have to change directory.

You could have the problem Tom mentions.

Chriss

RE: Problem with SET DEFAULT TO

Another wild guess,

What is the exact length of you COPY command?

Regards, Gerrit

RE: Problem with SET DEFAULT TO

(OP)
Gerrit,
Using LEN on the filename states 53 chrs.

GenDev

RE: Problem with SET DEFAULT TO

Just to prove the point you can copy files with full path, try out this:

CODE

lcSourceFile = AddBS(Home())+"redist.txt"
lcDestFile = AddBS(GetEnv("TEMP"))+"redist.txt"
? File(lcSourceFile)
? File(lcDestFile)
COPY FILE (lcSourceFile) to (lcDestFile)
? File(lcDestFile) 

This obviously only runs within VFP, where HOME() is pointing the the installation directory of VFP containing the redist.txt, but shouldn't be a problem, should it?
Expected output is
.T. (redist.txt exists in Home())
.F. (redist.txt is not in TEMP)
.T. (redist.txt was copied to TEMP) 

Chriss

RE: Problem with SET DEFAULT TO

Hi Gendev,

I was wondering about the length of the entire copy command, not just the filename.

Regards Gerrit

RE: Problem with SET DEFAULT TO

Just a thought:

The pu8rpose of a roaming profile is, that it roams with a user. What would it be worth a profile roams, if you (or any application using profile specific files) would need to know whether the user roams or uses his usual workstation? Shouldn't Windows mirror the usual profile into the roaming folder and after it was travelling via storage on a domain controller to another workstation mirror it back into the "normal" location of user profile, the local profile?

Maybe it was never necessary to write directly into the roaming subfolder, as the only use for it is to let the profile files roam from one to any workstation, not to be used, so the roaming folder is just the mirrored local profile and not meant to be used. If you do so, your changes obviously also roam, so no harm is done by what you did earlier - but from what I read so far I think it's true Microsoft decided to reduce permissions of that, so you're nudged towards using the usual profile files as a developer.

Well, if my thought bears any meaning, I think you would find a copy of the INI of TMG.exe somewhere outside the roaming folder and the EXE likely reads that in.

Chriss

RE: Problem with SET DEFAULT TO

(OP)
Chriss,
1.
I added
SET DEFAULT TO AddBS(GetEnv("TEMP"))
success=File(lcDestFile)
and success = .T.
2
C>the EXE likely reads that in.

That was why I was asking about the utility to investigate exactly that.
However, both TMG and my program 'use' roaming profiles as do many other programs I have installed on my PC.
TMG does have an ini in the program files folder along with its exe but the one in the roaming folder contains the details of the latest usage of the TMG program ( which is why I want to access it).
So at the moment it looks like I will not be able to modify the TMG ini file. <sigh>

3
Both TMG and my program are designed to run on a users home PC (Genealogists who in the main know little of the 'innards' of a PC.
GenDev

RE: Problem with SET DEFAULT TO

(OP)
Gerrit
G> I was wondering about the length of the entire copy command, not just the filename.
Sorry, I don't follow?

GenDev

RE: Problem with SET DEFAULT TO

Quote (gendev)

Both TMG and my program are designed to run on a users home PC

Well, that's not necessarily natural, good that you say so.

In your first post you mentioned

Quote:

C:\Users\username\AppData\Roaming\
Roaming profiles are only a thing in a network of a company, where a user can roam from onw workstation to another and still have his user profile, his personal settings and many more user specific files available no matter where he logs in.

So it is very questionable that you ever needed access to a Roaming subfolder of the user profile.

It could be very handy to know where TMG.exe actually reads its own INI from. Even if one exists in C:\Users\username\AppData\Roaming\ for whatever reason, it may not even be used. Not in a standalone PC that doesn't have anything like roaming profiles.

So the idea you had in your other thread to determine which files a process accesses is not bad. I and others told you Sysinternal procmon can show that, did you investigate in that direction to see whicdh INI TMG.exe loads?

Chriss

PS: To relativate what's available and what not. On a standalone notebook I use my local user profile folder in C:\Users\profilename also has C:\Users\profilename\AppData\Roaming and there are some folders of companies (Microsoft, for example) and applications (Notepad++) for example. I can read and write in these third party application folders both as a user using Windows Explorer and with VFP. I'm on Windows 10, though.

So either Windows 11 changed this to become private to users and applications or its soimething that the TMG.exe does to it's own files, perhaps you also can read/write the INI as long as TMG.exe runs and not, if it is started, when it perhaps opens its own INI file with exclusive access.

For Notepad++ I don't see a corresponding appdata folder in the Local and LocalLow subdirectories. So this application decides to use the Roaming subdirectory only. Why does it even exist on a standalone PC? I can't really tell you what's on the mind of MS about this, but I guess that's for simplyfying the roaming feature once the PC would join a network. Anyway, it is indeed not only existing for networked computers, that's right.

The last thing I read your code didn't manage here or in your other thread is even just reading the INI file and copying it elsewhere. If that also didn't cause any error I'm quite stumped, so the last direction we can go for is finding out whether TMG.exe reads its INI from there or elsewhere.

If you're then locked out of the directory or file, your last chance still is providing an EXE, maybe a separate module, that requires the user to have adminstrative permissions so you can try to access the folder that's protected. Unless there's really a simple reason like a typo in the path or file name that sneaked in with any recent edit, unintended.

RE: Problem with SET DEFAULT TO

(OP)
Chriss,

AS I mentioned in the other thread it is clear/certain that TMG uses the ini in the roaming folder.
I'm not sure the definition of roaming folders as used on a network is what I am describing here.

As a second evidence both TMG and my app install with roaming folders under users/username/appdata/roaming on my notebook so I am convinced this is the normal case thus valid in my thoughts of wanting to access the tmg app.ini there.

I have process monitor installed but haven't yet been able to see what additional files an exe uses. I did do this before so i will probably get there soon

GenDev.

RE: Problem with SET DEFAULT TO

Okay, it's still more appropriate for a non networked and thus local application to use {localappdata} instead of {userappdata} - speaking in terms of Inno Setup constants, no matter what other Software does.

It's not a showstopper usualy, it seems - see my edited previous post. But all your test results indicate either Windows 11 or TMG are protecting their application data folder from access of other applications, doesn't it? If not by default and since you installed them but just recently. Anything that's not your code can change at any time, can't it?

So focus on the current situation, not the fact "it worked before", it's just not getting you forward, is it?

From the pure perspective of coding things you do what you did, you set variables to the fully qulified names (path+filename) or path only and then either

CODE

COPY FILE (lcSourceFile) TO (lcDestinationfile) 
or using separation of paths and file names:

CODE

SET DEFAULT TO (lcPath)
COPY FILE (lcSourceFile) TO (lcDestinationfile) 
This time only the file names in lcSourceFile and lcDestinationfile - "your.ini" and "backupyour.ini", for example.

The brackets indicate to VFP that you don't literally mean files named like the variables - that's what VFP would interpret and do if you leave off the brackets, it also makes it possible to use paths and filenames with spaces. So from that perspective everything is fine with your code. But something is wrong and it's hard to tell from here without having hands on your computer and full code.

Since the code is okay, it can only fail on wrong values, permisssions, non existing directories, protected/hidden directories, files in exclusive use, and maybe more reasons, just because code once ran, that's not putting you in a futureproof situation, when influences from outside have an effect. So you could make code much more cautious in checking assumptions:

CODE

*assumed: lcPath, lcSourceFile and lcDestinationfile are set as wanted/needed
IF DIRECTORY(lcPath)
   SET DEFAULT TO (lcPath)
   IF ADIR(laDummy,lcSourceFile)=1
      IF ADIR(laDummy,lcDestinationfile)=0 OR Set('Safety')=='OFF' && important, upercase OFF.
         * Copy file with local error handling
         TRY
            COPY FILE (lcSourceFile) TO (lcDestinationfile)
         CATCH TO loException
            Messagebox("Copying file failed due to Error:"+CHR(13)+CHR(10)+loException.Message)
         ENDTRY
      ELSE
         Messagebox("Destination File "+lcDestinationfile+" already exists. Copy File would fail to overwrite it as SAFETY is ON.")
      ENDIF
   ELSE
      Messagebox("Source File "+lcSourceFile+" not found.")
   ENDIF
Else
   Messagebox(lcPath+' does not exist or is a hidden or system directory.')
Endif 

You can see from this how a centralized error handler shortens code as you (usually) will be informed about what's not working with path or filenames when you just do SET PATH and COPY FILE instead. But something is ill with your situation, if this code yields some messages that should have triggered your error handling, or your error handling is not yet initialized when you do this in an early application state, whatever. But you could try this code to see what it brings up.

Chriss

RE: Problem with SET DEFAULT TO

One detail aspect, notice the help topic about DIRECTORY() and its second parameter, that can be used optionally, set to 1:

CODE

? Directory(GetEnv("USERPROFILE")+'\AppData') && results in .F., usually, as AppData is a hidden folder
? Directory(GetEnv("USERPROFILE")+'\AppData',1) && results in .T., as this disregards the hidden status.
? Directory(GetEnv("USERPROFILE")+'\AppData\Local') && .T. - works regardless of AppData being hidden, as the Local folder isn't hidden.
? Directory(GetEnv("USERPROFILE")+'\AppData\Roaming') && .T. - dito for Roaming. 

So it's not just better to use Directory(lcDir,1) always, because if you would want to copy from or into the hidden directoy itself, VFP would respect the hidden status and decidedly fail, even if files and directories exist just hidden. Therefore the longwinded code does check Directory(lcPath), not Directory(lcPath,1). It makes no sense if the hidden attribute wouldn't have any effect. The way Windows handles its hidden folders is not as strict as they could be, you can configure the options for Windows Explorer to show hidden folders with a fainter yellow color´and allow navigating into them, too. So the hidden status is mainly a guidance of the normal user that doesn't set this up for himself, but once you know a non hidden subfolder within a hidden folder you're in safe territory again and (usually) don't need special permissions, unless a folder like Program Files is write protected anyway, no matter that it's not hidden.

Chriss

RE: Problem with SET DEFAULT TO

(OP)
Chriss,
So the result of your code is
lcPath+' does not exist or is a hidden or system directory.'

I substituteg

IF DIRECTORY(lcPath,1)
SET DEFAULT TO (lcPath)

and the command is ignored with no error msg and path remains as it was before the command. ( as before)

Investigating the roaming folder itself with TMG loaded and pathwiz the same and I get the following screens



The access 'ticks' show exactly the same density as a folder on my 'spare' SSD that pathwiz operates from.

I changed the read only check box to clear and tried again - same result.
So- 'up a creek without a paddle' I guess, unless I've misunderstood some of your wonderful comments.

GenDev

RE: Problem with SET DEFAULT TO

(OP)
Chriss,

Just to clean up the query about TMG app.ini



and PathWiz being able to write to its roaming folder



and my ini file



GenDev

RE: Problem with SET DEFAULT TO

Quote (gendev)

So the result of your code is
lcPath+' does not exist or is a hidden or system directory.'

For which lcPath?

This does not help, gendev. It would be easier to post the screenshot of the Messgebox.

Quote (gendev)

I substituteg

IF DIRECTORY(lcPath,1)
SET DEFAULT TO (lcPath)

Have you read what I wrote?

Quote (quote myself)

So it's not just better to use Directory(lcDir,1) always, because if you would want to copy from or into the hidden directoy itself, VFP would respect the hidden status and decidedly fail, even if files and directories exist just hidden

Seems to me, the path you want to change to is hidden and thus even though it exists, VFP wouldn't write into it, maybe not even re<d from it. Your change to DIRECTORY(lcPath,1) does only change that DIRECTORY will report the path as existing. For VFP to work within that folder it would need to be unhidden, and you can't change by changing permissions.

Chriss

RE: Problem with SET DEFAULT TO

I tested what in detail happens in a hidden folder.

SET DEFAULT TO (hiddenfolder) works without error.
COPY FILE (fileinhiddenfolder) to (backupfilename) also works without error.
And also, both do their job.

So VFP does only respect the hidden attribute in terms of denying the existence of the folder, not working within it.
So what's really the problem with your case, then?

Is it perhaps just your way to verify the existence of the backup file, that's wrong?

Chriss

RE: Problem with SET DEFAULT TO

(OP)
Chriss,

Your results are disheartening on one hand and pleasing in another.
I just can't replicate your results so I'm not sure where to from here.
No matter what I do I cannot get DEFA To - to curdir() to the required folder ( although my folders have the hidden
attribute removed.
I do not see the backup file either so it's not working for me as shown by your code I cut into my program.
Maybe someone else can confirm your results.

Cheers
GenDev

RE: Problem with SET DEFAULT TO

The one thing that makes me question now is - of course, how else could it be - about the unknonw lcPath.

If the change of DIRECTORY(lcPath) to DIRECTORY(lcPath,1) did help to go on with my code, then lcPath must be a hidden or system path the DIRECTORY function reports as non existing, unless you force it with ...,1).

I wonder why that would be the case as you want to change directory to the folder that has the INI within it, and that seems to be C:\Users\bryan\AppData\Roaming\pathwiz11, not C:\Users\bryan\AppData\Roaming.

Why are you showing all details about C:\Users\bryan\AppData\Roaming, as it is C:\Users\bryan\AppData\Roaming\pathwiz11 that is of interest, isn't it?

Chriss

RE: Problem with SET DEFAULT TO

Quote (gendev)

I do not see the backup file eithe
Do you look at the right place? I know, that's assuming you don't knopw what you're doing, but coming back to UAC, a file you write into a system folder can be redirected into somewhere within

Making the backup copy also is just the first step before you change the INI and thereby influence the TMG9.exe

What about verifying the copy by code?

CODE

SET DEFAULT TO (lcPath)
COPY FILE (lcSourceFile) TO (lcTargetFile)
IF FILETOSTR(lcSourceFile) == FILETOSTR(lcTargetFile) 
   MESSAGEBOX("COPY succeeded.")
ELSE
   MESSAGEBOX("COPY didn't succeed.")
ENDIF 

Besides that, you still owe some answers to questions.

Chriss

RE: Problem with SET DEFAULT TO

(OP)
Chriss,
As a start today
C> 1 Why are you showing all details about C:\Users\bryan\AppData\Roaming,
2 as it is C:\Users\bryan\AppData\Roaming\pathwiz11 that is of interest, isn't it?

1 Showing PathWiz accessing its own ini file

2 The ini I am wanting to modify is in my fist image above
C:\Users\bryan\AppData\Roaming\The Master Genealogist v9
At the monent I am not sure what other answers you need. I'll look back today and see if I can locate anything.

Cutting your new code into my app I get
Store .T. To lTableError
at the SET DEFAULT TO (lcPath) command.
Where lcPath is the TMG one shown above

GenDev

RE: Problem with SET DEFAULT TO

(OP)
This afternoon I no longer get the error on SET DEFAULT TO (lcPath) command.
tcFilename1 = app.ini
savedfile1 = oldappini.txt
The debugger (see image)passes through with the claimed result as shown. Note the curdir() on the Watch window.
Using wizfile it is clear despite the vfp message no file was created.




GenDev

RE: Problem with SET DEFAULT TO

I'd trust FILETOSTR(lcSourceFile) == FILETOSTR(lcTargetFile) much more than any third party tool.

What are you searching with wizfile - and where are you searching?

Get real, open up Windows Explorer, look into the directoy C:\Users\bryan\AppData\Roaming\pathwiz11
And see if you find the app.ini and the oldappini.txt

Or add this code:

CODE -->

SET DEFAULT TO (lcPath)
COPY FILE (lcSourceFile) TO (lcTargetFile)
IF FILETOSTR(lcSourceFile) == FILETOSTR(lcTargetFile) 
   MESSAGEBOX("COPY succeeded.")
   _dummy = GETFILE('*.txt*)
ELSE
   MESSAGEBOX("COPY didn't succeed.")
ENDIF 


If you do this, are you doing this while being logged in as "bryan"? If not, you're trying to write into someone elses user profile. If you want to test how this works for "bryan" you can only test this logged in has him or change to your own user profile for the testing. Even with admin elevation, where you could read and write, the file generated will likely end up not in the users profile but it will be generated and FILETOSTR(lcSourceFile) == FILETOSTR(lcTargetFile) proves that.

If you don't see that file within an already open Windows Explorer you have to refresh the content with F5, if it's not shown even then it's likely generated by redirection elswhere - still FILETOSTR(lcTargetFile) is able to read it in as reading also is redirected to the same place. I already mentioned UAC and VirtualStore. You had not asked back, but you don't seem to know this, although it is also about 20 years old by now, at least 18.

Besides all that, copying the app.ini is just the first step on your journey, isn't it? You then need to modify the ini and start tmg9.exe to react to the changes, i.e. changing the INI does not change anything about an already runnung TMG9.exe process - it'll not read in the ini once more just because you change it and changing it clearly won't retroactively change what has already been read from an already running TMG9.exe

Chriss

RE: Problem with SET DEFAULT TO

Here's a small demo qabout how File redisrection and your profiles VirtualStorefolder work:

Requirement: UAC (user access control) has to be turned on. It is by default, so if you don't know what UAC is, it likely is on, you can check it in Windows Control Panel -> User Accounts -> Turn UAC on or off.
Better idea: Go into Windows Settings and via the "Find a setting" search box search "UAC".

CODE

#Define CONTENT 'test'
Local lcProgramFiles, lcNewFile, lcBackupFile, lcVirtualStore

lcProgramFiles = GetEnv("ProgramFiles")
lcNewFile = lcProgramFiles+"\vfpgenerated.txt"
lcBackupFile = ForceExt(lcNewFile,"bak")

If StrToFile(CONTENT,lcNewFile)=Len(CONTENT)
   ? 'File created'
   Copy File (lcNewFile) TO (lcBackupFile)
   ? 'File copied'
EndIf

If FileToStr(lcBackupFile)== CONTENT
   ? 'Copy verified Ok'
EndIf

? File(lcBackupFile)

lcVirtualStore = GetEnv("LOCALAPPDATA")+"\VirtualStore\"+JustFname(lcProgramFiles)

* Files will not be seen here
Run /n explorer.exe "&lcProgramFiles"
* As redirection put them into your VirtualStore folder
Run /n explorer.exe "&lcVirtualStore"

* nevertheless redirection also works when reading from the path where the redirected file doesd not exis:
? lcBackupFile
? FileToStr(lcBackupFile)
? lcVirtualStore+"\vfpgenerated.bak"
? FileToStr(lcVirtualStore+"\vfpgenerated.bak") 

If you have questoins about what the oiutputs are for, please ask.

One thing to know and do is in the Windows Explorer showing the Program Files folder, you have to scroll down to see NO generated and copied file, which due to redirection is generated in the PRogram Files subfolder of the VirtualStore folder, which the seconf Windows Explorer is showing. So there you see the effect of redirection. Not only wrintg, also reading the file is redirected. Therefore the last two FILETOSTR() commands actually both read the file from the VirtualStore, even though the backup fiel does not exist at the location of lcBackupFile.

What does this mean?

It means your backup process succeeds, proven by reading in the file copy. That you don't see it, no matter if you use Windows Explorer or your Wizfile tool, because you look at the wrong place.

And why is Microsft doing this?

To keep legacy software working, or software of programmers that think their software should write into folders under system control. MS thereby lets code work without error and it works twoways, when writing and reading.

Are they doing a great service with this? If you ask me, no. Of course legacya software that can't be modified can now still work, but if you have a permission problem like that as a company with your important legcy software of which - unllike in your situation - the developer may not even live anymore - you could also solve that damn problem by giving write permission into the application folder. So it's not a big service. On top of that, change UAC from time to time, turn it off and on, and this redirection doesn't work anymore. Install a software with UAC off and then use it with UAC on, it doesn't work. There are more situations this is unhelpful than this is helpful, if you ask me.

I guess we're at a point where - at least as of today - your backup works, you still don't see it with WizFile, but that's not your problem (anymore). I think you bark up the wrong tree, as you stand in the wrong forrest. So I suggest you get to the bottom of the problem, not to solution but what actually does not work out. After 10 years, wouldn't there also be changes in TMG, maybe your INI key/value changes don't work. I hear you say TMG9.exe ist still also the old software and nothing could have changed? Are you sure it has no self updating mechanism?

All we're doing here is taking stabs in the dark, and that has to change.

Chriss

RE: Problem with SET DEFAULT TO

(OP)
Chriss,
Some answers to your questions etc
1
C> TMG9.exe is still also the old software and nothing could have changed? Are you sure it has no self updating mechanism?
No -the last exe produced is way back on 03/12/2014.Shown in properties of tmgv9.exe

2
c>I guess we're at a point where - at least as of today - your backup works,
Well, I have to disagree with that. Wizfile finds a requested file right across all drives as soon as it is created and I don't see the bak file anywhere. This takes wild cards and is hugely useful when looking for a particular file on the PC. I tested it on a file I see in a roaming folder and it finds it OK.

3
C> ? FileToStr(lcVirtualStore+"\vfpgenerated.bak") - this line in your test program generates an error.'File does not exist'

4 I have UAC on 'Never notify' - maybe I should change it to a higher setting? I don't know when this was set.

5 In your previous test code I can't get past the SET DEFA line = when I force it in the debugger I get an error on the COPY command.
6 In my folder C:\Users\bryan\AppData\Local\VirtualStore\Program Files (x86)\BeeSoft - I only see 2 entries both made some years ago.
7 In C:\Users\bryan\AppData\Local\VirtualStore - I only see folder entries from some years ago.
Regards
GenDev

RE: Problem with SET DEFAULT TO

(OP)
Chriss,

On further inspection when running your code

* Files will not be seen here <<<<<<<<<<<<<<<<<<<<<<<<<<<they are
Run /n explorer.exe "&lcProgramFiles"
* As redirection put them into your VirtualStore folder<<<<<<<<<<<<<<not visible here
Run /n explorer.exe "&lcVirtualStore"
and the end result message is


GenDev

RE: Problem with SET DEFAULT TO

Do you have UAC off?

Chriss

RE: Problem with SET DEFAULT TO

(OP)
See 4 in my post above.

GenDev

RE: Problem with SET DEFAULT TO

I'd like to know which line errors.

So rerun this:

CODE

#Define CONTENT 'test'

On Error ? Lineno(),Error(),Message()
lcSafety = Set("Safety")
Set safety off

Local lcProgramFiles, lcNewFile, lcBackupFile, lcVirtualStore

lcProgramFiles = GetEnv("ProgramFiles")
lcNewFile = lcProgramFiles+"\vfpgenerated.txt"
lcBackupFile = ForceExt(lcNewFile,"bak")

If StrToFile(CONTENT,lcNewFile)=Len(CONTENT)
   ? 'File created'
   Copy File (lcNewFile) TO (lcBackupFile)
   ? 'File copied'
EndIf

If FileToStr(lcBackupFile)== CONTENT
   ? 'Copy verified Ok'
EndIf

? File(lcBackupFile)

lcVirtualStore = GetEnv("LOCALAPPDATA")+"\VirtualStore\"+JustFname(lcProgramFiles)

* Files will not be seen here
Run /n explorer.exe "&lcProgramFiles"
* As redirection put them into your VirtualStore folder
Run /n explorer.exe "&lcVirtualStore"

* nevertheless redirection also works when reading from the path where the redirected file doesd not exis:
? lcBackupFile
? FileToStr(lcBackupFile)
? lcVirtualStore+"\vfpgenerated.bak"
? FileToStr(lcVirtualStore+"\vfpgenerated.bak")
Set Safety &lcSafety 

And then it would also help to see a screensahot of the outputs until that error happens for you.

There are other open questions, too, gendev.

Chriss

RE: Problem with SET DEFAULT TO

(OP)
Chriss,
Please see my post in the other thread.

GenDev

RE: Problem with SET DEFAULT TO

(OP)
Chriss,

I did not get an error.
Here is the output


Dinner now.

GenDev

RE: Problem with SET DEFAULT TO

Gendev,

you did get the same error, just this time it triggered the ON ERROR Code and printed the line
36 1 Flie does not exist.

Line 36 is

CODE

? FileToStr(lcVirtualStore+"\vfpgenerated.bak") 
So file redirection doesn't happen. I guess because you start the IDE/VFP9.exe itself elevated, which means it can write into Program files and writing files there is not redirected.

Okay, but forget about that. After all the suggestions made not only by me to find your problem, I think it's better to see what you actually need and trash your old code in favor of something that works. I'll make a suggestion in a separate answer, though.

Just some final pointer about that to https://learn.microsoft.com/en-us/windows/security...
Besides explaining essentially all effects of UAC, also the ones not of interest, in the section Virtualization states that:

Quote (MS)

Virtualization doesn't apply to apps that are elevated and run with a full administrative access token

That's also part of the problem that I subsumized by saying

Quote (myself)

There are more situations this is unhelpful than this is helpful, if you ask me.
One of the reasons is that when you run a setup that is not effected by file redirection as setupüs run elevated. When the application later runs under normal permissions it may be affected by redirection and having no access to files the setup successfully managed to place where the developer intended them to be, but not where an unelevated process can access them.

Don't get me wrong, I'm not saying setups shouldn't have these privileges, of course even since way before MS invented the UAC mechanism to fool help us all, the setup needs to write into Program Files, of course, besides other usually restricted places. There's an obvious way to make use of that to solve your problem, and maybe I/we should have suggested what makes your necessary code as simple as it can be: Set permissions during setup.


Chriss

RE: Problem with SET DEFAULT TO

OKay, as I said in my previous post, here's a suggested solution which could do away with all previous suggestions and questions and analysis of problems.

What would make your code a few lines that work withjout problems is simply setting permissions to files as necessary during the setup process of your software. As you are using Inno for that, I assume it's not a big deal to figure out how to script setting permissions to both files your setup puts into the installation directory of your software and also to already preexisting files like the INI of TMG9.exe, during setup you have all the power necessary to do that.

For already installed systems, this could still be done by a setup you generate as a kind of service pack. Plus: You need an upgrade setup for the new EXE with code changes, anyway.

Okay, here's what I collect from the thread you need:

1. Make a backup of the INI of TMG9.exe
2. Modify the INI
3. Start TMG9.exe while the INI has been changed
4. Reinstate the backed up INI so the next TMG9.exe start is uneffected.

All that is essentially simple code, once you have all necessary permissions:

CODE

COPY FILE (fullfilenameofINI) TO (backupfilenameofINI)
* Code to modify the INI
* Code top start TMG9.exe
COPY FILE (backupfilenameofINI) TO (fullfilenameofINI) 
COPY FILE (fullfilenameofINI) TO (backupfilenameofINI) 
If you want to stick to your old ways, you can add changing directory and setting that back instead of simply using full names. Note that the limitation of VFP to access directories with too long names applies no matter if they are fully qualified or you split up changing to a directory. As far as I see this limitation is not the reason of failing anyway.

Of course the code to modify the INI surely are a few more lines, but starting TMG9.exe likely also is just a RUN command, isn't it? So besides the INI modification it's a three liner.

And it works as long as you have write permissions to the directory and the INI file, which you can either do manually or let a setup add those permissions to the group of standard users, for example, or simply to everyone. Giving that permissions to the directory where TMG stores its INI is, of course, a bit excessive and outside your own territory, but I don't see how you can get around that anyway, even if we find out how to let UAC mechanisms do what is intended to solve the problem of legacy software without changing the software or permissions, even then you need write acccess to the INI of a third party software. No matter if you package it within your own setup or recommend users to install it alongside your application, that's strictly speaking out of your own territory, but you restore the INI anyway and you do it as a comfort function to make it easier for users, so why not.

If that idea still fails, then it may be your INI modification isn't working anymore, because TMG uses other keynames, sections or other changes of the INI meaning. That's something we didn't even get to until now.

I think that's the simplest solution, give your software the permissions it neesds during your setup/update.



Chriss

RE: Problem with SET DEFAULT TO

(OP)
Chriss,

Thanks for your assistance.
I lost my last post before posting <sigh>
C> TMG uses other keynames, sections or other changes of the INI meaning.
G>TMG ini hasn't changed since 20??.

C> Of course the code to modify the INI surely are a few more lines, but starting TMG9.exe likely also is just a RUN command, isn't it? So besides the INI modification it's a three liner.
G>Thats right - in my code.

C> give your software the permissions it needs during your setup/ - and
And it works as long as you have write permissions to the directory and the INI file,
G>Well I don't know how to do that in INNO - I'll research. But as I showed above I seem to have complete access/full control to the Roaming/TMG folder.
PS I am user bryan as an administrator on my dev PC.

GenDev

RE: Problem with SET DEFAULT TO

Bryan, a user of the administrative group on a system since Vista does not have all access permissions anywhere all the time, that's what UAC changes. You likely start VFP elevated and your EXE not, that's making a big difference.

Your exe only works, as if you where a normal user, not a user of the admin group. And that's the way since Visa.

Chriss

RE: Problem with SET DEFAULT TO

(OP)
Chriss,

C>that's making a big difference
I expect that the individual user would choose to run a program as an administrator rathger than a normal user. I am not sure how that would impact on what we are dealing with in relation to the Roaming folders?

GenDev

RE: Problem with SET DEFAULT TO

Quote (gendev)

I expect that the individual user would choose to run a program as an administrator rathger than a normal user.
I already told you that that doesn't help.

The deal with administzrative permissions since Vista is, it's not eniough to be Admin.

You can embed a manifest with an essential information, that an EXE require administrative elevation, that's described, for example, here:
https://west-wind.com/wconnect/weblog/ShowEntry.bl...

I think there's a whitepaper or blog post fromn Rick Strahl that describes this for the special usecase of easily embedding a changed manifest. What I remember is that having a file your.exe.manifest within the soma folder as the PJX and side to side by the EXE that's generated by a build, this manifest is embedded into the final EXE without needing tools like mt.exe to postprocess an EXE.

The normal manifest embedded into a VFP9 built excecutable is this:

CODE --> manifest

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity 
	version="1.0.0.0" 
	type="win32" 
	name="Microsoft.VisualFoxPro" 
	processorArchitecture="x86"
/>
<description>Visual FoxPro</description>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
	<security>
		<requestedPrivileges>
			<requestedExecutionLevel level="asInvoker" /> 
		</requestedPrivileges>
	</security>
</trustInfo>
<dependency>
    <dependentAssembly>
        <assemblyIdentity
            type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0"
            language="*"
            processorArchitecture="x86"
            publicKeyToken="6595b64144ccf1df"
        />
    </dependentAssembly>
</dependency>
</assembly> 

And what you need to enforce an EXE to run elevated is a changed manifest in the security section:

CODE --> priviledges

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity 
	version="1.0.0.0" 
	type="win32" 
	name="Microsoft.VisualFoxPro" 
	processorArchitecture="x86"
/>
<description>Visual FoxPro</description>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
	<security>
           <requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
             <requestedExecutionLevel level="requireAdministrator"
                                      uiAccess="false" />
             </requestedPrivileges>
        </security>
</trustInfo>
<dependency>
    <dependentAssembly>
        <assemblyIdentity
            type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0"
            language="*"
            processorArchitecture="x86"
            publicKeyToken="6595b64144ccf1df"
        />
    </dependentAssembly>
</dependency>
</assembly> 

Either that, or you create a shortcut to the EXE that runs it "as Adminsitrator", which means an elevation dialog will appear at the start.
Notice: This will not automatically give the process with that manifest an elevated status, the requireAdin means Windows will ask the user to allow this, if he's a user of the administrative group or show a login, with which a user could switch the invoker of the EXE to be an adminstrative user, which also requires the password for that administrative user, so the minfest is not elvation in itself or a free ticket. I don't know from the top of my head if the EXE would run anyway, without elevation and with all limits that has or whether it would then not start at all.

But to get to the essntial point of the reason such manifest and their security tags were introduced: An admin is not running anything as an admin anymore, that's a changed security concept since Vista. If you don't believe me, than I can't help you. Let me see if I can find it explained in mopre detail and officially from MS:
https://learn.microsoft.com/en-us/windows/security...

Hm, well, this is the link I posted earlier, already. I don't know why you ignore so much that's already told to you. I think you can't believe it since you know otherwise. Yes, it was otherwise before Vista, but not since Vista, and Vista was released 2006.

You have configured your UAC setting to "never ask", so you're suppressing some things, but you can't expect anybody to have your setting. And your setting also doesn't make the admin exyperience 100% as it was befrope Vista, you just don't realize when you're elevated and likewise when not.

You should always program in a way a normal user can use your application, otherwise you're undermining the security of the users system. So I explicitly tell this here: While I show how you can embed a manifest that will make it easy for adminstrative users, this should only be foreseen within executables that have an adminstrative nature, not for a normal application. You can set permissions on just the one INI and its folder and thereby also act in foreign territory of TMG, but limit your intrusion into the security decisions of a user or MS to an acceptable level. So I'd still recommend that.

In short: I wouldn't use an application that asks me to elevate it at the start, other than a setup I verify by signature or at least checksum to be a trustworthy unmanipulated setup. Other things like sysinternal tools or other adminstrative tools, but not a normal application. Get it done in a way a normal user can use your application.

Chriss

RE: Problem with SET DEFAULT TO

One more thing: You can easily determine the elevated status of an EXE (or also for the VFP IDE, for what it's worth) with an easy call af a Windows API function IsUSerAdmin (part of shell32):

If you google for it you see it mentioned in a white paper by Doug Hennig and in blog posts of Rick Strahl, too, with added checks whether the function exists in the shell32 system DLL. Well, since Vista it does and I don't see a reason to check for XP or earlier anymore. But OS() could help with that, too.

Anyway, the core thing this would help with is verifying that an EXE with a manifest requiring administrative elevation actually is elevated. So if you need to ensure you, you can be double sure about it.

There's another way to manually see this in the task manager process list, you can add a column "Elevated" besides "UAC virtualisation":


Here you can see I started two sessions of VFP9.exe with the same user account, once elevated and once not.
Executing this in both sessions I get the following result:

CODE

Declare Integer IsUserAnAdmin In shell32
? _vfp.processid, IsUserAnAdmin() 



This shows:
1. IsUserAnAdmin() reflects the elevated status of the current process (0=No, 1=Yes, also compare the processid=PID from task manager and VFP screenshots).
2. IsUserAnAdmin() differs and is not just telling whether the user (in both cases my user account ChrissM) is in the admin group or not.
3. Obvious from both 1 and 2: A process does not automatically gets the users' privileges.

Chriss

RE: Problem with SET DEFAULT TO

(OP)
Chriss,
I see the results shown above in your post when I open vfp 2 ways however I don't see the Task Manager/Details column on UACsettings.
So using the vfp9.exe process in the Task Manager and selecting Properties/Compatibity - I can see Run as Administrator but no option to add UAC settings.
From all of your excellent content above I have the following questions
. Should I normally run vfp9.exe as administrator?
. Should I normally use UAC to the full?
.Should I add your manifest file when compiling?
.Can I really set INNO to allow me to read and write into the Roaming/TMG folder?

As an 82 year old I am doing my best to follow your writings.
Regards
GenDev

RE: Problem with SET DEFAULT TO

0. I don't see the Task Manager/Details column on UACsettings.

I said you can add a column "Elevated" besides "UAC virtualisation". Right click on the column headers and pick "Select columns" from the context menu. then check the columns you want to see.

1. Should I normally run vfp9.exe as administrator?

You can, you don't need to. One advantage is olepublic classses will be registere, when you compile. One disadvantage is, you can't test under real conditions as an elevated process can do things an unelevated EXE can't. So there will be a discrepancy from testing vs later EXE functionalities.

2. UAC is your decision, For security you have it at it's default or stricter, you loosened it. Make what you want of it. Just like 1 it adds to the discrepancy of test vs reality, not on your development computer, but in comparison to the rest of the world.

In summary to both 1 and 2. All settings can make sense, why would they be configurable if only one option or combination nmakes sense? It depends. Make everything with an awareness. Your questions indicate you don't want to decide and get a recommendation instead, I have to disappoint you, depending on what you do and want to test all things make sense.

3. Should I add your manifest file when compiling?
I alread answereed that question, please jhust reread.

4. Can I really set INNO to allow me to read and write into the Roaming/TMG folder?

Yes, setting permissions on files is a normal feature of any setup tool. Again, I already told everything about this in my recommendation to not use the modified manifest, even though I showed it to put all the options on the table and get into your head that an admin account isn't the same thing as it was previous to Vista, the manifest is also a new feature that - again - was introduced with the major changes MS mnade to Windows with Vista.

Chriss

RE: Problem with SET DEFAULT TO

(OP)
Chriss,
Task Manager in WIN 11 does not offer the UAC info column - I wonder why? I see it on wife's WIN 10 Task Manager.

I have added the IsUserAnAdmin output to my log file -
(extract from log)
21:23:08 Starting PathWiz! ver. 11.0.0 20240611_at_21-23
21:23:08 Operating System - Windows WIN64 bit
20:59:27 Computer details
20:59:30 CurrentClockSpeed: 3101
20:59:30 Manufacturer: GenuineIntel
20:59:30 MaxClockSpeed: 3101
20:59:30 Name: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz
20:59:30 Current Display Resolution : 1920 x 1080
20:59:30 PID 2676 User <<<<<<<<<<<<<<<<<<<<<( Note other option Administrator)
21:23:09 C Local hard drive
21:23:09 D Local hard drive
21:23:09 I Local hard drive
21:23:09 P Local hard drive
21:23:09 T Local hard drive
21:23:09 U Local hard drive
21:23:09 Z CD ROM drive
21:23:09 Strings Date is 06-Apr-10
21:23:10 Splash screen closed
21:23:13 Log File View


I see no change whether PathWiz is started elevated or not.

GenDev

RE: Problem with SET DEFAULT TO

Whoi talked about PathWiz?

Chriss

RE: Problem with SET DEFAULT TO

(OP)
Chriss,

I have mentioned Pathwiz before in this thread. It is my application which ideally can access the roaming/TMG folder to modify the tmg.ini file.
FYI The WIN 10 version of Task Manager is available in WIN11 at C:\Windows\SysWOW64\Taskmgr.exe - to get the UAC virtualisation state on a process under the Details tab.

GenDev

RE: Problem with SET DEFAULT TO

Gendev, thanks for the clarifications.

You mentioned Pathwiz before, yes, but that's the first time I hear this is the name of your own application. Also, I confused it with WizFile, the tool you mentioned somewhere and showed a screenshot.

Okay, so you tried to use your own application elevated and this doesn't solve access to files.

Still, the now golden final idea of creating a setup that sets permissions on the folders and files you need to access to a) backup the tmg ini b) change the TMG ini will neither need elevation nor admin permissions, because giving the permissions to normal users will cover any situation. You don't seem to realize that I consider this suggestion the straight forward solution as it makes everything independent of several other settings, it also won't matter then, whether UAC is on or off, strict or loose. You simply have permissons on the files and folders, SET DEFAULT, copy and change the INI.

Anything else afterwards is just to teach you how things changed. And that wasn't just in recent years, but since Vista. So it does not explain why your 10 year old state did work 10 years ago and not now. I have given up on finding out why. One last thought: You storer paths in a DBF char field, which has trailing spaces you need to remove, but that's also something that would have not worked 10 years ago.

Anyway, it's much more important to get your application going now, isn't it? So finally, the straight forward solution is to set permissions and make that work comlpetely wwindependent on elevation or UAC settings.

Chriss

RE: Problem with SET DEFAULT TO

(OP)
Chriss,
C> Anything else afterwards is just to teach you how things changed.
G> I have really enjoyed reading your explanations - when one is a lone operator it's hard to pick up all those points.

C> You simply have permissions on the files and folders, SET DEFAULT, copy and change the INI.
G> Having tried to do SET DEFAULT, copy and change the INI and failed - which was my first question to the forum -I'm not sure how to deal with the permissions issue. I can't see anything in the INNO help to explain that.

Regards
GenDev

RE: Problem with SET DEFAULT TO

(OP)
Chriss,
This applies to the final exe obviously but how can I check/amend my code if I can't get to Roaming/TMG in the debugger. This where I came in..

GenDev

RE: Problem with SET DEFAULT TO

Quote (gendev)

but how can I check/amend my code if I can't get to Roaming/TMG in the debugger.

After a setup makes sets the permissions you willbe able to SET DEFAULT TO where you permitted yourself to go.

And for already installed applications you still can apply an updated installer that sets the permissions. Or for the one off case of your own computer, use Windows Explorer and set permissions explicitly.

Chriss

RE: Problem with SET DEFAULT TO

(OP)
Chriss,
This is the situation re permissions in Roaming/TMG for bryan on my dev PC before I make any changes to my INNO setup program.


I can't see how I can do better than that.
I have emended the exe line in INNO
Source: U:\Dev\_FoxPro\Dist_Folders\PathWiz_Dist\Programfull\pathwizv11.exe; DestDir: "{app}"; Flags: ignoreversion ; Permissions: everyone-full
I can't see how to nominate the roaming/TMG Dir though.
So running my pathwiz with test code again I see the same problem in the output.


As can be seen (as before ) DO DEFAULT does not move to the TMG roaming folder but stays on pathwiz11 and the result of the file test is .F.
despite the dubugger moving to the 'Success' mesagge.
--------------

RE: Problem with SET DEFAULT TO

Regarding the Inno setup,k please click the links.

What is the name? Open your eyes. Within the [Dirs] section of an Inno Setup it is the name of a Directory. And in the [Files] section it is the name of a file.

Chriss

RE: Problem with SET DEFAULT TO

Reagardng SET DEFAULT:
Can you show the output of this (as a screenshot)?

CODE -->

? LEN(lcPath)
? LEN(ALLTRIM(lcPath))
? ">"+lcPath+"<" 

Chriss

RE: Problem with SET DEFAULT TO

(OP)
Chriss,

As previously noted in this thread the length of the path string is 54



C> Open your eyes.etc INNO says 'Creating subdirectories underneath the main application directory is a common use for this section.'
I know that but I am assuming it is the TMG roaming folder and that does not appear in my INNO file - it is accessed from within PathWiz. How can I add it to the INNO file then?

Inno uses
[Dirs]
Name: {app}
;Name: {app}\Docs
;Name: {app}\Reports
; Name: {userdocs}\Pathwiz Reports\HTML
Name: {userdocs}\Pathwiz Reports\WORD
Name: {userdocs}\Pathwiz Reports\CSV
Name: {userdocs}\Pathwiz Reports\LOG
is (userdocs) an appropriate place or is there another name I can use?

GenDev

RE: Problem with SET DEFAULT TO

Quote (gendev)

How can I add it to the INNO file then?
You add it. If you add a path that already exists, you can still use the Permission: part to set the permission. It's straight forward.

Chriss

RE: Problem with SET DEFAULT TO

Aha, didn't you said you want to change into the TMG roaming folder?

According to your procmon output

That is C:\Users\bryan\AppData\Roaming\The Master Genealogist v9\

And according to the output of my suggested test code:

That is C:\Users\bryan\AppData\Roaming\The Master Genealogist\

Do you still not see the difference?
Are we talking about a wrong path for almost 2 weeks?

Chriss

RE: Problem with SET DEFAULT TO

(OP)
Chriss,
As each user will have their own place in Users dir its not possible to anticipate what the problem path will be.
ie for me
C:\Users\bryan\AppData\Roaming\The Master Genealogist v9

GenDev

RE: Problem with SET DEFAULT TO

Again, open your eyes: The value in lcPath is missing the v9 part of the path.
What's really your problem? Eyesight, focus, short term memory?

The path in general will always be ADDBS(GETENV("APPDATA"))+"The Master Genealogist v9" in VFP code and within the INNO setup {userappdata}\The Master Genealogist v9

Well, and "always" depends on when whoever changes the folder name of the TMG application subfolder. TMG is not your software, so you don't decide that subfolder name. When it changes you have to adapt. No sytem directory function or environment variable will help you with that. When the developers of TMG decide their subfolder name should include a version number, that's the way it is. There's no function telling you the name of another applications appdata folder. So when you involve your application with the INI of another software and assume once finding out the appdata folder name is enough, then you don't have any idea of your own responsibiliities when you introduce a dependency of your software from how/where another software stores its files. It's usually non of your business, but if you make it your business you will have to stay up to date.

Chriss

RE: Problem with SET DEFAULT TO

(OP)
Chriss,
Yes all of the above but I optimistically keep trying...

I am so sorry to have taken up your time with this - the V9 added to the path statement has allowed SET DEFA to work correctly.

As you say, way back TMG added the version number to the exe and my hard coded app name missed it. and I wasn't alert enough to spot that. A red faced Mea Culpa
I have learned a lot from your posting and I thank you for that.
Now to test the rest of the code - BUT the copy of the ini has worked though.

GenDev

RE: Problem with SET DEFAULT TO

One question that remains is why you didn't get an error. My guess is that both the old and new appdata folder of TMG exist. So your code also did copy and modify the old ini, just TMG9 did not read it from there.

The general problem of knowing the appdata (sub) folder of a third party application you don't have control over is not solvable, but do you install TMG alongside your application? Then you know the version you install alongside and where its ini is. What could be helpful to make this an ini setting of your ini so users can adapt this. And you could check the exe name and size of the TMGx.EXE, and note down where the ini is for each versio of TMG to have that knowledge available at least about all versions you know.

Chriss

RE: Problem with SET DEFAULT TO

(OP)
Chriss,

Overwhelmingly the TMG community worldwide have been encouraged to use the last version released in 2014 - that's Ver 9.04. Production of the software has finished with the author pulling the plug and taking up other pursuits. Genealogists who use TMG believe it to be the best s/w for Family History. My app only works as an add-on to TMG. Thus my app will be unlikely to be used in conjunction with any other version. If it is my code will (now) recognise any older versions and find the ini files location without any dramas.

Regards
GenDev

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login


Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close