I've always created a new .exe file whenever I make even the slighest change in any file (prg, frm, rpt), since it only takes a few seconds to re-compile everything. But I realize that if I change a .prg which is called via a DO command, I dont have to create a new .exe (could just send out the .fxp to a customer). Same thing applies to reports - a change to a report does not require a re-compile. But the same does not hold for forms, is that correct? If I make a change to a form, I must create a new .exe to implement that change?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
when does a new .exe need to be made
- Thread starter jamesrav
- Start date
Chris Miller
Programmer
The example you give about an fxp only holds true if the prg/fxp file is excluded. The same is true for a report. PRGs and FRXs are by default included in compilation so the included (old) version would be used, if you don't recompile.
Or simpler said, you can do what you intend to do to reduce building EXEs, if you exclude things from being embedded into the EXE. You just also increase the amount of external files you have to provide with the EXE to let it work. And you would need to exclude files from the first EXE so excluded files are actually used - but then they also are needed.
Overall your distribution of an application would become the distribution of a ver reduced EXE with all the external reports, frxes, etc. and that is not that comfortable. You also make it much easier to see the structure of all your application and decompile portions of it, file by file only.
Chriss
Or simpler said, you can do what you intend to do to reduce building EXEs, if you exclude things from being embedded into the EXE. You just also increase the amount of external files you have to provide with the EXE to let it work. And you would need to exclude files from the first EXE so excluded files are actually used - but then they also are needed.
Overall your distribution of an application would become the distribution of a ver reduced EXE with all the external reports, frxes, etc. and that is not that comfortable. You also make it much easier to see the structure of all your application and decompile portions of it, file by file only.
Chriss
Mike Lewis
Programmer
I think you could probably get away with sending out the updated form on its own provided that you first compiled it (the compiled object code being stored within the SCX/SCT), and also that you excluded the form from the original build.
But, although that would probably work, I would advise against it. The whole point of bundling everything within the EXE is that you will only have one file to distribute (apart from the standard run-times, of course), and that file will be a complete representation of the application.
The more files that need to be distributed, the more chance of them getting out of sync, or of one of going missing, or of the user simply failing to install the right file at the right time. Also, if you (or the user) ever uses the version information in the file properties, that won't reflect the changes to the individual file that you are distributing.
You said that it only takes a moment to rebuild the app. I suggest that you do that every time you need to change a form or a report or a PRG. (A possible exception might be if your app allows the user to edit a report, but even that can be avoided.)
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
But, although that would probably work, I would advise against it. The whole point of bundling everything within the EXE is that you will only have one file to distribute (apart from the standard run-times, of course), and that file will be a complete representation of the application.
The more files that need to be distributed, the more chance of them getting out of sync, or of one of going missing, or of the user simply failing to install the right file at the right time. Also, if you (or the user) ever uses the version information in the file properties, that won't reflect the changes to the individual file that you are distributing.
You said that it only takes a moment to rebuild the app. I suggest that you do that every time you need to change a form or a report or a PRG. (A possible exception might be if your app allows the user to edit a report, but even that can be avoided.)
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Chris Miller
Programmer
Mike Lewis said:
Well, or it is wanted. The whole feature of protected report controls and allowing to modify reports also needs external report files, so they are even encouraged by the feature of the PROTECTED keyword of the MODIFY REPORT command.
And as a last not unimportant point, if excluded FRXes or SCXes or any code could override code included in an EXE, that would be a risk of EXE manipulation only needing to know names of files. And they are embedded in the EXE itself, so this would be a security hole of VFP executables, if it would work to patch an EXE by putting a changed FXP or SCX/SCT outside of an EXE that has that same name file embedded within itself.
What you could do, though it adds a completely different layer of complication, is bundle together all files in a zip and embed that into an EXE after the end of the actual VFP EXE, then use EXE internal code to unzip that part of your EXE, there are enough libraries available that would allow to unzip a string you get from extracting a known portion of your EXE you read by FILETOSTR, for example. There are even more elegant ways, as there are existing solutions, because that's effectivle what self extracting archives do and that's available, for example from 7zip in look at the description, which tells that the LZMA SDK includes besides many other things SFX modules to create self-extracting packages and installers.
If you'd add such a mechanism a new build could be made by just changing the modified code file in a zip archive and adding that to the unmodified rump EXE. I don't think it's worth doing, though.
In fact, VFP does something similar when building an EXE, the FXPs etc are put into the EXE, even only unzipped. Someone else not in the forum anymore has announced to go for a build patching approach to only replace a changed FXP that is to be found in the old EXE. That has its limits as the new FXP could be larger than the old one and there are further problems I saw when trying out simple examples.
Your simplest official way to a faster build is unchecking the "Recompile all files" option in building. Then VFP only compiles PRGs etc, that are newer than their compilation by file date. The next step of the build, to compose an EXE from the object code files. In the case of SCX/VCX etc the object code is embedded within memo files of the file pairs, which is a bit harder to see how VFP even determines what needs to be compiled and what is already up to date, but assume you find out, I think VFP has good reasons to not patch an old EXE but recompose a new APP and then EXE file in the build process, as it would overcomplicate things to do otherwise. The time that's spared without recompiling ALL files is compilation time for all PRGs etc that are unchanged, and that's already a good time-saving option.
Chriss
Steve Meyerson
Programmer
I totally agree with the "Include" rule! I don't know the poster's situation. Just thought I'd mention I had an exception to that rule in a very special situation.
A few years ago I created an app (exe) with nearly 100 (excluded) reports to create forms for a single user. We communicated by email. The exe wouldnt go through, so when I made a change to one of the reports, all I had to do was attach the frx & frt to an email. He knew where to save them in this situation.
Once again, this is an unusual situation. I fully support the "Include" method mentioned above.
Steve
A few years ago I created an app (exe) with nearly 100 (excluded) reports to create forms for a single user. We communicated by email. The exe wouldnt go through, so when I made a change to one of the reports, all I had to do was attach the frx & frt to an email. He knew where to save them in this situation.
Once again, this is an unusual situation. I fully support the "Include" method mentioned above.
Steve
Chris Miller
Programmer
Steve,
I see you only used this excluded FRX to solve the EXE transfer by mail as a hurdle. That's not a usual way of software distribution, you make software available as a download. Anyway, it's true that it helps.
And it's not unusual to exclude FRXes not only for the protected mode modification you can enable, also for a team of developers, the FRXes could be put into a central share where the data (DBFs) also are shared and then anyone in the team familiar with the reports can modify them independently from the EXE. That of course is limited to modifications that still work with the untouched EXE, i.e. there could be report changes that require a change of code proceeding the report in an EXE, so that's also not a solution working for any case.
Even less so when making exclusions a norm just to be able to provide any single changed file as the sole update file. Because you can only override what the old EXE also used as an external file.
Chriss
I see you only used this excluded FRX to solve the EXE transfer by mail as a hurdle. That's not a usual way of software distribution, you make software available as a download. Anyway, it's true that it helps.
And it's not unusual to exclude FRXes not only for the protected mode modification you can enable, also for a team of developers, the FRXes could be put into a central share where the data (DBFs) also are shared and then anyone in the team familiar with the reports can modify them independently from the EXE. That of course is limited to modifications that still work with the untouched EXE, i.e. there could be report changes that require a change of code proceeding the report in an EXE, so that's also not a solution working for any case.
Even less so when making exclusions a norm just to be able to provide any single changed file as the sole update file. Because you can only override what the old EXE also used as an external file.
Chriss
Steve Meyerson
Programmer
Hi Chris,
I understand your points and in fact, as you indicated, I HAVE on occasion changed the exe to accommodate a new report.
Back then I used Dropbox for the exe. But there were many small changes that required only minor report changes. Not so much any more. If I had to do it over again, I would probably "Include" all the reports.
Another advantage to inclusion might be the convenience of having the complete report list right in the always-open project manager, a click away from edit.
Steve
I understand your points and in fact, as you indicated, I HAVE on occasion changed the exe to accommodate a new report.
Back then I used Dropbox for the exe. But there were many small changes that required only minor report changes. Not so much any more. If I had to do it over again, I would probably "Include" all the reports.
Another advantage to inclusion might be the convenience of having the complete report list right in the always-open project manager, a click away from edit.
Steve
- Thread starter
- #8
those were very informative, and it does explain why the previous programmer (I inherited her program) structured it the way she did. With about 50 clients, all with different Report needs, not including the reports makes sense since modifications and bug fixes only require the single report be distributed to the individual client rather than create and send a new .exe (there is a 'Report manager' which allows for this). Any .prg files that invoke the report can also be updated and sent individually. The distinction seems to be in the Forms, most of the forms are Common to the program and are included in the Project. The problem then is if a bug is found in any of the common forms' code, a new .exe is needed. Since she left somewhat hastily, if I don't have everything needed to re-compile (have not tried - with so many 3rd party add-ons and a multitude of files and folders I'd be amazed if I have 'everything')and a Form problem is found, there's no way to fix the situation if a re-compile fails.
Mike Lewis
Programmer
I was once in a similar situation. The solution we adopted was to move all the reports from the main application to a separate free-standing reporting application. This enabled one of the developers to focus on providing reports more or less on demand, without disturbing the main application. It also provided the users with a degree of customisation, mainly by parameterising the reports in various ways.
In another case, we trained the users to use ReportSmith, thus allowing them to create whatever reports they wanted without reference to the developers. It turned out to be an ideal solution.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Chris Miller
Programmer
Well, don't assume you get awy without ever rebuilding the EXE.jamesrav said:
Why should it be a problem? A project should always be able to build an EXE again. It's just a matter of giving it a go. You can copy the current EXE so it isn't overwritten and you have that backup, but then a build not working is definitelyy a reason to get back to her and ask for completeness. You sure have enough legal reasons to ask that from her.
Chriss
- Thread starter
- #11
that is good advice Chris, I may give it a go and see how 'close' it comes to compiling. I know the current owners of the program are not that keen on devoting much man-power to keeping it going, the whole point was to obtain the client base and develop a new version of the program. Not surprisingly its proving much more difficult than they (non-programmers) anticipated, and this 'antiquated' Foxpro program (in their view) that has been under development for about 20 years is going to be tough to reproduce, even with a team of programmers.
- Status
Similar threads
- Locked
- Question
