>>I am most curious where you got the idea that you
>>could make a suggestion in the Thor forum and it
>>would be up to somebody else to write the code
>>or you.
>
>I offered to code it or large portions of it. What I received back in several responses were negatives (replies that began with something like "Unfortunately..." or "That would be nice, but..." or "It wasn't designed to...", etc).

All of that is accurate enough. The one thing you saw in Thor, a tool to assign MDots, did not really provide you with the information you would need for what you wanted to accomplish. Unfortunate, but true.

>
>I came away with the impression that Thor was not really capable of doing what I asked, nor were any of the developers involved desiring to step outside of the existing methodology of processing "m." prefixes to examine the request from another perspective. In addition, it seemed the necessary infrastructure wasn't there, as there were planned future features which were currently of low priority necessary to make it happen which may or may not come into existence, and the algorithm which processed the "m." prefixes did not know where the file came from, etc., so there was a disconnect internally about how it could be stored.

I can't control what impression you got, of course, but the limitation in Thor is -- well -- if you can call a PRG to accomplish a task, it can be done in Thor. In fact, it's quite easy to take any existing program to make it available in Thor. That limitation was in your perception. So, if you could write a PRG to do what you want, it could easily be accommodated in Thor.

>
>All of these factors indicated to me a lack of desire or belief that the suggestions I made warranted inclusion. And in short, the attitude I received was of such a kind that I moved on to complete the work in Visual FreePro.

We welcome all new tools in Thor. Some tools are not widely used until they are published and understood. Others only apply to a small audience. (The tool that adds M.Dots, for instance, is not going to be used by everybody).

I believe you may have confused the response of "there is not as much here to build on for your suggestion" with "there is no interest in your suggestion".

>
>>If this issue is so important to you and the amount of
>>new work, as you say, "would not be significant", I
>>have to wonder why you have not already created it.
>
>I have all the pieces already built, as likely is already done in Thor. These pieces will be assembled into this concept and integrated into Visual FreePro (James 4:15).
>
>I have not already written it because, like you, I've never seen a need to code "m." prefixes on every variable reference, so I've never needed it. It was only after the consistent insistent positions offered up by Koen (who remains absolutely adamant to this day), and Tamar, and a few others, that "m." prefixes were ABSOLUTELY ESSENTIAL that I began to realize that they are essential IF the ONLY tool you're using for validation or security is VFP itself. But, if instead you can validate EXTERNALLY (via some tool like Thor) that no such name collisions exist in your project, then the "m." prefixes can be removed in all areas except where foreign tables will be opened and used, and your code can be much cleaner. And, as other people have indicated, the performance hit by not using "m." prefixes is negligible.

Yup, there are M.Dots Enthusiasts around, as even can be seen in this thread on the UT. The make their voices heard here, just as they did in the Thor forum. That doesn't mean that they speak for anybody else, just themselves, even if they are highly visible because they are so vocal.