RE: Appended row not being displayed

["Erik Ohrnberger" <Erik echohome org>]

On Wed, July 12, 2006 12:31, Erik Ohrnberger wrote:
> On Wed, July 12, 2006 11:54, Erik Ohrnberger wrote:
>> On Wed, July 12, 2006 11:20, Erik Ohrnberger wrote:
>>> On Tue, July 11, 2006 13:15, Murray Cumming wrote:
>>> <snip>
>>>> Are you using a custom treemodel, or are you adding the rows
>>>> during some intensive processing that would stop the UI from
>>>> updating?
>>> <snip>
>>>
>>> I'm using a standard treemodel with application code populating the
>>> columns in the rows, and yes, this is during some pretty intensive
>>> processing.  Approx. 6 rows are being added each second, with a
>>> possible
>>> maximum of 100,000 rows in the treemodel that need to be displayed and
>>> scrolled by the user.
>>>
>>> The TreeView is rendering the content of a virtual memory mapped region
>>> that is serving as a circular log of events.  The events are what are
>>> being logged to this memory religion at approx. 6 rows per second.
>>> Each
>>> of these entries in the region is 176 bytes in length, but is
>>> represented
>>> as a row in the treeview that includes a unsigned long time stamp for
>>> sorting, an icon, a time stamp string, a 3-4 character address, and a
>>> 150
>>> byte message.
>>>
>>> It makes me wonder if I can relieve some of the contention by threading
>>> the GUI update part of the code.  Is this a good idea?  Would it have
>>> the
>>> desired effect of keeping the GUI updated in a more timely fashion?
>>>
>>
>> I thought I found what I was looking for in a suggestion that was
>> submitted to the list for what appears to be a similar problem
>> (http://marc.theaimsgroup.com/?l=gtkmm&m=112928461625469&w=2), however,
>> when I add the code:
>>
>> ////////////////////////////////////////////////////////////////////
>> // code that allows the UI to update
>> while(Gtk::Main::instance()->events_pending())
>> Gtk::Main::instance()->iteration();
>> ///////////////////////////////////////////////////////////////////
>>
>> The application seems to hang and not exit when the user closes the main
>> window.
>>
> Yea, I've tracked it down a bit more.  Seems that at some point, the
> execution enters Gtk::Main::instance()->iteration(); but does not return,
> reguardless if the blocking argument is set to false (to indicate
> non-blocking).  Hmmm.  That's strange.  Buton the plus side, this is
> exactly what I need to do.
>

Right.  Must be something inthe application that is generating an
unlimited number of events.  Why do I say this?  Well, I changed the code
to be this:

unsigned int		count = 0;
while( Gtk::Main::events_pending() )
{
	Gtk::Main::iteration( false );
	count++;
	cerr << "Count: " << count << endl;
}

and I saw the count display run all the way up to 16,7816 which seems way
out of whack!  Any ideas what could be running the events that high?