Hi,

I found it kind of upsetting that the trial version of VCP 7 took over my VCP 6 MRU. I don't expect nor want a trial version or full version of an existing product to obliterate my MRU's of installed apps. It breaks my train of thought and forces me to keep a separate spreadsheet for things I don't want windows (broken as it is in this case) and apps installed in it doing such things.

Also, I noticed that in my user profile, my MRU of files in the Registry is encrypted or mangled in some what that was not so back in version 6. There should be NO reason that a logged in user cannot see his/her own MRU. Anynoe knowing the password and having physical access to a computer will already have access to far more valuable information than the MRU. IF the MRU loggs remote sites (particularly if they are sensitive government or contractor or non-public URLs/etc ), that's one thing, but LOCAL files need not be encyrpted.

The MRU in the registry and in VCP are very important. You don't provide a mechanism that distinguishes between files being worked on and files being hunted en mass. After hunting through 10 or 11 files, the VC/VCP MRU trees is effectively destroyed. Stopping work for a few weeks means fervent hunting to regain a list that was wiped out.

What would be really kewl is if you bypass ms' maligned MRU 'feature" and provide us users a multipersonality MRU: Working and Hunting. The two would be distinct, and it would be something that the USER has to learn to use. You needn't do much special other than tell the users it is THEIR responsibility to ask the app to enable the hunt mode enable/disable option. After they finish hunting for and inspecting files, they can be asked to disable or make persistent the hunt mode. They could also be empowered to flag files (to avoid making lists and aliases and pointers and unnecessarily duplicated whole files) that are never to be removed from the MRU.

In short, MRU and MRI:

Most-Recently USED
Most-Recentnly INSPECTED

Once a user edits a file AND saves it, it could go to the MRU list. IF a user opens, browses, and inspects a file, then closes without saving, the user can be asked to discard the activity history or shove it over to the MRI. MRU is more effective when it aids the user in reopening USED files. It's lamentable that ms (and, in copying ms) Linux developers seemed to completely miss this enhancement opportunity.

I hope other developers can also make this distinction. Windows (and Linux, but I don't know about Apple) have sorely failed to grasp or implement this. Please be among the first to fix this paradigm!

Each and every installation of an app should maintain its OWN MRU/MRI even if it is the same user profile. It was this way before, but it broke somewhere in the past 6 months when I last enjoyed this and installed one or more VC/Shark apps trials/betas.

If I am sorely wrong, and this is a registry problem and completely NOT VCP/Shark doing it, I'll humbly receive slapping.

Thanks much!

Last night, I just had another/expanded idea regarding MRU.

Rather than have VC/VCP/Shark (or, any other app for that matter) keep track of the MRU information in the registry or in the "Program File" directory, save one baseline and subsequent, stamped history files in EACH DRAWING Folder.

For example, say one is a person who saves each drawing in steps as it progresses, maybe for historical or protection against crash and loss of too much progression all in one file. The user would initiate creation of a file. VC/VCP/Shark (or, any other app a developer distributes) would ask the user to indication whether or not to generate a seed which would serve as "DNA" for subsequent versions of the work. Files that are to be distributed with zero DNA would be "washed" or "stripped" of the seed so that valid or surreptitious queries across WANs/LANS/etc would not find sibbling or parent or descendent files.

The program would then on making a new file ask the user to generate the seed. Saved files would either have it or not, and if the user mistakenly says no to the seeding and regrets it, the user could drag and drop a "relative" file onto the one needing seeding, and then the app could do a deep inspection to determine a new seed ID. The more files dumped, the better the relationship can be structured.

Now, the actual timestamps, file names, and so on could be less important when searching for related files. Similar to when apps find duplicate text and photo documents. Versioning could be based on spawns of a file.

There was more I was thinking, but i feel my idea is a whole lot better than ms' and others' find file by date/time/name fragment and so on. I can only hope someone non-proprietary-minded devs take and popularize this so that for CAD purposes, it becomes a LOT easier to scan one's system and organize or lay out the progression and heirchial value of a file based on content quantity and content evolution. Of course, if one starts deleting massive contents of a file, the app could lose track, or it could keep the seed even though the two compared files may be nothing alike. So, Create/Save As Template/Non-Template might be one way to approach things so long as a user rigorously adheres to a personal workflow that evolves drawings of a given project.