6.6 delay in execution vs 6.7

[Johnc]

Mmm... more testing from old macros with MMM V6.7.0 has shown problems again. Switching back to V6.6 solved it.
I am guessing V6.7.0 has much less delay in execution, therefore causing the problem. It would have been nice
to have a converter to convert V6.6 macros to V6.7.0 macros by adding time delay automatically, such that the V6.6 macros
would slow down to work with the faster V6.7.0.

I think I am keeping both the V6.6 and V6.7.0 MMM applications on the desktop to avoid debugging the old V6.6 proven macros while running on MMM V6.7.0.

[Steve]

Hi John,

How much faster are you finding execution using 6.7 rather than 6.6? Version 6.7 (like every new version) adds to improve what I like to call the 'macro processing engine' to make macros run cleaner. I haven't experienced a great deal of execution speed change with the new version. I do recommend using the newer version over the old one. Version 6.7 internally is better than 6.6 and will make for smother running and recording.

[Johnc]

My mistakes Steve. My apology. The misbehavior of my old v6.6 script was not caused by timing issues.
After spending time debugging the old v6.6 script in MMM v6.7, I found where the problem was:


8 | RUN ACTION | | | | DEFINE INTEGER VARIABLE | %INTEGER1%::%CLIPBOARD%

9 | RUN ACTION | | | | MESSAGE PROMPT | %INTEGER1%::clip


In MMM V6.6,  when %CLIPBOARD% contains 1234,  Line 8 would assign integer 1234 correctly into %INTEGER1%, giving a prompt output of 1234

In MMM V6.7, however, the prompt output would be a 0

I certainly hope that this behavior of V6.6 would be passed onto future versions as it is very difficult to store a snapshot of %CLIPBOARD% in MMM. 

Thank you Steve for your help!

[Steve]

Yes your right this is now a little different. The difference is the way 6.6 defines new %integer% variables. 6.6 is happy to pass the string word %clipboard% to %integer% and then check if the contents of the clipboard is a word or a number. However 6.7 does not want to accept a string word at all when defining a new numeric value into any %integer% variable. From memory the change was made due to some tweaking of the interval variable system with the addition of all the FOR loop variables. I will look to changing this I think. As you've pointed out I think it would be better to check first the contents of a string variable when it is passed rather then cut it all together.

Cheers,
Steve.