----- Original Message -----
From: "J. Merrill" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, September 13, 2003 8:05 PM
Subject: Re: [ADVANCED-DOTNET] Object identities, marshaling issues and
interoperability


> At 02:11 PM 9/13/2003 +0400, Dmitry Shaporenkov wrote (in part)
> >----- Original Message -----
> >From: "J. Merrill" <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>
> >Sent: Friday, September 12, 2003 7:39 PM
> >Subject: Re: [ADVANCED-DOTNET] Object identities, marshaling issues and
> >interoperability
> >
> >> Wouldn't using the string parameter to externalObject.Item as the key
> >solve your problem?  [snip]
> >>
> >> Of course, you might have confused me by using "MyItem" as the .Item
> >parameter, when perhaps it's something that could change and thus can't
be
> >used as the HashTable key on the .NET side (ugh).
> >
> >   Yes, and I am sorry for being so unclear. I used "MyItem" as the .Item
> >parameter just for illustration. In reality, Items form a hierarchy, so
the
> >typical code to get an item looks like follows:
> >...
> >      Item item;
> >      Item subItem = item.GetSubItemByIndex (2);
> >...
> >
> >  My wrappers mimic the hierarchy by holding a reference to the
underlying
> >item and delegating calls to this reference:
> >....
> >   class ItemWrapper
> >   {
> >       Item myItem;
> >
> >       ItemWrapper GetSubItemByIndex (int index)
> >       {
> >          Item item = itemToWrapperTable [myItem.GetSubItemByIndex
(index)];
> >// (*) Item.GetSubItemByIndex returns different stubs for the same member
> >
> >// of the hierarchy on different threads
> >       }
> >   }
> >....
> >     ItemWrapper wrapper;
> >     ItemWrapper subItemWrapper = wrapper.GetSubItemByIndex (2);
> >....
> >
> >  In line (*) I get two different wrappers depending on what thread now
> >executes the code. It is OK, I do not really need ItemWrappers to be
unique.
> >However, I need
> >  a way to provide correct Equals () and GetHashCode () methods for
> >ItemWrapper class. "Correct" means that the methods should treat
different
> >ItemWrappers which
> >  represent the same member of the hierarchy as equal. Unfortunately,
Item
> >does not expose the unique identifier among its properties, so using some
> >kind of apartment-
> >  independent identifier of Item seems to be the only way to implement
both
> >methods.
> >[snip]
>
> Does the item hierarchy change while things are running?  If not, you
could perhaps create a unique key for each item using an "a.b.c" scheme
where a,b,c are the index positions at each level of the hierarchy.  (That
assumes you can get a reference to a (sub)item's parent, and the item's
sibling-relative position, from the item; and that you won't "see" a child
item unless you've already seen its parent.  It would be too bad if you had
to "walk up the tree" each time to get the full 'a.b.c' path but perhaps
that could be avoided.)

    Yes, the item hierarchy may change at run-time. Otherwise I could mirror
the entire hierarchy at start-up and avoid the
    problem of accessing COM objects at all. Perhaps I still can mirror it
at start-up and maintain the mirrored
    and the original hierarchies in sync using path in the hierarchy as an
item identifier, just as you propose.

>
> Let's look at it another way.  Why do you need to talk to the COM object
from a secondary thread?  Unless you have a multi-processor machine, things
won't be significantly faster than if you do "background" work within the
main thread (by handling the Application.Idle event when there's work to do,
and turning off the delegate that does the "process one item" task when
everything has been processed).
>
> Avoiding multiple threads sometimes makes life simpler.
>
> J. Merrill / Analytical Software Corp

    You are right, of course. However, besides performance there is a reason
for using multiple threads, and this
    reason is responsiveness of the application. When my application runs a
time-consuming operation,
    it would be nice for a user to see a progress indicator showing how far
the operation has gone. This assumes that the
    operation itself is performed in a separate thread, so that the UI
thread can process events from the user and the operating
    system.
>
> ===================================
> This list is hosted by DevelopMentorŪ  http://www.develop.com
> NEW! ASP.NET courses you may be interested in:
>
> 2 Days of ASP.NET, 29 Sept 2003, in Redmond
> http://www.develop.com/courses/2daspdotnet
>
> Guerrilla ASP.NET, 13 Oct 2003, in Boston
> http://www.develop.com/courses/gaspdotnet
>
> View archives and manage your subscription(s) at
http://discuss.develop.com

===================================
This list is hosted by DevelopMentorŪ  http://www.develop.com
NEW! ASP.NET courses you may be interested in:

2 Days of ASP.NET, 29 Sept 2003, in Redmond
http://www.develop.com/courses/2daspdotnet

Guerrilla ASP.NET, 13 Oct 2003, in Boston
http://www.develop.com/courses/gaspdotnet

View archives and manage your subscription(s) at http://discuss.develop.com

Reply via email to