|
#1
|
|||
|
|||
|
I haven`t been able to realize a patch, it never finds the path of my program, nor the wizard,nor with actions if some one could send me some code or some advice .
All my work And the work of my team is parallize by this problem whe really need urgent help Lorne help us a lot but we still haven make this patch to work my program is in C:/Program Files/Monitor/monitor.exe if not g_InstalledVersion then local TargetFileName = "monitor.exe"; local tbFolders = {}; tbFolders[1] = SessionVar.Expand("%ProgramFilesFolder%\\%ProductN ame%"); here it should have found it but he didn`t I don`t understand why Dialog.Message("uupps",tbFolders[1]); tbFolders[2] = SessionVar.Expand("%ProgramFilesFolder%\\%CompanyN ame%"); Dialog.Message("uupps",tbFolders[2]); tbFolders[2] = SessionVar.Expand("%ProgramFilesFolder%\\%monitor% "); Dialog.Message("uupps",tbFolders[3]); tbFolders[3] = SessionVar.Expand("%ProgramFilesFolder%"); -- Insert other folders here... Dialog.Message("uupps","No encuentra la ruta"); -- (g_FindApplicationOnSystem is defined in _Global_Functions.lua) end Last edited by pedro arzac; 11-15-2006 at 06:17 PM. |
|
#2
|
|||
|
|||
|
I have read a lot of post/threads in the forum about the key files, but honestly I don`t have any idea of how to make an .ini file, as long as I have read the best way to solve my problem of finding my app is using an ini file instead of a .exe that I`m using (It`s driving me and my team crazy)
If someone of the staff or some one that has had the same problem could help us we will appreacciate a lot |
|
#3
|
||||
|
||||
|
Quote:
Of course that means your patch needs to know where that ini file is...so the ini file needs to be stored in a commonly accessible location. An alternative is if your installer stores the location of your software in a Registry key. Then your patch can look in that Registry key to learn where the software was installed, so it knows what to patch. Another method which works really well is the "current folder" method, which just checks the same folder that the patch.exe is in. Or you can do a file search, although that's generally the worst method to use because it can take a long time and isn't as precise (you might find a backup copy of the software, for instance). Now, that only deals with one question: "where is the software to patch?" There is another question that needs to be answered by the patch: "what version is it?" The standard method that Visual Patch uses to handle the second question is to calculate the MD5 signature of one or more "key" files and compare that to the list of key file MD5s that was stored in the patch. In order for this to work, you need to make sure that you select appropriate key files for each version in your project. The key files are so Visual Patch can say, "okay if I find this file in the folder where they say the software is installed, and it has exactly this data in it, then this is the version that I've found." The key files need to be "unique to each version." If you choose a file in version 1 that is the same in version 3, Visual Patch won't be able to tell versions 1 and 3 apart. They'll both look the same to it. Think of this like comparing fingerprints at a crime scene. If it finds a match, it stops looking for other suspects. Its job is done. Quote:
In your posts so far you've included script that really misses the point...for example trying to use INI file actions to get the version from an .exe. I think you need to educate yourself a bit more on the subject. Based on the information you've been posting I think you have several things fundamentally wrong in your project (perhaps from being in a rush and trying different things to make it work ). That's why I recommend starting a new project using the project wizard, so you have a working script to start from.Patching is a complicated process. Visual Patch simplifies it a lot, but there are still some things that it can't guess...there's some information about your versions, and your software, that only you can provide. To put it another way: Visual Patch will do what you tell it to do, but you need to know enough to be able to tell it what it is you want it to do. It can do A, or B, or C...but you need to tell it which of those you want.
__________________
--[[ Indigo Rose Software Developer ]] |
|
#4
|
|||
|
|||
|
Hi Lorne
Yea I have notice that thinking in using an ini file was a really dumb idea, I was triying to solve one problem generating another.
The only file that could be my key file and exist in the machine of my client is the main.exe file and I know that I will change with the update is this. So for this reason I will choose these to be my key file. Quote:
The second option is very logic but I can`t make it work this is very frustrating. And the third option even giving to the software teh exact location it didn`t find it. I have checked the MD5 of my key files v1 815d39c5281c7e429f11280068a0990a v2 2cc909ada7e4ab0b0850413dee1c9d31 These were the results so obviously they aren`t the same, so the program should find the difference. And update it. Even I have tried using this line of code to tell the program the exact location of my program: g_InstalledFilePath = SessionVar.Expand("%SourceFolder%\\monitor.exe"); I have use the wizard changing completly the vpach file but I haven make a usefull patch. I you need that I attach my exe files and my patch file I will do it thanks |
|
#5
|
|||||
|
|||||
|
Quote:
Quote:
![]() Quote:
Quote:
Quote:
__________________
--[[ Indigo Rose Software Developer ]] |
«
Previous Thread
|
Next Thread
»
| Thread Tools | |
| Display Modes | |
|
|
All times are GMT -6. The time now is 07:12 AM.







). That's why I recommend starting a new project using the project wizard, so you have a working script to start from.
Linear Mode
