08-22-2007, 07:59 PM
Between yours vs. my function comparison and the fact that backspace/resubmit won't work for a period of time (whereas mine is immediate) narrows it down a good bit.
With del line active, and a cookie in folder, I get correct behavior every time:
Upon macro del line:
Upon Submit:
Repeat results same.
----so here's the interesting bit, please correct if not true to your results----------
CASE Del Line Active. The del line has nothing to delete because in every prior run it is deleted automatically and immediately. As a result, you do not get a output from file monitor at the point of macro del line.
The phantom behavior can be observed/hypothesized as:
Upon first run or following a macro run with a short and perhaps varying time-out period of a minute-ish, the cookie is deleted immediately after creation, but manages to live long enough for you to hit OK so the macro can get the data out.
If you leave the browser open and rock back and forth between message and submit html pages, it NEVER writes a new cookie, even if you change the data in the text fields, and even if you wait a minute or more between submittals (in other words, it appears the browser session MUST be closed before it will ever rewrite cookie [vs mine, which as expected writes new cookie every time, without fail, without delay]).
CASE Del Line Inactive. This results in correct behavior every time (if cookie already exists at runtime) because the cookie that gets phantom deleted upon submittal is actually the previous run's cookie as we saw in your earlier post: [1], [1], [2] or [2], [2], [1]
----
Symptoms seem to point to cookie being treated by browser/ie settings as session-only and probably page-only life span instead of using the actual expiry date, which is what my systems are doing. The wait period is probably the opposite of what it appears - post waiting time, the (incorrectly interpreted) session cookie deletion routine is slow on the draw, remains ready to destroy for about a minute, and is forced out of cache and back into semi retirement by OS) .
Until I can figure out why cookie is being degraded on your system (and possibly others), the work-around/safeguard method is to remove delete line, and even set.file a cookie at beginning of macro if one doesn't exist already to kickstart the [1] [2] alternating.
With del line active, and a cookie in folder, I get correct behavior every time:
Upon macro del line:
- 2 C:\Documents and Settings\Steve Murphy\Cookies\steve_murphy@~~local~~[1].txt
Upon Submit:
- 1 C:\Documents and Settings\Steve Murphy\Cookies\steve_murphy@~~local~~[1].txt
8 C:\Documents and Settings\Steve Murphy\Cookies\steve_murphy@~~local~~[1].txt
Repeat results same.
----so here's the interesting bit, please correct if not true to your results----------
CASE Del Line Active. The del line has nothing to delete because in every prior run it is deleted automatically and immediately. As a result, you do not get a output from file monitor at the point of macro del line.
The phantom behavior can be observed/hypothesized as:
Upon first run or following a macro run with a short and perhaps varying time-out period of a minute-ish, the cookie is deleted immediately after creation, but manages to live long enough for you to hit OK so the macro can get the data out.
If you leave the browser open and rock back and forth between message and submit html pages, it NEVER writes a new cookie, even if you change the data in the text fields, and even if you wait a minute or more between submittals (in other words, it appears the browser session MUST be closed before it will ever rewrite cookie [vs mine, which as expected writes new cookie every time, without fail, without delay]).
CASE Del Line Inactive. This results in correct behavior every time (if cookie already exists at runtime) because the cookie that gets phantom deleted upon submittal is actually the previous run's cookie as we saw in your earlier post: [1], [1], [2] or [2], [2], [1]
----
Symptoms seem to point to cookie being treated by browser/ie settings as session-only and probably page-only life span instead of using the actual expiry date, which is what my systems are doing. The wait period is probably the opposite of what it appears - post waiting time, the (incorrectly interpreted) session cookie deletion routine is slow on the draw, remains ready to destroy for about a minute, and is forced out of cache and back into semi retirement by OS) .
Until I can figure out why cookie is being degraded on your system (and possibly others), the work-around/safeguard method is to remove delete line, and even set.file a cookie at beginning of macro if one doesn't exist already to kickstart the [1] [2] alternating.