Cool

Thanks for explaining this in more detail.  Today I will start testing those new changes.

BTW, you won't believe this, but 2 days ago while testing a form which has 2 listview controls, as an end user, I felt the need to add a DoubleClick action to edit the selected record, and boom! you just implemented that feature in this release, it couldn't be better than that!

Edhy Rijo

Yeah, we have been using this extensively as well...so that keeps the features coming

One thing I thought I would point out on this new release is the BOs SaveCurrentDataTableToSnapShot and RestoreCurrentDataTableFromSnapshot methods.  These were implemented specifically for the ListView and performing Undos if their was a cancel out of a child dialog form.  The complication without this was the following scenario:

1. Add a new child record
2. Click OK on child dialog to close the child and keep the new child record in the BO
3. Select the new child record from the ListView and edit the record
4. Click cancel

At this point prior to this method, if you performed an Undo you lost the new record because it technically still had a RowState of Added.  With the Save and Restore snapshot methods, you never need to call Undo.  You should always let the ListView perform an automatic snapshot (does by default) then just call the Restore if the end-user cancelled the child dialog.  This way it is always 100% accurate in regards to what the end-user has been doing.

Well, since this seems to be an isolated issue then I will not waste a lot of time and just say what I did to get back to a working stage:

• I disabled all antivirus, spybots, etc.
• Uninstalled SF and manually remove the assemblies from the C:\WINDOWS\Assembly
• Reboot
• Reinstalled SF and got same missing file error, and canceled the installation.
• Copied the Triggers.xml to C:\Users\Edhy\AppData\Local\Temp\MicroFour\Metadata
• Reinstalled SF and it completed.
• Checked SF version and had the same screenshot as before with different versions.
• Checked SF assemblies in C:Windows\Assembly and they all have correct version 1.6.5.2
• Checked SF assemblies in C:\Program Files (x86)\MicroFour\StrataFrame\Assemblies and they are also correct 1.6.5.2
• Now last place to check C:\Program Files\Common Files\MicroFour\StrataFrame here the assemblies where not updated, they all have version 1.6.5.1 (see image attached) and also I believe this may be the caused of the missing file since the *.pkg files may not be updated.  So for now my fix was to copy the correct assemblies to C:\Program Files\Common Files\MicroFour\StrataFrame.

Tomorrow if I have some time or in the next update I will do all steps above and will also manually remove C:\Program Files\Common Files\MicroFour\StrataFrame before installing to see if that takes care of future installations.

P.S.

I am very happy with all new features added, specially those related to the ListView which I use a lot in my current project.

Edhy Rijo

This says a lot about what you may be facing, also your screen shot says a lot as well.  This is clearly not the norm otherwise this would be a major issue for us all. 

If you'll notice, your assemblies are not getting updated.  This could all come from my previous posts suggestions.  All of your files should show a version of 1.6.5.2.

Good news!  There is nothing wrong with the installation and it works as it should!   So this means that for whatever reason (will list some below) your StrataFrame.pkg file did not get overwritten and so the new programs were trying to use the old PKG file.  Also, I have tested this on both 32 and 64-bit OS environments (including Vista) and it works in all environments.

Some possible reasons the StrataFrame.Pkg file did not get overwritten:

1. Insufficient permissions
2. File was open by another process (unlikely unless you manually opened)
3. Real-time virus protection attempted to scan and prevented the update of the file.  I have seen this more and more lately....I am not a real-time anti-virus fan.  In fact, I have dealt with viruses that are not as mean as the real-time stuff...OK, that is enough of a rant on that point!

I would check these and see if any are possibilities and try again.  The installation does work so something is getting in the way of the files being updated...all of this falls in line with standard MSI coding standards.

Thanks for the quick response, I thought that you may not be at the office at this time.

Doron Farber, installed the update without a problem and I asked him to send me the trigger.xml file and I copied to the expected location, ran the setup again and it finished without any error.

Here is my Version status in the attached file, which I believe is not OK, so once again in my setup something is not right, but nothing to worry about it, I am getting used to the install not working on my setup without some manual help

Edhy Rijo

I have tested the install in a number of environments without issue, so I am in the process of trying to reproduce your issue.  It seems like the StrataFrame.pkg file did not get overwritten on your machine and is trying to use the old StrataFrame.pkg file, which doesn't have the triggers.xml file within it.  I am proving that the installation is correct and then we can go from there.

FYI, the file C:\Users\Edhy\AppData\Local\Temp\MicroFour\Metadata\triggers.xml is not in the expected folder, so it may be missing in the original installation. 

See attached image for a list of files in this folder: C:\Users\Edhy\AppData\Local\Temp\MicroFour\Metadata

Edhy Rijo

Hi Trent,

Installing the SF 1.6.6 Beta update, I got an error when Building StrataFrame Databases.  Please see images attached.

The process is looking for a Triggers.xml file.

Edhy Rijo