LISTs in Version 6

Addendum for version 6.1 -- It would appear that ScanSoft has fixed the problem of exporting ALL of a user's lists with any export. I am leaving this page in for background and for information some users might not know. Congratulations, ScanSoft.

LIST handling in version 6 has several differences from version 5. The most obvious is that of the nomenclature for referencing LIST values in the body of a macro. Version 5 used the syntax of _arg1, _arg2, etc. Version 6 actually has 2 ways of referencing list arguments: UtilityProvider.ContextValue(0),UtilityProvider.ContextValue(1), etc. OR Listvar1,Listvar2, etc.

All LISTs are now Global

The next most important change is very positive in that all LISTs are now Global in scope. That is, every macro (both legacy types and new version 6 types) has access to all LISTs. This is a big improvement over version 5 where LISTs were only local in scope to each STATE. One nice effect of this was when I wanted to change a couple of my macros that used the LIST <1to20> (backspace <1to20>). All I needed to do to get a much bigger range for the command was to change the list to <fontsize>. <fontsize> is a built-in LIST that goes from 1 to 100 and a little beyond. There was no need for me to enter all those numbers from 1 to 100, they were already there (for any command in any scope).

Exporting gotcha

One downside to the current handling of Exported LISTs is that even if you only export 1 command, All of your LISTs are present in the exported .dat file. Try it. Use Notepad to look at your exported .dat file. It will look kind of funny with binary values in it, but you can clearly see all your LISTs present. [Note: do not do a File, Save]. This would be no big deal if you were never going to give/share/sell this file to another person. Presumably the Export, Import commands were designed with this in mind, so the fact that an Export puts all your Lists into the Exported file is somewhat of a security risk. For instance, some people might have LISTs with things like credit card numbers, passwords, or other private information as LIST elements. If they wanted to Export macros to give/share/sell to other people, they would only be able to do so with the above risks in mind (or perhaps they weren't even aware of this at all).

Furthermore, whenever you Import someone else's Exported file, any LIST that is in the Exported file that is not present already, is imported and ready to be used, so the risk is not only present in the Exported file itself, but also in the fact that those LISTs or LIST elements are visible to the user in the Name Editor.

One other behavior of note is that if a LIST name exists in both places, but the contents are different, the current user's LIST contents are retained as they were, rather than reflecting the contents of the Exported file's LIST. (Let me know if anyone has any experiences different from those described above).

The solution? TrimLists.exe

I (and others that I have talked to) believe that this current behavior of Exporting all LISTs is inhibiting the ability of people to give/share/sell macros or groups of macros, I have written a program to remedy this situation, called TrimLists. It takes an Exported .dat file, reads its commands, makes note of actually use LISTs, and then produces a file containing only those LISTs actually used, thereby eliminating the security/privacy risk. I have decided to make this program available for free for non-commercial usage, and for a modest fee ($19) for anyone charging for macro file distribution. This should encourage more distribution of macros on the free and for fee level both. Please respect these parameters. You don't have to charge for macro file distribution to register of course!

New SayWhatPro feature:

To make it easier to deal with Exported .dat files, I have added a File, Open command to SayWhatPro (version 1.1). I found this facility invaluable in learning about LIST behavior and for looking directly into an Exported or about to be Imported file.

Download