Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Bindevent to a property
Message
De
11/04/2013 12:44:34
 
 
À
11/04/2013 11:34:20
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Versions des environnements
Visual FoxPro:
VFP 9 SP2
OS:
Windows 7
Network:
Windows 2003 Server
Database:
MS SQL Server
Divers
Thread ID:
01570434
Message ID:
01570751
Vues:
44
>>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.
>
>Having written this ability myself (parsing VFP source code and identifying variable references), and knowing that there are only so many ways to skin a cat, I recognized what was required to make this happen. If you're able to identify variables from source code syntax from VFP source files, forms, classes, etc., in Thor (which you obviously are), then every piece of information I need to carry out this work exists except the additional comparison logic and integration setup. As for the existing code, it's just a matter of refactoring a few algorithms to handle this new ability.

If what you say is true, and you were really interested in this, you might well have said ... "point me to the code that finds the variable names for MDots, and I'll make the necessary (and simple) modifications to make it work".


>
>>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.
>
>I did realize this. But, I was told, "Thor wasn't designed to do..." so I responded with an explanation of how it could be done, offering also to code it for Thor.

No, not that Thor was not designed to do that, but rather than the existing tool in Thor was not designed to do that.

In one of the last messages in the thread on the Thor forum on this topic, I wrote:

If you think it is of general interest, feel free to submit it to be incorporated into Thor so that others can use it.


>
>>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".
>
>Perhaps, but I don't think so. I think there is almost ZERO interest in my suggestion because people see a usable, workable solution by prefixing everything with the "m." text and being done with it, or by not using "m." prefixes and "risking" the danger of having it crash when some unexpected collision comes about.

Unfortunately, you were mis-led by the flurry of messages by a few M.Dot Enthusiasts, who were offering their solution to the problem. Actually, your sales pitch on this suggestion would not appeal to them anyway -- they would not need it, would they, if they had already take care of the problem?

Instead, your solution could only be of interest to those who don't use MDots -- they are confident, as well, that they have taken care of the problem, but your proposed tool could identify for them any cases where they were wrong. Very handy indeed, I would take advantage of it.

But non-MDot users are not enthusiasts, nor are they very vocal. If you were only going to pursue your proposal if there were sufficient interest, I think you should have made a clear statement of what it was trying to achieve and ask whether anybody else would be interested in it if provided.

>
>My personal interest in not using the "m." prefix solution is because it's beyond completely hideous. It also affects my ability to read the code as I have dyslexia and already have enough trouble reading code. It's why all of my source code is aligned visually.
>
>If I ever show up at a general VFP convention of some kind, I will consider wearing a T-Shirt which reads:
>
>On the front:
>t.Good
>m.Bad

I could not disagree more. To me, MDots are neither good nor bad. They are one of at least two solutions to a problem that we all may encounter. Everybody chooses the solution that works for them,
Jim Nelson
Newbury Park, CA
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform