Changes To App - PDW 2nd Time - Looks Same??

This may sound really lame, even dumb?? My problem is described below: Can someone tell me what i'm doing wrong.....

1) Made App. Made an EXE. Used PDW to comple and run in lab. App is OK, no problems.

2) Made some changes to my app. Made EXE. Used PDW again - used setup.exe, as before to load on computer in lab again, BUT the app shows OLD app, no changes......:confused:

3) So i changed the name of the .vbp and erased the first one, now i erased the old .exe, made a new one.......Used PDW again......this time i checked the support folder and pressed the NEW .exe.....it looked OK???? Now i used the setup.exe to place on same computer in lab.......Still i get the OLD exe???:confused: Can someone PLEASE help me....what am i doing wrong??


QUESTIONS:

Should i not be able to make changes to my app. then make my exe and should it not show up when i redeploy it???:confused:

Is it better to make the .exe in VB6, or let it compile it with the PDW, did this too, same thing......??? please explain....probably doing something wrong.....1st time compile is always OK

It usually best to uninstall the original and then install the new program.

When making changes:

If you are not using a source management tool (SourceSafe or something else) it is often best to copy the entire project folder as a backup with the old-version number before making any changes.

To make version 2 of MyApp copy your MyApp folder as MyApp1. Then open the MyApp folder, open the VBP project, update the version number of the project, make changes and test, do a final compile and save, then package version 2.

It is usually a bad idea to rename individual files in a project. The file names of source modules may end up mismatched with names stored within the VBP and other source files. The names of other files (EXE, data files, etc.) may end up being mismatched with those within the saved packaging scripts, the registry, etc.

If the PDW discovers that the compiled EXE is older than the VBP and module files it offers to recompile, assuming you've made changes. Avoid this by always doing a save before your final make in the IDE.

open the setup.lst file with notepad and see if it is using the correct .exe name
If you make a new exe PDW uses the old name. Change the name of your exe
in the setup.lst file to the correct name. I have got into the habit of always checking this file and often make changes

It usually best to uninstall the original and then install the new program.

When making changes:

If you are not using a source management tool (SourceSafe or something else) it is often best to copy the entire project folder as a backup with the old-version number before making any changes.

Quote:

---

To make version 2 of MyApp copy your MyApp folder as MyApp1. Then open the MyApp folder, open the VBP project, update the version number of the project, make changes and test, do a final compile and save, then package version 2.

It is usually a bad idea to rename individual files in a project. The file names of source modules may end up mismatched with names stored within the VBP and other source files. The names of other files (EXE, data files, etc.) may end up being mismatched with those within the saved packaging scripts, the registry, etc.

If the PDW discovers that the compiled EXE is older than the VBP and module files it offers to recompile, assuming you've made changes. Avoid this by always doing a save before your final make in the IDE.

---

This makes great sense, thankyou.......ever much. Could you please answer the following question to help me to understand this? thanks:)


1) When finished with PDW there are 4 groupings of files. a) Support, b) Cabinet Cab.exe, c) Setup.exe, and d) Setup list........Can you explain What files *change* if I don't add any controls but just change the code then redeploy?

2) Why are files *duplicated* in the support folder and in the Cabinet files? What is happening here?

3) When Setup.exe is press, which VB6 files are deployed [not the file names], but from where? The support folder?

4) The NEW Cab.exe single file deployed is in the Support folder correct? Not from the Cabinet files? [as this one asks for a CD to be entered]???

thank you much for helping me here:) Do i have to create a new version every time code only is changed? thanks again, you explainations will be of great help in my understanding of this, thanks loads.......

Quote:

---

open the setup.lst file with notepad and see if it is using the correct .exe name
If you make a new exe PDW uses the old name. Change the name of your exe
in the setup.lst file to the correct name. I have got into the habit of always checking this file and often make changes

---

thank you soooo much, did not know this. great help......

Can you explain to me..........if i make a NEW Cab.exe in VB6 and copy this file to the Support folder, taking out the OLD one and then change the setuplst as you say, should this work OK? i am assuming no canches to controls, etc, as this will probably change the files in the support folder + Cabinet Cab.exe files? [correct?]......

this is a great help thanks much......:)

you guys have been great, thanks again.............

Quote:

---

Originally Posted by Ashly6000

thank you soooo much, did not know this. great help......

Can you explain to me..........if i make a NEW Cab.exe in VB6 and copy this file to the Support folder, taking out the OLD one and then change the setuplst as you say, should this work OK? i am assuming no canches to controls, etc, as this will probably change the files in the support folder + Cabinet Cab.exe files? [correct?]......

this is a great help thanks much......:)

you guys have been great, thanks again.............

---

Not sure about that, you might want to read this:
http://www.jsware.net/jsware/vbcode.php3

Basically the only thing you need to do is to change the version number then recompile the app. If the installer checks the exe and finds the same version as the one you are installing it WILL NOT replace the exe.

Quote:

---

Basically the only thing you need to do is to change the version number then recompile the app. If the installer checks the exe and finds the same version as the one you are installing it WILL NOT replace the exe.

---

thanks......what are you saying here. Changing version number is generally OK.......so what can be done by the installer then? just use the Cab.exe in the support folder? What if it's a first time install?


Can someone please explain the questions i asked above. thanks.....:)

Quote:

---

Not sure about that, you might want to read this:
http://www.jsware.net/jsware/vbcode.php3

---

thanks....read it......not sure how this answers the questions i asked. can you please clerify for me?:confused: thanks loads.........

Quote:

---

Originally Posted by Ashly6000

thanks......what are you saying here. Changing version number is generally OK.......

---

Yes, that is what you are supposed to do to keep track of what you are using. Use the revision number for each compile and it will always change. Of course use the automatic change feature so you dont forget.

Quote:

---

Originally Posted by Ashly6000

so what can be done by the installer then? just use the Cab.exe in the support folder? What if it's a first time install?

---

Why worry about the installer it will handle what it should. A first time install will not have your exe to replace ???:confused: :confused: :confused:

Loads and loads of these kinds of questions are answered in the VB documentation. You can find this online at:

Visual Basic Concepts: Distributing Your Applications

Ashly ... if you haven't made big changes, you don't need to "install" at all. Simply copy your new executable app to your lab machine (overwriting the old version). I think you'll find it runs fine.

(I do this all the time with various projects that are for single users. If you need to distribute to various << new >> users, that's a different matter and you do need to fix the PDW's setup.)

Quote:

---

Ashly ... if you haven't made big changes, you don't need to "install" at all. Simply copy your new executable app to your lab machine (overwriting the old version). I think you'll find it runs fine.

---

yes i know, thanks.........can you explain to me if i can take the NEW exe and place it in the support folder and redeploy it without using the PDW again??? [assuming that only code has changed and no added controls]........... :)

Quote:

---

Loads and loads of these kinds of questions are answered in the VB documentation. You can find this online at:

Visual Basic Concepts: Distributing Your Applications

---

yes, thankyou i found this very good, but unfortunately it does answer the questions i asked above.....can you help? can you answer these?? i really want to understand what is happening with these files, thanks:)

Quote:

---

Yes, that is what you are supposed to do to keep track of what you are using. Use the revision number for each compile and it will always change. Of course use the automatic change feature so you dont forget.

---

you are correct, thank you......can you answer the questions above? if you can i am grateful to know......:)

can you explain to me if i can take the NEW exe and place it in the support folder and redeploy it without using the PDW again??? [assuming that only code has changed and no added controls].......

I don't think so. The app.exe gets folded into the .cab file by the PDWizard.

You put the new exe in the support folder then run the .bat file thats there to create a new .cab file.

Quote:

---

Originally Posted by randem

You put the new exe in the support folder then run the .bat file thats there to create a new .cab file.

---

Exactly. The purpose of the Support folder is to allow you to repackage after compiling a changed EXE.

As described in the documentation cited above, there are several options for silently packaging an application. One is to run the BAT file (which you can remove the ECHO and PAUSE from). The other is to run PDCMDLN with a saved PDW script passed as a parameter.

These are used for automated/scripted builds as part of a formalized "make" process.