[Tilt, TyTN II, MDA Vario III Windows Mobile ROM De] bengalih:
Ok...getting a little convoluted in the description there... but let me just say these things:

1) SASHIMI does in NO WAY look inside of CAB files for any of its functionality. Mortscript just doesn't have the capability to do anything in that respect. So, no matter what the CAB file looks like, all that matters is where the shortcut ends up in the file system after install that SASHIMI cares about.

2) If you install that CAB you attached manually (without SASHIMI) you will see that it installs its shortcut to \Windows\Start Menu not \Windows\Start Menu\Programs. Therefore SASHIMI can't operate on it since as I discussed, it only scans in \Windows\Start Menu\Programs for changes to the file system (and only one level deep).

3) SASHIMI has the ability to MOVE the shortcut to the root of \Windows\Start Menu, it just doesn't scan there for any changes.

All that being said, I have worked a little on re-doing how this process works and I think that most users will be happier with this new method I am going to use.

The new method is now recursive, but only looks for changes to file structure and not folders. The way it works is follows:

1) Prior to CAB install, do a recursive scan of every (link) file in \Windows\Start Menu.

Note that I am now starting the scan at the root of Start Menu

, since I can now do recursion. Every file found is recorded in an array.

2) After CAB install, the root of \Windows\Start Menu is again recursively checked and every file in the first array is compared to the current contents. If the file exists in the original array (meaning it was there prior to the CAB install) then nothing is done. If the file does not exist in the original array (meaning it is new) it is added to a second array of files on which to operate on.

3) Once all files are checked, the second array is then enumerated and every file in this array (which should be any file new from AFTER the cab install) is then moved to the location defined in the customlinks.ini (or deleted).

4) When a file is moves in step 3, if it was the last file in the directory, then the directory will be removed.

So, for example a CAB creates the following folder:

\Windows\Start Menu\Programs\MyCab

It places One.lnk and Two.lnk inside.

Both those link files will be added to the second array. The first one will be moved, and then the second one will be moved, and since it is the last file the MyCab folder will be deleted. That way, nothing is left from the CAB's original location and the shortcuts are located only where specified.

There are still a couple of problems with this method:

1) If the CAB file created multiple levels of program folders, the sub levels may not be deleted. This is probably a rare occurance as most CABS, although they might create their own program folder, probably don't create

2) In the same vein...if a CAB creates several folders of icons, each icon will be moved to the new location and will not keep the original stucture. So, for example if CAB creates:

...\Folder1\A.lnk

...\Folder1\B.lnk

...\Folder2\C.lnk

And your customlinks.ini says to move these to \Programs\MyProgs then you will just get A,B, and C inside MyProgs without reflecting that they were originally in 2 separate folders. Again this is unlikely since most CABs only create one or two icons, and maybe one folder. In addition, some users may prefer this becuase it allows them to automatically consolidate all icons to one location.

So...that is the new method I have and I think it will resolve the issues that most people report with the customlinks. Even with the problems it still has it will probably be more effective.

Expect to see it with the next release, hopefully over the next few days.