RE: [litwindow-users] Re: m_current as a pointer

[yrs90 <yr...@ya...>]

To answer this email I'm returning to the pointer implementation I tried.
Maybe it will turn out to be a better solution.

Currently, though, I'm trying to figure out why, when using m_current as
originally designed, I can follow a particular click-sequence and watch what
starts out as an iterator pointing to correct contents translate into
corrupted data during the assignment to m_current.  Not only that but
m_current's original contents coming into the assignment look suspect too.

Actually, my investigation is hampered because I can't find the data or a
data pointer in the accessor data structure.  Could you tell me where to
find the data that the accessor is pointing to?  I can find it in the
iterator but lose it once it is dereferenced and becomes an accessor. To
find the data in the iterator 'i' I can look in
i.it.container_iterator.i._Tree._Ptr._Myval

So on (or back?) to m_current as a pointer.  I probably should have renamed
the variable to avoid confusion...

> Can you post the relevant code? m_current declaration, and where you 
> call NotifyChanged and other relevant places.

Let's see.  This is a little hard to boil down. I presume (perhaps wrongly)
that you prefer the narrative explanation over a diff.

lwListAdapterBase header was changed so
     mutable accessor    m_current;
became
     mutable accessor    *m_current;
     mutable accessor     m_empty;

m_current was initialized to &m_empty in lwListAdapterBase constructor.
m_empty.destroy() is called in the lwListAdapterBase destructor.

The biggest changes were to CalcCurrent where empty is assigned an empty
object if not !is_valid and m_current either points to the the_item or
m_empty accessor depending on whether the container index indicated an item
was selected.

void lwListAdapterBase::CalcCurrent(int containerIndex) const {
    if (m_items.is_valid() && m_items.is_container()) {
        // the const_accessor points to the end item which is invalid
        // but the type of the item is valid.
        container c=m_items.get_container();
        container::iterator i=containerIndex>=0 ?
m_items.get_container().at(containerIndex) : m_items.get_container().end();
        accessor the_item=*i;
        prop_t type=the_item.get_type();
        if (!m_empty.is_valid())
            m_empty=create_object(type);
        if (i!=c.end())
            m_current = &the_item;
        else {
            m_current = &m_empty;
        }
        g_rapidUI->ValueChanged(*m_current, true);
    }
}


Commands to destroy m_current were removed.  All ValueChanged() calls in
wxListObject were changed to reference *m_current rather than m_current.

> BTW, I don't know if you have stumbled across create, clone and 
> destroy yet as they are still undocumented. Together with a couple of 
> other methods they implement an object factory, giving you the ability 
> to create and clone objects dynamically by type, similar to the 
> wxWidgets runtime type system.
>
> Comes in useful when you want to write a generic insert method for 
> your control.
>
> Have a look at objectfactorytests.cpp for more information.

I'll take a closer look.  Thanks.

Best regards,
Joel



---
[This E-mail scanned for viruses by Declude Virus]