Prev: MFC Feature Pack App with full frame docking
Next: New control styles with imported VC6 app in VS2008
From: Hector Santos on 1 May 2010 14:12
nexolite wrote:

> yes but the thing is I want to modify the contents of the loaded html page
> based on the data fetched from remote server (which can take time of it will
> be another thread that will be started from OnDocumentComplete).
>
> So is it ok to pass LPDISPATCH pDisp to thread so that it can use it ?


I don't know enough about this Web component COM interface.

But in principle, you can pass any pointer to a thread as long as it
is not destroyed after you start a thread. For example, the pDisp
pointer is no longer valid once you exit the message handler. If so,
you can only make it work if you make a copy of the pointer data you
want on the heap and the thread destroys it when it is finished using it.

You might be better off just using the yielding the the message pump
in your handler.

--
HLS
From: Goran on 1 May 2010 16:06
On May 1, 6:21 pm, nexolite <nexol...(a)discussions.microsoft.com>
wrote:
> yes but the thing is I want to modify the contents of the loaded html page
> based on the data fetched from remote server (which can take time of it will
> be another thread that will be started from OnDocumentComplete).
>
> So is it ok to pass LPDISPATCH pDisp to thread so that it can use it ?

Probably not. Try learning about COM threading rules. They say that
you have to "marshal" any interface pointer to another apartment. I
would guess that your object is in a single-threaded apartment, and
that your thread will be another single-threaded apartment, but multi-
threaded apratment will need properly marshalled interface pointer as
well.

As for a solution: use IGlobalInterfaceTable (you use CoCreateInstance
to create it) in your object's apartment. Do RegisterInterfaceInGlobal
with your IDispatch. Pass received cookie to another apartment. In
another apartment, create IGlobalInterfaceTable and use
GetInterfaceFromGlobal with the cookie to get your dispatch. Be aware
that any methods you invoke on said IDispatch will likwely be
marshalled to it's apartment.

Goran.
From: Joseph M. Newcomer on 1 May 2010 22:39
Generally, you can pass any pointer across thereads. However, there are some limitations
which are not always obvious.

For example, both threads have to share the same heap and use the same allocator for
new/malloc delete/free. This is the most common scenario, and therefore this requirement
is usually not mentioned or even noticed.

But if the thread is in a DLL that has static linking of the CRT, you are doomed.

Typically, what I would do is create a thread to fetch the data, and when the data is
received, use PostMessage to post a pointer to that data back to the main GUI thread; the
main GUI thread then uses the pointer in some reasonable fashion.

The long explanation about the message pump is important and you really need to understand
that.
joe

On Sat, 01 May 2010 14:12:02 -0400, Hector Santos <sant9442(a)nospam.gmail.com> wrote:

>nexolite wrote:
>
>> yes but the thing is I want to modify the contents of the loaded html page
>> based on the data fetched from remote server (which can take time of it will
>> be another thread that will be started from OnDocumentComplete).
>>
>> So is it ok to pass LPDISPATCH pDisp to thread so that it can use it ?
>
>
>I don't know enough about this Web component COM interface.
>
>But in principle, you can pass any pointer to a thread as long as it
>is not destroyed after you start a thread. For example, the pDisp
>pointer is no longer valid once you exit the message handler. If so,
>you can only make it work if you make a copy of the pointer data you
>want on the heap and the thread destroys it when it is finished using it.
>
>You might be better off just using the yielding the the message pump
>in your handler.
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Hector Santos on 2 May 2010 06:59
Joseph M. Newcomer wrote:


> Typically, what I would do is create a thread to fetch the data, and when the data is
> received, use PostMessage to post a pointer to that data back to the main GUI thread; the
> main GUI thread then uses the pointer in some reasonable fashion.


But does that not defeat the purpose of blocking the UI again - the original OP issue? I agree, grabbing a copy of a external thread data, but posting it back to the GUI isn't solving the issue.


> The long explanation about the message pump is important and you really need to understand
> that.


Joe, there are many time where a short explanation or reference that pertains the OP issue suffices. Its really not that hard to advise a solution that does not requires a course in MFC 101. It saves you time too. If there is any follow up questions, then you can provide with a course in MFC 101 message pumps.


--
HLS
From: Hector Santos on 2 May 2010 07:17
nexolite wrote:

> as mine is a BHO .. so can it be a problem if the previous tab is yet under
> processing and the user opens a new site in a tab ?
>
> Thanks


Thats an engineering design question, meaning, it will depend if you
want to do each thing separately or allow the new request completion
take over that last request completion.

The answer probably starts with knowing more about the end result you
are trying to archive. In short, there are various answers depending
on what you trying to do.

But again, in general, if your main issue is about the UI being
blocked, then as originally suggested either a thread is used or you
call the message pump in the computational loop. There is no other
way to solve that general UI blocking issue.

--
HLS
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: MFC Feature Pack App with full frame docking
Next: New control styles with imported VC6 app in VS2008