Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 5 of 5 total
Thread How long should I wait
Thu, Mar 5 2015 10:44 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

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 AMPermanent 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 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

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 PMPermanent 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 AMPermanent 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
Image