![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General Discussion » View Thread |
Messages 1 to 5 of 5 total |
![]() |
Thu, Mar 5 2015 10:44 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | I have decided for email subsystem of my main app to use a delayed display approach when someone is scrolling up or down the list of emails within any mailbox. Just using a TTimer and moving the email display code from a TEdit OnChange event to the timer triggering. My question is if anyone out there is using something similar what interval do you set the timer for?
Roy Lambert |
Thu, Mar 5 2015 10:56 AM | Permanent Link |
Matthew Jones | Roy Lambert wrote:
> I have decided for email subsystem of my main app to use a delayed > display approach when someone is scrolling up or down the list of > emails within any mailbox. Just using a TTimer and moving the email > display code from a TEdit OnChange event to the timer triggering. My > question is if anyone out there is using something similar what > interval do you set the timer for? Hmm, I've done similar things, but I tend to use a timer that checks an update time value. Thus in the OnChange I set it to FUpdateTime := IncMilliSeconds(Now, 300); and in the OnTimer I have if (FUpdateTime <> 0.0) and (Now > FUpdateTime) then begin FUpdateTime := 0.0; // update This way the timer will not trigger while the rapid updates are happening. Which is pretty much what you said you are doing, but not answered your question, which is how fast. And my answer to that is "it depends". 8-) Fundamentally you want to tweak it, and an INI setting override may help. You want it to feel "not slow" but also not "a problem waiting". You move along, pause, there it is. But if you pause for a quick read and then it slows you down, it is too quick. But I don't think there is any magic value that works for all situations as it depends on the "cost" of the action that then happens. For one purpose like this, I have about 800ms pause because the cost of the change is high, and I want people to be sure they are done before I do the update. Not helped a lot really have I? 8-) -- Matthew Jones |
Fri, Mar 6 2015 2:58 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | Matthew
To answer <<Not helped a lot really have I?-)>> first - a bit. I was finding that I had to wind it up to 1000 before I caught it all so you saying you have one up to 800 makes me feel a little easier. Roy Lambert "Matthew Jones" <matthew@mattNOSP-AMhew-jones.com> wrote on Thu, 5 Mar 2015 10:56:00 -0500 >Hmm, I've done similar things, but I tend to use a timer that checks an >update time value. Thus in the OnChange I set it to > >FUpdateTime := IncMilliSeconds(Now, 300); > >and in the OnTimer I have > >if (FUpdateTime <> 0.0) and (Now > FUpdateTime) then >begin > FUpdateTime := 0.0; > // update > >This way the timer will not trigger while the rapid updates are >happening. That took me a bit of time to get my head round. I assume that your timer is just left enabled with an interval <300ms? Roy Lambert |
Fri, Apr 10 2015 9:12 PM | Permanent Link |
Peter Evans | On 6/03/2015 1:56 AM, Matthew Jones wrote:
> Hmm, I've done similar things, but I tend to use a timer that checks an > update time value. Thus in the OnChange I set it to > > > Not helped a lot really have I? 8-) > Thank you for sharing that technique. I have, in the last few days, used that technique in a different area - that of DataSnap. I could not get the event in my timer to fire. However, by enabling the timer from program start it runs and fires. I then use similar code to yours with the variable FUpdateTime to actually run the code I really want to run! Prior to seeing your technique I had looked at StackOverflow and saw that many other people have had problems with the TTimer. The solutions there are many, varied and complex. Regards, Peter Evans |
Mon, Apr 13 2015 3:56 AM | Permanent Link |
Matthew Jones | Peter Evans wrote:
> Prior to seeing your technique I had looked at StackOverflow and saw > that many other people have had problems with the TTimer. The > solutions there are many, varied and complex. Timers are more complex than they appear, and depend on a window to be processed, but they aren't normal messages. Someone should do a blog post on them - old fogeys like me know the details because we had to back in the days when we were chiseling our interfaces from stone. -- Matthew Jones |
This web page was last updated on Wednesday, August 14, 2024 at 03:12 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |