Re: Keep UI working without COM object being started

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Hi David,
Nice to hear from you! :)

Based on my experience, I suggest you'll be ready for the re-entrancy. All
the hacks will make the problem worse.
Another solution is to not reference this special COM object from the UI
thread. UI must be re-entrant safe: it is the nature of UI. (And there
are many message loops in the system that you do not have control of.) And
then spin up a worker thread to talk to this COM object.

I hope the above information is helpful for you. If you have any questions,
please feel free to let me know. Thanks and have a nice day!

Best Regards,

Terry Fei [MSFT]
Microsoft Community Support
Get Secure! www.microsoft.com/security

--------------------
>From: "David F." <df2705@xxxxxxxxxxxxxxxx>
>References: <eQF$6A#GGHA.648@xxxxxxxxxxxxxxxxxxxx>
<ew3MgoFHGHA.3728@xxxxxxxxxxxxxxxxxxxx>
>Subject: Re: Keep UI working without COM object being started
>Date: Wed, 18 Jan 2006 15:14:45 -0800
>Lines: 87
>X-Priority: 3
>X-MSMail-Priority: Normal
>X-Newsreader: Microsoft Outlook Express 6.00.2900.2527
>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
>X-RFC2646: Format=Flowed; Response
>Message-ID: <#hkd5TIHGHA.1192@xxxxxxxxxxxxxxxxxxxx>
>Newsgroups: microsoft.public.win32.programmer.ole
>NNTP-Posting-Host: ip68-108-44-76.lv.lv.cox.net 68.108.44.76
>Path: TK2MSFTNGXA02.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP11.phx.gbl
>Xref: TK2MSFTNGXA02.phx.gbl microsoft.public.win32.programmer.ole:12267
>X-Tomcat-NG: microsoft.public.win32.programmer.ole
>
>
>"Alexander Nickolov" <agnickolov@xxxxxxxx> wrote in message
>news:ew3MgoFHGHA.3728@xxxxxxxxxxxxxxxxxxxxxxx
>> Use PeekMessage with PM_REMOVE instead of GetMessage
>> for your message loop. You may need to call it several times
>> in the loop for different message ranges. Some ranges you need:
>> keyboard messages (WM_[SYS]KEY[DOWN|UP], WM_[SYS]CHAR),
>> mouse messages (WM_[L|R]BUTTON[DOWN|UP], WM_MOUSEMOVE,
>> etc), menu handling (WM_COMMAND), painting and hit testing
>> (WM_[NC]PAINT, WM_[NC]HITTEST), and there may be others
>> I've missed.
>>
>
>Actually, I am using peekmessage but for all messages in a loop and had
>thought of a filter but stupidly didn't think about having multiple
>peekmessage loops (or array of filters to process). The right messages to
>handle is the key - is there a "cheat ***" you know of that lays out all
>the UI messages in detail?
>
>> Personally, I'd recommend you to redesign the object to be
>> reentrant...
>>
>
>Yes, I agree, but that's a down the road project as there is way too much
on
>my plate right now (I'm getting too old for these 20+ hour days - and I'm
>only in my mid 30's <LOL>).
>
>> --
>> =====================================
>> Alexander Nickolov
>> Microsoft MVP [VC], MCSD
>> email: agnickolov@xxxxxxxx
>> MVP VC FAQ: http://www.mvps.org/vcfaq
>> =====================================
>>
>> "David F." <df2705@xxxxxxxxxxxxxxxx> wrote in message
>> news:eQF$6A%23GGHA.648@xxxxxxxxxxxxxxxxxxxxxxx
>>> Hello,
>>>
>>> I have an application that allows copy/paste and drag/drop that has an
>>> "object" that must not be reentrant. That "object" is used either by
the
>>> UI or the IStream (both in a STA) and is controlled via a semaphore
with
>>> a MsgWaitForMultipleObjects that will start a message pump (that
ignores
>>> all keyboard and client area mouse activity WM_MOUSEFIRST->WM_MOUSELAST
>>> and uses IDC_WAIT). The "object" is not kept allocated/locked across
a
>>> the normal message loop so everything works fine (if UI has control
then
>>> IStream doesn't and the UI will free it before the message loop and; if
>>> IStream has it, the UI waits and pumps the messages allowing the
IStream
>>> to complete and the UI does its thing).
>>>
>>> Now the caveat, using that "object" can take a long time. I'd like the
>>> window to paint itself and allow the user to be able to cancel via the
>>> menus. Within the "object" it calls a test-for-cancel routine which
>>> needs to process messages (to keep the menus working/screen painting so
>>> cancel can be chosen). The test-for-cancel routine calls the same
>>> message pump. The problem is that a new request from the IStream may be
>>> ready and dispatching a message causes it to attempt allocating the
>>> "object" causing a deadlock. I tried using a SendMessage instead of
>>> Dispatch but it still seemed to start the IStream. (Also, I wondered
if
>>> throwing away all messages except ones dealing with the non-client area
>>> of a window would work or would the request to process the IStream be
>>> lost as well?)
>>>
>>> Anyway, the main questions are:
>>>
>>> Is there a way to dispatch/process messages for the main window without
>>> allowing some other object in the STA from gaining control (ignored
until
>>> the main message loop)?
>>>
>>> Is there a way to use Drag/Drop and Copy/Paste via an MTA in that the
UI
>>> and IStream are separate?
>>>
>>> Is there a way to implement Drag/Drop and Copy/Paste in a thread
separate
>>> from the main UI thread?
>>>
>>> I guess I could also just pop up a little cancel dialog in a separate
>>> thread and have the Message Pump just process paint messages but I
really
>>> don't want to.
>>>
>>> TIA!!!!
>>>
>>>
>>>
>>
>>
>
>
>

.

Quantcast