dhoward Admin Group
Joined: June 29 2001 Location: United States
Online Status: Offline Posts: 4447
|
Posted: March 03 2014 at 10:36 | IP Logged
|
|
|
Paul,
I took a look at the source code and then best I can come up with is that since the read info is so long, its firing the socket twice to get the message in a couple of chunks. However, I would expect the first time the macro is run, the [TEMP5] variable would contain the first chunk and the second time the macro is run, the [TEMP5] variable contains the second chunk (and contains the data of interest to you). Based upon your description though, it sounds as if the first time the macro runs, you get the first chunk and the second time the macro runs you get the complete message including the first chunk.
In any event, assuming the complete data is roughly the same length with each call, I would think the best way to handle this is to check the length of [TEMP5] in the Boolean formula of the trigger.
Say the first time the macro runs, you get 600 bytes of data. The second time the macro runs, you get 850 bytes of data. You could place this formula in the Boolean field:
len(ph_getvar_s(2,5)) > 800
and the trigger will only execute the macro if the length of the data is over 800 bytes. You could also do variations of this formula by searching for a particular unique string portion that would only occur in the complete message.
I think this would give you cleaner results than killing the macro.
Hope this helps and let me know how it goes.
Dave.
|