ActiveX and OnIdle

Since the control 'probably' doesn't contain it's own message loop (it's controlled by the container), I would have to doubt that you can use the OnIdle.  Have you checked up on OnKickIdle? It typically works for modal CDialogs.

Also consider adding a method to receive the OnIdle from the container?

Third, a timer will work in your ActiveX.

I dunno, just wanted to respond to a lady on the net.

Phillip

Why don't you create a worker thread?
(See AfxBeginThread)

Philip is right, I guess. OnIdle will not be called inside your
ActiveX control. One work around would be to modify the container
app to trap OnIdle message and relay it to the Ax ctrl thru
a method. But if u can't modify the container App, well it
appears it wouldn't be possible to do Idle processing inside
your ActiveX control.

I've done something very close to this before, but unfortunately I can't remember how. I do remember spending weeks on the solution, and I probably came up with something inferior...

First, if OnIdle doesn't work, PeekMessage won't either. Either the control has its own message pump (in which case it'll call OnIdle), it's tied to the container's message pump (in which case neither solution will work), or for some reason it's not getting messages at all (in which case you have bigger problems). Look at the way CWinThread::Run works--it does the PeekMessage for you, and throws out OnIdle calls for you...

Also, you didn't mention whether the "CMyApp" you're referring to is your control's CWinApp derivative, or the container's. If you can trap the container's OnIdle and have it call a method on the control, your problem's solved, but I suspect you're trying to build a general control that doesn't depend on such support from the container, and you're trying to override the control's OnIdle.

If I'm right, I'm pretty sure that the control's CWinApp derivative pretty much does nothing, and you can't count on it to, e.g., handle OnIdle for you.

You might be able to count on MFC-built containers passing WM_IDLEUPDATECMDUI messages to you, but that obviously won't work with containers that aren't either built with MFC or extraordinarily friendly. And even if it does, I'm pretty sure you'll only get the message if you're active (that is, in-place active and have an HWND, or windowless in-place active).

Which reminds me: If you're in-place active and have an HWND, you have your own messages. If you're windowless in-place active, you get your messages from your container. Maybe either changing your control to explicitly not be windowless and to request activation on creation will solve your problem (assuming you don't need to receive idle messages until activated, or while inactive).

Sorry I couldn't help more...

Thanks to everyone for their interest in this question. Here are some details for you...

I have created a control that is to be used as an editor for C and Assembler code. It's a simple CRichEdit Doc/View that the container application creates an instance of "on demand". The control needs to provide the standard bells and whistles including color coding of comments and key words. I parse the 1st 48K before the text is displayed without a noticable delay. If the file is larger than 48K, parsing must continue, however, the user can't wait while a 1MB file is made pretty.

I could tie a timer and scroll events to parsing the remainder of the file. But, isn't this a good candidate for a background task? The worker thread sounds like a possible solution unfortunately I cant pass C++ objects. Although it appears there are workarounds for that too..

Thanks again for any guidance.
-Lisa

I would definitely look at worker threads.  Have your worker thread busy loading up the code and your UI interface processing the data.

Thanks to all, esp. snoegler for the most informative one liner.

Off I go to the land of worker threads.

Lisa