If that is the case it might be worth checking the timeout settings in the flash remoting configs... if I remember correctly there is a separate one in there.
On Wed, Jul 14, 2010 at 1:24 PM, Charlie Arehart <[email protected]>wrote: > Well, to be clear, Craig was referring to a (quite old) Flash Form based > feature. I don’t know if it would be fair to throw all CF “widgets” under > the bus. There have been some nicer ones since the Ajax features were added > in CF 8. Still, I realize that some may still have issues with them. > > As for Troy’s comment, I don’t think he was suggesting that the page > timeout would have any connection to this, just that he thought it was > specified in ms. (It’s not, that’s in seconds, too.) And FWIW, I would > assert that there’s not likely any connection at all between the page > timeout and this CFFORM timeout. The page timeout has to do with how long a > request can run (while it’s executing). This CFFORM timeout seems instead to > be more like a mini version of a session, in that it lives on the server > across requests. > > > > /charlie > > > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Steve Ross > *Sent:* Wednesday, July 14, 2010 1:14 PM > *To:* [email protected] > *Subject:* Re: [ACFUG Discuss] Preserving data on flash forms using the > timeout attribute > > > > Not to be a jerk or anything but this is EXACTLY why I don't use any of the > built in "CF_" widgets... > > > > Not trying to troll here but, since the discussion happened a few months > back I'd thought I'd just throw that out there. Stuff like this seems to > happen a lot and fixing it takes longer than rebuilding... > > > > I think Troy is probably on the right track, check the page timeout. > > > > > > > > On Wed, Jul 14, 2010 at 1:02 PM, Troy Jones <[email protected]> wrote: > > I was thinking particularly of the timeout value of cfthread and the > requestTimeout value of cfsetting. I could also be wrong, like I said, it > was just a thought and a place to look. > > Troy Jones > > > > ___________________________________________________________________________________________ > > Troy Jones | Director of Technical Services | Dynapp Inc | > 1-800-830-5192 ext. 603 | dynapp.com | facebook.com/dynapp > > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > [email protected] > Sent: Wednesday, July 14, 2010 1:00 PM > To: [email protected] > > Cc: [email protected]; [email protected] > Subject: RE: [ACFUG Discuss] Preserving data on flash forms using the > timeout attribute > > Yes - I have confirmed that the timeout value, according to doc, is in > seconds.........unless that's a misprint in the doc..... > > > Craig Nassal > > Federal Reserve Bank of Atlanta > 1000 Peachtree St. N.E. > Atlanta, Ga 30309-4470 > (404)498-8437 > [email protected] > > > > From: "Charlie Arehart" <[email protected]> > To: <[email protected]> > Date: 07/14/10 12:16 PM > Subject: RE: [ACFUG Discuss] Preserving data on flash forms using > the timeout attribute > Sent by: [email protected] > > > > I don't know: most timeout attributes I think of in CFML (CFQUERY, CFHTTP, > CFSETTING > RequestTimeout) are in seconds. > > Anyway, to be clear, the timeout in CFFORM is indeed in seconds: > http://www.cfquickdocs.com/cf9/#cfform > > /charlie > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf Of Troy Jones > > Sent: Wednesday, July 14, 2010 12:06 PM > > To: [email protected] > > Subject: RE: [ACFUG Discuss] Preserving data on flash forms using the > timeout > > attribute > > > > I see that your value is 'timeout="300"'. In most other cases where a > timeout > > value is used, the numeric value is in milliseconds. If this is also > true for > > your value here, the value is actually only .3 seconds, in which case, > the > > timeout value has most likely passed by the time the action has taken > place. > > > > Just a thought. > > > > Troy Jones > > > > > > > > > ------------------------------------------------------------- > To unsubscribe from this list, manage your profile @ > http://www.acfug.org?fa=login.edituserform > > For more info, see http://www.acfug.org/mailinglists > Archive @ http://www.mail-archive.com/discussion%40acfug.org/ > List hosted by http://www.fusionlink.com > ------------------------------------------------------------- > > > > > > > > > ------------------------------------------------------------- > To unsubscribe from this list, manage your profile @ > http://www.acfug.org?fa=login.edituserform > > For more info, see http://www.acfug.org/mailinglists > Archive @ http://www.mail-archive.com/discussion%40acfug.org/ > List hosted by http://www.fusionlink.com > ------------------------------------------------------------- > > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.830 / Virus Database: 271.1.1/3004 - Release Date: 07/14/10 > 02:36:00 > > > > ------------------------------------------------------------- > To unsubscribe from this list, manage your profile @ > > http://www.acfug.org?falogin.edituserform > > > For more info, see http://www.acfug.org/mailinglists > Archive @ http://www.mail-archive.com/discussion%40acfug.org/ > List hosted by http://www.fusionlink.com > ------------------------------------------------------------- > > > > > > -- > Steve Ross > web application & interface developer > http://blog.stevensross.com > [mobile] (912) 344-8113 > [ AIM / Yahoo! : zeriumsteven ] [googleTalk : nowhiding ] > > ------------------------------------------------------------- > To unsubscribe from this list, manage your profile @ > http://www.acfug.org?fa=login.edituserform > > For more info, see http://www.acfug.org/mailinglists > Archive @ http://www.mail-archive.com/discussion%40acfug.org/ > List hosted by FusionLink <http://www.fusionlink.com> > ------------------------------------------------------------- -- Steve Ross web application & interface developer http://blog.stevensross.com [mobile] (912) 344-8113 [ AIM / Yahoo! : zeriumsteven ] [googleTalk : nowhiding ]
