INI value wildcard

[instrumentally]

I utilize an INI file with my installation which (after the installation is successful and the program runs) contains a Boolean value that is named based upon my program's internal version info. IOW, if my compiled program (I'm not referring to the SetupBuilder install EXE) contains an internal version string of 1.0.0.0, that value is then written by my program to the INI file. Example:

[Settings]
Beta_1.0.0.0=1

(This value does not exist in a virgin, first-time-ever install.)

In subsequent installations, I'd like my SetupBuilder install to read the existing INI file and preserve this information in the new INI file that is created by SB. The problem here is that this value is not static and therefore I cannot instruct SB to retrieve an INI value since I don't know whether the INI contains this...

[Settings]
Beta_1.0.0.0=1

...or whether it contains...

[Settings]
Beta_1.0.0.0=1
Beta_1.0.0.1=1

...or whether it contains...

[Settings]
Beta_1.0.0.0=1
Beta_1.0.0.1=1
Beta_1.0.2.9=1

I'd like to have all of the Beta_#.#.#.# values preserved in the INI file after each installation. How would I accomplish this? Would it be best to create an INI section that is used solely for these Beta_* values? E.g.

[Settings]
Left=100
Right=200
Username=John

[Beta values]
Beta_1.0.0.0=1
Beta_1.0.0.1=1
Beta_1.0.2.9=1

[MoreSettings]
Blahblah=0

[linder]

Hello,

I have to give this some thoughts and get back to you...

Friedrich

[instrumentally]

Another issue to consider...

When the user is in the Script Editor window and then changes the line height value to "1" via "Tools > Options > Editor", then clicks OK, then goes back and change it to "21" and clicks OK, the vertical scroll bar is missing *until* you take your mouse and click inside the Editor window.

[instrumentally]

I am having a problem with a web deployment built by SetupBuilder Developer Edition 2017 Version: 10.0.5452

When I click the COMPILE button, the compilation succeeds without any errors. There are no error messages with respect to the FTP process. When I then run the resulting .exe, there are no errors UNTIL about 15% into the download of the 201 sub-units on the web server. No matter how many times I try, the installation hits a brick wall at the same point. See attachment... 4577

Again, there are no error messages during the compilation. I've rebuilt the .exe multiple times, and yet the installation error always occurs at the same point.

[linder]

Hello,

that simply means the file (default.css) on the server is not the file that has been added to the script when you compiled the installation. This has nothing to do with the SetupBuilder version you are using. The installer does a CRC32 check and the file downloaded (from your server) is not identical to the file on your development machine at the time when you compiled the setup. This feature is there to protect your customers. This is not a compile issue... the only problem is that the files downloaded are outdated.

BTW, if there is a proxy involved, it's very well possible that you got an old file from the cache. Make sure that you are using the "no-cache" web installer option. Mark this checkbox to use the "Pragma: no-cache" HTTP header to disable caching for a particular page.

Hope this helps a bit.

It's similar to this:
http://www.lindersoft.com/forums/showthread.php?20832-quot-File-Expected-from-server-and-received-do-not-match-quot&p=39438&highlight=no-cache#post39438

BTW, the office is closed for vacation until August 30, 2017 and we do not check the web forums on a daily basis.

Friedrich

[linder]

By the way, I'll check back later today or tomorrow morning to see if this solves your problem. The good news is that it's not a bug in the software so we do not have to wait for a new build.

Friedrich

[instrumentally]

The "Pragma: no-cache" HTTP checkbox is set to True when I reported the above/original issue.

The only way I was able to resolve the problem was to add new files to the install package and then recompile. SB is doing the transfer to the FTP server, BTW. I am not manually copying the deployment files.

[linder]

Hello,

so the problem is resolved now?

Thanks,
Friedrich

[instrumentally]

No, the problem has not been resolved. You can see the problem retraced in this video:

https://vimeo.com/227299161/2daa64edec

[linder]

Thanks for the video!

I'll be back in the office on next Monday and would like to analyze the problem. Would it be possible for you to send me your .sbp project file and the created .exe file?

Here is how it works. At compile time, the CRC32 of all files to be downloaded is created and stored in the web installer .exe. At runtime, the installer downloads the file and checks the CRC32 before it copies it to the final location. We do not get a download or unpacking error, so there is no transmission error. But the CRC32 of the downloaded file is NOT the expected CRC32 value stored in the .exe. We have to find out why this is the case.

I do not have the tools here with me to analyze the problem :-( I am sorry for the delay in resolving this issue. It's my #1 priority for next Monday.

Friedrich

[instrumentally]

Would it be possible for you to send me your .sbp project file and the created .exe file?

Here are the files you asked for:

http://hostsafe.com/temp/sb.zip

[instrumentally]

The LOG file for the SB session can be found here:

http://hostsafe.com/temp/sblog.txt

[instrumentally]

FWIW, I renamed the target folder where all the deployment files resided on the server and created a new folder, giving it the original folder name. Then I simply copied all the files from my local hard drive to the networked folder (which I just created). I did this so that I could bypass SetupBuilder's FTP transfer process. I then ran the .EXE. The same result occurred. This indicates that the flawed files are being created by SB locally, and that the FTP transfer process is not to blame.

[linder]

Thank you!

Friedrich

[linder]

Perfect! Thanks for the upload.

Friedrich

[linder]

Thanks for the info. We'll debug it on Monday. Please do not remove the files from your server.

Thanks for your help.

Friedrich

[linder]

Hello,

would it be possible to ZIP your original "homepage1.htm" and upload it here or send to support [at] lindersoft [dot] com?

Thank you!

Friedrich

[linder]

Hello,

I did a quick check. Your executable is time stamped Thursday, July 27, 2017 7:55:52 PM. I executed it and analyzed the cluster file for "homepage1.htm".

The installer expects a "homepage1.htm" file with a date/time stamp of 2017/07/27 -- 09:35:15, file size of 8,663 bytes and a CRC32 of 947437CA. But on your server there is a "homepage1.htm" with an older date/time stamp of 2017/07/25 -- 03:58:11, file size of 8,724 bytes and CRC32 of 59208d77.

Then I checked the inword.csv. This lists all packaged files (including file/date stamp, etc.). This information comes directly from the compilation process. File ID 38 reports "homepage1.htm" 2017/07/27 -- 09:35:15, file size of 8,663 bytes and a CRC32 of 947437CA. So the compiler packaged the correct file, but on your server there is still an older file!

For whatever reason, the cluster file on your server is definitely wrong (two days older than the expected file).

Friedrich

[linder]

Please see the attached screenshots. Files do not match and the installer verification mechanism protects you from installing the wrong file.

Friedrich

[linder]

BTW, are you sure you did not change the location on your server? I see "demo\deployment" in your upload (from your sblog.txt) but only "deployment" (with no "demo") in your download (from your project file). So perhaps you are still downloading from an OLD test location (dated July 25)?

Please send me the "inword.exe" from your "inwordbible.com/deployment" folder and I'll check this.

Friedrich

[linder]

FOUND IT! See attached screenshot.

The inword.exe in your inwordbible.com/deployment web folder is dated 2017/07/25. So IMO, all the files are dated 25-JUN-2017 and not 27-JUN-2017!!! I think you uploaded all the newer files to another location but you still point (in your download) to the old location (even from your inword.exe dated 2017/07/27).

The inword.exe you sent me is dated 2017/07/27.

As far as I can see, all your NEW files are located at http://inwordbible.com/demo/deployment but you still instruct the installer to download from (the OLD location) http://inwordbible.com/deployment.

Just downloaded the inword.exe from your http://inwordbible.com/demo/deployment and it is the new one (dated 2017/07/27)!

Friedrich

[linder]

Solution: change the "Host Directory" from deployment into demo/deployment, recompile, and you are done.

Does this help?

Friedrich

[instrumentally]

I have to give this some thoughts and get back to you...

I am still waiting for a response to my postings from July 14 and July 15, not to mention the following issue...


I am sorry for the delay in resolving this issue. It's my #1 priority for next Monday.

Monday was 3 days ago.

[linder]

Here is the analysis from SATURDAY!

http://www.lindersoft.com/forums/showthread.php?47685-INI-value-wildcard&p=88572#post88572

Friedrich

[linder]

I am still waiting for a response to my postings from July 14 and July 15, not to mention the following issue...

BTW, this one is something that has nothing to do with SetupBuilder per-se and is some kind of consulting. I don't have an idea yet on how to handle it.

And the solution to the "issue" you mentioned was posted on Saturday.

http://www.lindersoft.com/forums/showthread.php?47685-INI-value-wildcard&p=88573#post88573

Friedrich

[linder]

I am still waiting for a response to my postings from July 14 and July 15, not to mention the following issue...

Monday was 3 days ago.

Yes, but I already posted a solution 5 days ago!

See attached screenshot. I already answered on SATURDAY (July 29, 2017)!!

Friedrich

[instrumentally]

Yes, but I already posted a solution 5 days ago!

With regards to the July 15th question, the following comment by me was never responded to:


When the user is in the Script Editor window and then changes the line height value to "1" via "Tools > Options > Editor", then clicks OK, then goes back and change it to "21" and clicks OK, the vertical scroll bar is missing *until* you take your mouse and click inside the Editor window.

[instrumentally]

See attached screenshot. I already answered on SATURDAY (July 29, 2017)!!


The only email notice pertaining to this thread that I received on Saturday was posting #14. In #14 you simply said, "Thank you." No other email notices between your posting #14 and #24 were ever received so I assumed that the CRC issue had been forgotten.

[linder]

Perhaps the notification e-mail made it directly into the Spam folder, I don't know. The vBulletin system handles all this completely behind the scenes.

Friedrich

[linder]

We'll see if there is something we can do here. The development system (Clarion) handles this automatically, so I am not sure if we can fix it or if we need a fix from the development system vendor.

Friedrich