Derrell,
As another possible solution, isn't there a method available to cancel
any pending requests in the queue, which Ken could use before submitting
each new request?
This would avoid the need for a timer and allow each selected line in
the table to cancel the request from the previously selected line,
providing a more immediate completion of the needed final request.
HTH,
Gene
On Mon, 2009-12-07 at 15:57 -0500, Ken MacDonald wrote:
>
>
> On Mon, Dec 7, 2009 at 3:40 PM, Derrell Lipman
> <[email protected]> wrote:
>
> On Mon, Dec 7, 2009 at 15:28, Ken MacDonald
> <[email protected]> wrote:
>
>
> I have a qx.ui.table.Table, single select, with 100's
> of entries. As I select a new entry, details of that
> entry are queried from our DB server, and displayed in
> two other panels on the page; one is another Table,
> and the other is a qx.ui.embed.html. That works well.
>
> However, if I go to the original table, and hit/hold
> the down-arrow through, say, 100 entries, the DB gets
> WAY behind, and the detail displays just "freeze",
> usually at about the location where I started down-
> arrowing. After a long wait with no apparent activity,
> the displays updates to the new entry 100 down.
>
> I would like to know if there is a way to display some
> type of progress indicator so users don't think the
> display has just died. I've tried updating the html
> panel (with "skipping entry # 582" etc.) and calling
> syncAppearance(), clearing the html panel, creating
> ANOTHER html panel, but action seems to be frozen no
> matter what I do - these things all work in Firebug,
> of course.
>
>
> So each of those rows that are being quickly passed by are
> generating a request to the server. The problem is determining
> how many of them can simply be discarded rather than passed to
> the server. You clearly need enough of them to actually occur
> to fill the final visible table rows. If there are no other
> side effects that you depend on, all of the intervening ones
> could be discarded.
>
> One way to solve this, that may point you towards some
> reasonable solution, is instead of issuing your remote request
> immediately upon selection of a row, add the request to a
> queue and start a timer with a short interval. Each time you
> get a new selection, add the request to the queue and reset
> the timer to so that short interval so that it doesn't fire at
> its original time, but instead some slightly later time. Your
> timer keeps getting suspended and suspended until finally the
> arrow key is released. You can now discard all but the most
> recent N requests, and issue each of them to your server. (In
> fact, there's some method call in Table that would cause a
> refresh. I don't recall at the moment what it is, but if you
> find that, and the queue is "long" enough by whatever
> definition of "long" you decide, you could just discard all of
> those queued requests and call the method that tells the table
> to refresh itself.
>
>
>
> I had considered using a timer before querying the DB, since the only
> request I really need to go to the server is the very last one, but I
> think this depends on a variety of things I may not be able to control
> - keyboard repeat rate, etc. I may yet get around to setting that up,
> but would still like a way to notify the user that something is
> happening. I did try changing the display panels and calling
> syncAppearance(), but it seems to have no effect - is that the
> 'refresh' method you mention? Qooxdoo really seems to be "letting the
> dust settle" before applying any of the updates I've set, which is
> pretty frustrating.
> Ken
>
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________ qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
