×
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

Inno Setup - Read-Only
2

Inno Setup - Read-Only

Inno Setup - Read-Only

(OP)

Hi, I'm following up on the previous thread where the users gave me great advice.
https://www.tek-tips.com/viewthread.cfm?qid=182017...

I currently have a problem with the function of the program, some functions do not work and write the following error:


When I try this in the development environment, everything works, but when I create the installation file in "Inno setup", it says this error.

I thought it was in the rights of a certain file, so I set all the files in the directory to "Permissions: system-full" in Inno setup. Unfortunately, it did not remove this error, has anyone encountered this problem?

Does the rights have to be set in FoxPro even if everything works for me in the FoxPro environment? Or set it differently in "Inno Setup"

Thanks for your help with this problem

Have a nice day

RE: Inno Setup - Read-Only

Hi,

That depends on how the cursor GPTINFO is created.

If you SELECT ... INTO CURSOR you have to add READWRITE at the end of the command.

CREATE CURSOR ... is READWRITE by default

hth

MarK

RE: Inno Setup - Read-Only

I don't know what this has to do with Inno Setup. But, in general, the error message usually is the result of trying to update a cursor that was created with SELECT ... INTO CURSOR ....

By default, such cursors are read-only. You need to add the READWRITE clause to the SELECT to make the cursor updatable.

If the cursor is read-only, as well as not being able to update it, you cannot add or delete records or create indexes.

Having said all that, it's not possible to know for sure that this is the cause of your error, as we cannot see the relevant code.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

RE: Inno Setup - Read-Only

Make sure that no data goes into "c:\Program files" or its subfolders, since these folders are read-only for security reasons.

RE: Inno Setup - Read-Only

MarK and Mike could point in the right direction, but I wonder.

I know from your previous thread, you inherited all that code. So, in principle, it should all work, aside from a few bugs you might have inherited. So unless you didn't introduce new code that fails here, this should not fail on forgetting READWRITE when creating a cursor the code later modifies. You also say this does not fail when you run it all within VFP.

That makes me think Tore has the better point about all files being readonly within the system folder of program files (and program files (x86), too).

If you install data into the installation directory it must be done with full file permissions on the data files, otherwise you get readonly errors, but let me check how that actually triggers errors...

...well, I don't get errors. If I copy the Northwind subdirectory from my VFP9 installation (which I did into c:\ussers\public instead of c:\program files (x86) to avoid having readonly problems) into a new folder c:\program files (x86)\Northwind I get prompted to elevate to administrator permission to be able to copy the files into it. Runnning a setup you also get that prompt once. But after doing that and using VFP9.exe without administrative elevation, I can actually open dbfs and write to them, the data modification gets redirected, though, by user account control redirection. The changed DBF and CDX can be found in %userprofile%\AppData\Local\VirtualStore\Program Files (x86)\Northwind.

Now it depends on your UAC settings what exactly happens in your case. Indeed if that redirection is turned off, you get exactly that error. In my case for trying to change customers.dbf:


So, well, Tore is likely right and you're right with your own assumption, that file permissions are insufficient for the users. And "system-full" is not the setting you need for users, it only gives permission to the SYSTEM account of Windows, not any user.

Eidt: https://jrsoftware.org/ishelp/index.php?topic=dirs... - this is where you find explained what the first part of a permission paramter means. And system is for the local system account, that is not a user account, it's really the local account called SYSTEM of Windows itself.

But the first question to address now is not how to change the permission within the inno setup project to produce a setup that writes the database with sufficient permissions into \program files (x86)\ for users, but whether you actually would need a central place for all the data. Otherwise, everyone only works on their own local data. It depends on what the application is designed for, but multi-user applications sharing data on a file server are more common than single-user applications with each their own database. And even in case this is intended to be data per userr, installing data into \program files (x86)\yourapplication\data\, for example, means this is the same data for all users of the same computer, so real single user data should be stored into the user profile directory, either into a subdirectory of documents within the user profile or within appdata.

That's all things you need to consider before creating the setup for your application, no matter if it's a VFP application, even, and no matter if you use inno or other tools for creating setups.

Chriss

RE: Inno Setup - Read-Only

(OP)
mjcmkrsr (TechnicalUser):
Yes, I haven't found where the cursor is created yet, otherwise it's set to READWRITE everywhere else.

Tore Bleken (Programmer:
Yes, that's what I thought too, but I wanted to install it somewhere else, not in the Program files directory, but this option is not there, so I set DefaultDirName=c:\GPT Print reports, which only installed in the C directory, but unfortunately it also nothing changed and the elements don't work.

Chris Miller (Programmer):
As you write, I shared this code and I don't have much experience like you.
I didn't introduce a new one, just the modifications you advised me and the program works in VFP.

I tried installing the program only in the C directory and also in the Users directory, this did not solve the problem.
Thanks for posting the link to the thread, I did this setup too and just to be sure I set all the files to Permissions: users-modify and installed to Users, the error message is the same.


Most likely I think it will be in the settings somewhere in VFP, but I'm not sure.

Thank you for your help

EDIT:
I found the code for "opening" in procedures and functions, maybe it could be here, but I don't know about it.

CODE --> FoxPro

PROCEDURE Otevri *Open
	IF MESSAGEBOX("Odstranit všechny záznamy ?",36,"Měření GPT")=6
		SELECT GptEvTras
		ZAP 
		SELECT GptInfo
		ZAP 
	ENDIF 
	IF DIRECTORY(MemoCestaSestav)&&NOT EMPTY(MemoCestaSestav) &&FILE(MemoCestaSestav)
		SET DEFAULT TO (MemoCestaSestav)
	ENDIF 	
	OtevriInfo=getfile("DBF", "InfoTrasy")
	SET DEFAULT TO (cCestaProgramu)
	IF NOT EMPTY(OtevriInfo)
		MemoCestaSestav=LEFT(OtevriInfo,RAT('\',OtevriInfo)-1)
		HIDE window gptinfo
		APPEND FROM (OtevriInfo)
		COUNT TO Mereno FOR NOT EMPTY(Datum_cas)
		COUNT TO Nemereno FOR EMPTY(datum_cas)
		SUM draha_konc TO DelkaKm
		OtevriInfo=LEFT(OtevriInfo,LEN(OtevriInfo)-1)
		SELECT gptevtras
		APPEND FROM (OtevriInfo)
		SELECT gptinfo
		replace info WITH ALLTRIM(STR(RECNO())) all
		GO top
		SHOW window gptinfo REFRESH top
	ENDIF
	SET DEFAULT TO (cCestaProgramu)
ENDPROC 

RE: Inno Setup - Read-Only

Did you check how permissions end up after the setup?
Also, if you do a changed setup on a computer which already had a setup, I don't know how Inno handles already existing files.
Your error message provides the info that the error arises in GPTINFO.COMMAND4.CLICK. That's the code we should look at.

Now, please read to the end how to get to the code section, before you waste time:

So GPTINFO must be a form, which you can find in two sections of a project, depending on whether it is an SCX form or a form class in a VCX class library or even a form class definition in a PRG, so indeed that's not straight forward to find, when you don't know the project. But look for the most commonly used variations, first: SCX forms. You can find them in the All tab, of course, where you open up the treeview node for Documents to find subnodes forms, reports, and labels. Or, as you know from that treeview sructure now, you find forms in the Documents tab of the project manager window under forms.

Is there a gptinfo form? Then open that up and find a button called command4. There have to be at least 4 buttons and they are named automatically to command1,2,3,4, etc, in the order they are added to the form, not necessarily in geometrical or reading order. That means, it could be any button. You see, that's one flaw of form design, if the button would have been renamed to its purpose it would be easier to find it. I mean, it could be simple and the caption is still Command4, too, but you will typically set the caption to something more user-friendly.

Instead of going through all the buttons you can open the properties window while you have the form open in the designer, and then drop down the combobox at its top. This will show yo the form structure as a treeview and you can see all objects names there and pick command4. Now in the methods tab you can find the click method, doubleclick on that and the code editor will show you that method. Watch out, the code window could end up behind the properties window.

And now you find the code causing the error in line 2. I bet there is nothing wrong with the code, it will be an UPDATE or REPLACE modifying the workarea that has the gptinfo.dbf opened in it. You won't program this for a table you intentionally open with USE gptinfo NOUPDATE or similar. this answers your indirect question indirectly, whether it is the code that prevents writing into the workarea itelf. But since this all works inside the VFP IDE, that's not the reason, this code does not step on its own foot.

So, in the end it would likely not even shed more light on what's the problem, if you find the cclick code. It's quite clear you have a file permissions problem.

Chriss

RE: Inno Setup - Read-Only

A short warning, if you do things along reading tips:

You'll see I tell in the end it's not worth finding and looking at the click code the error message mentions. So the thing to double check is how the file permissions are actually set in the data directory for gptinfo.dbf. The users-modify permission should suffice, but I don't know what inno setups do to already existing files. So to ensure this new setup works the essential steps are - sorry to even point that out: After modifying the setup permissions in the inno setup create the new setup.exe, uninstall the previous installation and then reinstall with the new setup.
Of course you did that, but I know from creating setups with Installshield there can be multiple output folders for setup.exe or msi files or even CD images. You can easily fail to have picked the actually changed setup.exe

So the best first thing to do is look into file permissions of the current installation on a users PC and decide what to do from knowing that. If effectively the user can write to gptinfo.dbf then its worth looking into the code. Otherwise its worth looking into other things. For example then it becomes helpful to find the click code to set a breakpoint for debugging there. While you don't get the error when you run the project code within the VFP IDE, you can stop there i the click and find out what the workarea gptinfo is at that point. And that doesn't shed enough light, you could also add a MESSAGEBOX(DBF('gptinfo')) into the code and build it into the EXE, put that into a new setup and run it at the client to find out where the file is, that the EXE uses at that point.

Chriss

RE: Inno Setup - Read-Only

(OP)
I would say that this is a complex problem, because this error appears when I close the INFOUSEK window, so it depends on which button I click, so this button appears as an error.
For example: Program witch error: GPTINFO.DATUMKOLEJ, GPTINFO.COMMAND3.CLIK and so on...

This is in the function for button 3:

CODE --> Foxpro

1 SELECT GptEvTras
2 ZAP 
3 SELECT GptInfo
4 ZAP 

5 COUNT TO Mereno FOR NOT EMPTY(Datum_cas)
6 COUNT TO Nemereno FOR EMPTY(datum_cas)
7 SUM 0 TO DelkaKm
8 thisform.refresh 

RE: Inno Setup - Read-Only

Quote (MajklPan)

GPTINFO.DATUMKOLEJ, GPTINFO.COMMAND3.CLIK and so on
"And so on" is not helpful here. Also, not knowing the line number for the error in button3.click I can't point out the problem even though you posted the code.

If it's line 4, the ZAP of gptinfo, it just points to the problem we already know, the readonly state of gptinfo.dbf

If a file is readonly or you don't have modification permissions (so it doesn't need to be the readonly attribute of the dbf file), of course, that causes multiple errors in your code. In every place in the code that tries to modify the dbf without the modify permissions. Of course they all error, as they all face the same problem of not being able to modify the DBF file.

Please, check the permissions on the file itself after the setup has been done. That's the only way to know it is the problem. If it turns out the file permissions allow modification, then we could investigate further in the code.

If somebody programs a ZAP of a dbf, then this needs exclusive access to that DBF and I'm sure the programmer made it that way, or you would have had trouble everywhere with previous software versions already. It also points out this software isn't for shared data access, but that's what I would have guessed from the local installation of the data anyway, so no big surprises or problems with the code, just file permissions. Looking into code or finding more places you only confirm more and more, it's a file permissions problem. Add into it that I got the same error message talking about a "cursor" though it was about customers.dbf in my case. The term "cursor" was misleading others to think of readonly cursors you can generate by code instead of readwrite cursors. But this is about the dbf file gptinfo, I strongl suspect and the suspicion just rises.

Chriss

RE: Inno Setup - Read-Only

(OP)
After starting the window and pressing any button in the INFOUSEKY window and exiting, it will write an error. So I thought it was unnecessary to list them all.
Yes, line 2 is the one I marked in the code.

In the picture above, where I sent the error, this code is for the COMMAND4 button (I marked line 2):

CODE --> FoxPro

1 old=RECNO()
2 DELETE
3 COUNT TO Mereno FOR NOT EMPTY(Datum_cas)
4 COUNT TO Nemereno FOR EMPTY(datum_cas)
5 SUM draha_konc TO DelkaKm
6 GO old
7 THISFORM.Grid1.SetFocus
8 thisform.Refresh 

After installation, I went through the files in the folder, manually assigning them rights for all users, nothing helped.

I also found that if I run just the .exe file in the project folder without creating any installation, the errors occur already here, I think it's to do with the location of the .exe file, where I have it in the main folder and not in Progs folders.

RE: Inno Setup - Read-Only

Quote (MajklPan)

this code is for the COMMAND4 button (I marked line 2):
That's DELETE and it also (tries to) write in the gptinfo.dbf file - assuming that is currently selected. DELETE writes a deletion mark into a record, so it's just a modification of the file, too, like REPLACE or UPDATE.

There's the catch with that click4 code. Depending on what was done before clicking it other workareas than gptinfo could be the current workarea. This code forgets to be specific about hat it deletes. Or it is done with the purpose to be able to delete in any workarea previously selected.

We already know what you inherited isn't really a good codebase, but this again just points out file permissions. Sorry, I can only repeat myself here.

I'm aware you said:

Quote (MajklPan)

manually assigning them rights for all users, nothing helped.

After you make any permissions change, please look into effective permissions: In advanced security settings you have a tool to pick a user, some application user, and see what effective permission he has with your security settings. Use that:


And then, as I already said, find out which file is actually modified by doing Messagebox(DBF()) in the code. For example right before the DELETE command. You will likely need to modify that code to first select the table that the DELETE command should address, but you might also keep it that way to be able to delete in more than just one DBF, if this is meant as aa general delete button. Before we change that, ensure you have solved the data file permissions, though. For the DBF files that matter.

So once more: You get to the effective access taab from foile properties dialog, security tab and going into the "Advanced" dialog. And first find out which DBF() file to look at by running the Messagebox(DBF()) in the installation. It's the easiest way to find out which file is tried to be modified.

Chriss

RE: Inno Setup - Read-Only

(OP)
I have the properties of the gpt info.scx file in the security tab, this setting.


EDIT: I tried the thing of creating the installation file as a whole project and then after installation I opened this project in Foxpro, the result was the same, it worked for me in foxpro. So it is likely that it will be in rights.

RE: Inno Setup - Read-Only

Wake up, we're talking about data, not the form.

You have a gptifo.scx form. Yes, but why? Because it's the form for the gptinfo table, the gptinfo.DBF.
You're looking at a totally unimportant file for the runtime error you have. The runtime problem you have is about DATA modifications.
The SCX is in the EXE when you build, it's not modified, it's executed.

I told you put in a MESSAGEBOX(DBF()) in the click code to see which file you have to look at in detail. Why don't you do that?

Chriss

RE: Inno Setup - Read-Only

(OP)
I looked for other alternatives as well...

Here is the error MessBox when I expected this file to be referenced.


Paradoxically, if I installed the previous version from 2015, which my pre-skinny did, the GPTINFO.dbf file is read-only and works normally in the program.

RE: Inno Setup - Read-Only

I assume you have erased a part of the filename. But now you know from where the EXE opens its data and in this folder users need file permissions on the DBFs. So the next steps should be straightforward. First look into effective permissions and then figure out how to give users permissions for this tables directory.

That it's all in the USERS directory points out it should be a directory of the profile and be writable to them, but if one user installed the software into his proflie, only that user can use the software, for example. There are some special users like "PUBLIC", which means for all users. As you don't show us more of the path it's again just guesswork.

As you mention an earlier version had a readonly GPTINFO.dbf and it still worked. I don't know how. I faintly remember VFP once didn't care about file attributes, but I'm not sure that's just a myth. If it was working that way, that's a bug MS fixed for VFP. Becasue what I am sure about is from a simple test right now is that VFP9 and an EXE using the VFP9 runtime will cause the same error, if the user has sufficient write permissions on the file, but the readonly attribute is set. So yes, that's also important to be unchecked.

Chriss

RE: Inno Setup - Read-Only

(OP)
Thank you for the explanation.

so if I understood it correctly, I don't need to programmatically set anything, I should somehow set the gptinfo.dbf file for the user so that it is opened for both reading and writing.

I did something like this and this didn't help.

RE: Inno Setup - Read-Only

Please, MajklPan, if you set permissions for this usergroup called "Users" and the dbf still can't be accesse, what does this point out?
Use the "effective permissions" feature and convince yourself about the effective permissions one sample user has.

And what did I just say about the readonly atribute? It is indeed important on top of the file permissions that this is NOT checked too.

Also as you might not have got this: C:\Users is the System directory for all user profiles, the next part of the filename determines which user, there are directories for each user of a system. And if the tables are installed into one users profile, you can try as many times as you want to give permissions to all users, a profile is only for one user and stays to only be accessible for that one user.

Chriss

RE: Inno Setup - Read-Only

(OP)
I have this set up a long time ago, unchecked "Read-Only".
I have no idea what to set in effective access, but full control is set everywhere.

RE: Inno Setup - Read-Only

(OP)
So I don't have that, unfortunately I don't have excellent English, so translation is difficult for me, and from a professional point of view, it's difficult to understand the meaning of sentences.

Therefore, some of the plot lines are difficult to translate.

Accesses the file where the installation process created the files.
Here:

Thank you for understanding

EDIT:I inserted MesseBox into a certain button and when pressed it calls something in appdata.. so I don't understand this at all..

RE: Inno Setup - Read-Only

Thanks, MajklPan.

I can't help you with your english, unfortunately, so this all has to do with repeating and pointing things out in different ways until the translation hits it.

If DBFs are installed there, the messagebox you posted earlier still doesn't match that, does it?
You erased a portion from that, which is much longer than "GPT Tisks sestav" only.

And that last screenshot of the data installation directory being C:\Users\GPT Tisks sestav\Tables means, that only the user "GPT Tisks sestav" can access this data.

Nobody else, and you can't change that with change of file permissions, because Widnows is very strict about who can access files in one user profile directory: Only that one user, "GPT Tisks sestav".
If ou created that folder within setup, that's not creating such a user. And nobody will have access to it. You might have thought C:\Users is a directory you can use to install your data into, you misinterpret this system directory meaning.

A directory all users can acess is C:\Users\Public\, that's the "All users" user profile directory on new systems.

And I think I now also know the root of all your problems. You must use a too old version of Inno Setup. Because things changed dramatically since Vista, about where many system directories are, especially also about Application Data for single users or all users. So what setup worked perfectly up to XP can fail in Vista or later, if it's not adapted to the new situation.

One thing is for sure: Installing data into C:\Users\GPT Tisks sestav\ is your problem, even if "GPT Tisks sestav" is actually a user and not your application name. A base directory for so called COMOMMONAPPDATA is C:\ProgramData.

Don't hardcode such paths in an inno setup script, there are specific codes for system directories. In this case this should be {commonappdata}.

And your code must address environment variable GetEnv("ProgramData") to find this system folder, which differs in Vista and later from XP or earlier.



Chriss

RE: Inno Setup - Read-Only


That's just pointing out the workarea has a CURSOR, not a table in it.

Let's talk about this once more, maybe another phrasing will help the transaltion:

CODE

1 old=RECNO()
2 DELETE
3 COUNT TO Mereno FOR NOT EMPTY(Datum_cas)
4 COUNT TO Nemereno FOR EMPTY(datum_cas)
5 SUM draha_konc TO DelkaKm
6 GO old
7 THISFORM.Grid1.SetFocus
8 thisform.Refresh 

That's code you posted about one button COMMAND4. I think that is where you added the MESSAGEBOX(DBF()), is that right?
Did you once get the above filename from it, the TMP name? And did you another time get this from it?


That can happen. Because the code above does not select a specific table before DELETE. It works in whatever is the current workarea. If that button COMMAND4 is only there to delete records of gptinfo.dbf, it should start with the line

CODE

SELECT gtpinfo 
, because whatever you do before clicking there can mean sometimes other tables or cursors are the currently selected and activated workarea. That's a problem with this code, as it does not take care about that aspect. A button doing a DELETE in whatever is currently selected can be okay, too. If it's a general delete button but then you should be able to first specify or know what you want to delete and so such a general deletion is usually not what I would expect to be the intent.

This is a problem that's unrelated to your general file permissions problem though, you first need to address where your data should go in the installation and also then where and how you open it in the application code. That's more important to fix first.

Update: By the way, since the code somehow knows to look for data in C:\Users\GPT Tisks sestav\Tables putting it into a more appropriate folder is only one step towards a solution. I said "...where and how you open it in the application code" because that needs to be changed, too. You don't get around to doing both changes. Change the data location in the setup and then also change how the application finds data, there should be something like a base directory it uses. I can even imagine how this path resulted even though you didn't change anything. In earlier Windows versions local application data was in a users profile documents subdirectory or in the "All Users", and there was no C:\ProgramData directory. But look into it, you see that all kind of software uses this system folder for its data or other application files, typically in a pattern of naming C:\ProgramData\Vendor\Applicationame\.

There is, by the way still something that compares to "All Users" since Vista, it's "C:\Users\Public", you can also install data into that. The problem just is, installing into another better directory does not make the rest of the code automatically find the data there. But you have to go this route and do this move of the data because you can't actually really change permissions within the branch of C:\Users\ That is the system directory for all user profiles and not of common appdata. So you have to change installation and software to work with this new situation of system folders since Vista.

Chriss

RE: Inno Setup - Read-Only

These kind of permission problems can be avoided totally by putting the program, data and supporting DLLs in its own directory, preferably not even on C: if there's another drive available. That way you can reinstall the OS if needed without risking your application.

RE: Inno Setup - Read-Only

(OP)
Yes exactly, I added MESSAGEBOX(DBF()) before the DELETE statement.

However, you write that I should not store data in "users" but install it in {commonappdata}, i.e. C:\ProgramData, which I did, but I don't see that anything has changed.

I also tried installing it in the {commondocs} folder ie C:\Users\Public and it also still says Read-Only.

Thank you for your patience and time.

EDIT: Chris Miller : If I gave you the source code, could you try running it? It would certainly be easier to understand the problem.

But it doesn't make sense to me, because already in the project itself, where I have the source code stored, I run the exe file itself and it already writes a Read-Only error, so it will have nothing to do with the installation, but with fixing the access to the file. Which has to be set up somewhere.

Thank you

RE: Inno Setup - Read-Only

MajklPan,

when you change the setup you don't change where the code looks for the data. That's the reason it still is read-only. The location where the code reads data from didn't change just because you changed the setup.

You need to find out where in your code the data is opened and change that to the new system folder used by the setup. Otherwise the EXE of course still trie to modify the data at the place it still is there from previous installs, where it still is read-only.

Chriss

RE: Inno Setup - Read-Only

(OP)
So you mean that I have to change the path to the gptinfo.dbf file in the code.
When I took an older project, where I run just the .exe file from the project, it works there.
Fixing the file, security and everything is identical compared to my file, I also tried the option of copying the dbf to the same place from the older project and again it didn't work.

I would not look for an error in the rights, but most likely in the creation of the exe file, where the authorization or the path should probably be set there, but I am only inferring that.

RE: Inno Setup - Read-Only

(OP)
Problem solved.
I figured out that the file to be specified as gptinfo.dbf was included in the file compilation and I changed it to "Exclude", that fixed the problem and it now works loading those items without setting permissions. I don't understand the politics of these programs, but this is probably how they will be disqualified.

Thank you all for the help and practical advice.

RE: Inno Setup - Read-Only

Ouch.

Chriss

RE: Inno Setup - Read-Only

There's still something to do, and I hope you will still read on or find this when you have your next question.

Since you changed a lot in the setup you either should reverse or continue and complete this.

You have more data than just gptinfo.dbf, don't you? There should be aplace for all of the dbfs and perhaps a DBC your application uses, maybe in a subfolder of your EXE, so that has to be writable to users.

It's completely unclear why there is a dbf in some subfolder of c:\users and it is there, isn't it?

So you still have to figure out where data should go and is found by the EXE.
If it's a subfolder of the EXE and you isstall this into Program Files (x86) then you kow the warnings others gave you about this, this is even a topic in the other recent thread of a problem with an application from k2a.

There is however, a very well known VFP developer Doug Hennig that has indeed made it a norm to install data into a subdirectory of an EXE, see here:

https://doughennig.blogspot.com/2007/12/where-shou...

And even before you go read it (very much recommended) he's posting his Inno setup configuration as

CODE -->

[Dirs]
Name: "{app}\Data"; Permissions: everyone-modify 
Where {app} is where Inno installs the application and the Data subfolder name may differ for you.

His argument is such an installation can even be the basis for a multi user application, if you either make it a terminal that multiple users connect to and use. It's not as good to make it a share, but it would technically also work. It would just not make all further installations automatically use this share, you'll still at least need to integrate a setup inteerviw question whether the installation is the server or a client. And then on the server you'd only need to install the data and on clients you only need the sofftware and so I would make two different etups out of that.

But you see, you have a proponent for a data subdirectory in the program files system directory.

The common use case for such an installation would be a per computer installation, though, with no shared data. And in his inno ini it would make all users able to use the same data, not just a single user.

It's also a bit funny, as Doug also has written a whole long article about Vista (that still holds true for VFP9 and any OS since Vista) that also talks about the changes in system directories made since Vista, UAC and all the consequences you face therefore in application projects. Overall it addresses almost anything you face and have to adapt in applications thaat still work up to XP. So Vista is a big turning point, indeed.

Here is that article: https://doughennig.com/Papers/Pub/Vista.pdf
And a follow up for Win7 (and later): https://doughennig.com/Papers/Pub/Windows7.pdf

And you find a lot that's unrelated to VFP as the effects of changes in system directory, another set of Fonts, Aero windows, and other things introduced since Vista affect all software, not only VFP software.

So read that, you will profit from knowing all these things in any development.

Chriss

RE: Inno Setup - Read-Only

(OP)
Great, thanks for the article, I will look into it.

I would prefer to get rid of the FoxPro environment completely, since support ended in 2007, but for now we are developing this application in another environment, so it needs to be managed for some time, so I am ignorant in these matters.

RE: Inno Setup - Read-Only

(OP)
I have one more question, so I don't create a thread unnecessarily, do you know where I could find the defined values in the field?

Such as, for example, MVD, MVH, MK.
I would need to change these values, but I went through the whole project and I can't find these values anywhere, aren't they defined in the .mem file?
I've also looked for it in the procedures and I also can't find the number that appears when the program starts.

Thank you for answer

RE: Inno Setup - Read-Only

(OP)
Thank you for answer.

I found them where they are declared, but the point is that a certain value is already set at startup, I would need to change it, where can I find it and change it?

It's in the variables:
MezKlik=MemoDefOstTrKlik
MezRozdVys=MemoDefOstTrRozdVysek
MezVysDol=MemoDefOstTrVyskaDolni
MezVysHor=MemoDefOstTrVyskaHorni

Thank you for answer

RE: Inno Setup - Read-Only

Hi,

Don't forgot create backup of file GPT_Memo.MEM.
RESTORE FROM GPT_Memo.MEM
MemoDefOstTrRozdVysek=<new value>
SAVE TO GPT_Memo.MEM
 

mJindrova

RE: Inno Setup - Read-Only

MajklPan,

I'm sure mJindrova's advice will work, though you might not understand it. There is a little detail omitted to first CD into the directory of the GPT_Memo.mem file, and you risk storing more than you restored with SAVE TO GPT_Memo.Mem. That sounds harmless, but the extra variables you store will be RESTOREd in the application and may override something that shouldn't be overridden.

To avoid that it would be nice to know what the software itself stores into GTP_MEMO.MEM and I'm sure you find a SAVE TO in the code which could, for example, limit this to all variables starting with the name prefix "MemoDefOst".

Then you should use the same SAVE TO the software itself uses. And finding that SAVE TO code you may even find the form doing that and saving changes of these value from within the usage of the software, which should be the safest way, as it is the intended way to change the MEM file.


I know you don't like to learn fishing: But as you already dived in as far as finding out these variables are important:

CODE

MezKlik=MemoDefOstTrKlik
MezRozdVys=MemoDefOstTrRozdVysek
MezVysDol=MemoDefOstTrVyskaDolni
MezVysHor=MemoDefOstTrVyskaHorni 

The next thing to look for is where the right-hand side variables come from, and I think you didn't find code defining and setting them, or reading them from a DBF or whatever. What you know is they are set somehow, somwhere at some time in the start before these lines.

Well, this is where the debugger can help you find the source. You can make a breakpoint, a condition to stop executing and suspend code, when one of these variables (from the right-hand side) becomes existent. MemoDefOstTrKlik, for example. That's a special type of breakpoint not set at some line number of some code, but this way:

In Foxpro start the debugger, that's in its menu "Tools", item "Debugger". In the Debugger window then use the Breakpoints (CTRL+B). Change Type to "break when expression changes" and set the Expression to the variable name of interest, click the "Add" button. So you have this:

You could repeat this with the other names, but finding one should find the others, too.

Keep the debugger window open, just minimize it, for example, or move it where it doesn't hinder you and start the application. Execution will suspend when "MemoDefOstTrKlik" changes from being undefined to being a declared variable. You then get a breakpoint message and can inspect what caused this. Then you will see where this comes from and I'm quite sure it is the RESTORE of the GPT_Memo.Mem file. It may point to something else, though. It could be a variable definition with LOCAL or PUBLIC. You might find it's set from some other file, whatever. That's how to find out the "origin story" of these superhero variables.

Also, bear with me one more time: New question, new thread. There is no need to avoid new threads. And if you continue a thread you don't do yourself a favor. Because:

People tend to unfollow a thread once it's solved. If it's revived, the natural assumption is, that this revival of the thread is because a problem with the same issue (by thread title) arose again. You can expect that only those who solved or contributed to solving your problem will look into it, so you get fewer people looking into it, automatically. Everyone else will just think those who solved are also best for solving the new, related issue.

So, it's a really basic rule to start a new thread for a new question. That this is still about the same software is no reason to continue a thread. I understand from your perspective it might just be one application you have to maintain and your only VFP software so this all is one thread to you. But it's not at all just one thread from the forums perspective.

Your problem isn't at all related to Innno Setup, is it? Or does it stem from your setup overwriting the user's GTP_MEMO.MEM file? I think this is configuration data, which is subject to change. And so a setup that is meant as an update should not overwrite this file. Otherwise, you reset such configuration settings to their defaults. There are cases when you have new entries in GTP_MEMO.MEM, when updating users with a new one is unavoidable, perhaps, but not always. Just another thought about what might have gone wrong.

If this or mJindrova's advice solves your problem, no reason to start a new thread, it's already cared for. But also from the perspective of a forum as a knowledgebase about questions and answers, it's best if each thread has its own topic.

Chriss

RE: Inno Setup - Read-Only

(OP)
Chris Miller,

Thanks for the detailed explanation, I followed your procedure exactly.

Yes, the declared variables were displayed, however there is still the question of how to change these variables, it must be set by default somewhere and this is what I am looking for.
Is it possible to change the GPT_memo.mem file somewhere?
If I open this file it is not viewable.


I would create a fiber immediately if necessary.

Thank you for your responses

RE: Inno Setup - Read-Only

Hi,

Variables value are saved in a file GPT_Memo.MEM.

1)run vfp

2) run next row in Command window:
RESTORE FROM GPT_Memo.MEM && read variable from file to memory

3) Change value of variable:
MemoDefOstTrRozdVysek=<new value>

4) run next row in Command window:
SAVE TO GPT_Memo.MEM && save variable from memory to file

mJindrova

RE: Inno Setup - Read-Only

(OP)
mJindrova:
Yes, I tried it now and it works dazed

This is exactly what I was looking for, I didn't know that this is a rather complicated procedure compared to other programming languages.

Thank you very much for the explanation and your time, I wouldn't have come up with this myself dazed

Chris Miller:
Thank you also for the instructions, this way I could look up the variables, how they are declared and how I will need to change them.

RE: Inno Setup - Read-Only

The screenshot you have, the locals window, actually allows you to change the variables by clicking into the value column.

Well, you should look into the trace window to understand where the variables are coming from. You then can also see which path is used and which file is restored.
And then Martina already gave you the SAVE TO command you need to update the file after changing the variables.

But You now have more in the MEM file than you need.

You should look for a SAVE TO command in your whole project and then look into what variables are really saved into it. I bet ou it's using SAVE TO ... ALL LIKE Mem* or something similar. Because even a not so well versed programmer (we already sorted that out from code postings) will not want to store all variables, that includes system variables and other things you not want to have in the MEM file.

Quote (MajklPan)

a rather complicated procedure compared to other programming languages.

The pair of commands SAVE TO and RESTORE are pretty easy to use. The only complication is that you can't edit the MEM file as you saw. I discussed this and that it should be replaced in your older thread, already. It's something that is indeed easy for the developer wanting to save a state and restore it. It's also useful to use in error handling to enable getting back to how the state of all variables was when debugging an error, for example. But it's a bad choice for storing settings, for example. Configuration data should be put into INI files or - as we use VFP, a DBF table is not a bad file type, too. The registr is another place and then also XML files, etc., etc.. It's all doable in VFP, too. But you then surely also need more than one line of code to store and to read the configuration settings.

From the programming perspective, as you also experienced yourself, a RESTORE FROM command hides away the source of whatever variables are store there and you therefore can't easily discover b source code inspection what's the source of something. It does also matter how much this is documented or not, just like in any programming language. But we already talked through all these points abot the MEm file the first time ou came around here, you just don't listen or remember.

Chriss

RE: Inno Setup - Read-Only

There are also other commands and functions pairing up nicely to store data in a file and read it back in and the files are then also maintainable from outside the application.

I found what you missed in the menu of your application. In thee menu zakladni_menu.mnx you have a menu item 'Konec', which means 'Quit', if google translates this correctly and it seems to do exactly that with this procedure defined for it:

CODE

SAVE TO (cCestaProgramu)+"\GPT_Memo" ALL LIKE Mem*
USE 				&& uzavøe tabulku
POP MENU _Msysmenu 	&& obnovení systémového menu
CLOSE ALL 			&& uzavøe všechny okna
SET CLASSLIB TO   	&& uzavøe všechny otevøené vcx knihovny
SET PROCEDURE TO 	&& uzavøe všechny otevøené soubory procedur
SET HELP OFF 		&& nedostupná nápovìda
SET SAFETY ON 		&& zobrazení dialogového okna pøed pøepsáním existujícího souboru
SET STATUS ON 		&& zobrazení stavového øádku
SET TALK OFF 		&& urèí, zda se zobrazí výsledky pøíkaz&ugrave;
SET TOPIC TO		&& urèí téma nápovìdy, když se vyvolá Help
RELEASE ALL 		&& uvolnìní všech promìnných a polí z pamìti
CLEAR EVENTS 		&& stopne proces událostí spuštìn "read events"
CLEAR ALL 
CLEAR PROGRAM 

So that saves whatever changes have been done to variables starting with the name prefix MEM to the GPT_Memo.MEM file.

Actually, you should be able to just adjust your GPT_Memo.MEM file from inside the application by exiting via this menu, that's all you would need. It also points out that this is really a file that can change with any application setting and has to be kept as it was when updating an EXE. You can define a new setting into it simply b declaring another variable with that name pattern and it will be saved and restored, as long as it's in the scope of this menu procedure. Exiting with the X button of the main window you don't get the GPT_Memo.mem file to update and with the next start anything related to the settings is rest. Or with an installation providing the GPT_Memo.mem file from development, you set users to that.

What you should do right now to get rid of anything not belonging to GTP_Memo.mem is read it in with RESTORE FROM GTP_Memo.mem and then rewrite with

CODE

SAVE TO GPT_Memo ALL LIKE Mem* 

You could redesign this, using XML with VFP also just needs a pair of functions CursorToXML() and XMLToCursor(), for example, or - as that stems from using a DBF as the storage of configuration data - or just use a DBF itself. A bunch of variables is quite an unstructured way of handling a few values globally available to the application.

Chriss

RE: Inno Setup - Read-Only

(OP)
Thank you for the warning and the commands in my language.
I will definitely save this for future work.

Have a nice day

RE: Inno Setup - Read-Only

It's from your software.

Chriss

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