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.)
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
===================================
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
