Many thanks for your response, Aviad. Your suggestion turns out to be half the solution. In addition to decorating the base class as you suggest, you must follow that with decorating any derived classes with: [ToolboxItemAttribute(typeof(ActivityToolboxItem))] If you don't do this, the derived classes inherit the [ToolboxItem(false)] from the base class. (I can't take credit for this; the whole solution was suggested to me in another forum.)

I have a set of WF custom activities that inherit core behaviors from from a base activity class. So the hierarchy is: SomeCustomActivity : MyActivityBase : Activity I would like SomeCustomActivity to appear in the VS 2008 WF toolbox (it does) but NOT MyActivityBase (it does, no matter what I try). Seems like this should be doable fairly easily, after all Activity itself never appears in the toolbox. AJ

DOH! Thanks much. I shall fume for a while over why MSDN has such retarded search capabilities that it couldn't produce this from looking for "processid" or "process identifier" or "GetWindow", but I'll get over it. It is in the Index if I'd looked there. P.S. Alfonso might just as well have been referring to Mr. Gates.

If I've understood your intent, I think you want to have the edit box filled with the item text from the node you double clicked. The HTREEITEM returned by GetRootItem is instead going to point to the root of the entire tree control. Try using GetSelectedItem.

I'm wondering if anyone knows of a reasonable way to jump from an Application Hwnd to an associated processID or vice cersa. I've found much information on enumerating either running applications (EnumWindows) or active processes (PSAPI EnumProcesses, for instance), but I can't see any way to get from a processID I'm interested in to its main window handle or from an application Hwnd to its processID (and from there to its loaded modules). Hopefully I've missed aomething obvious. Suggestions appreciated. AJ

I wouldn't think 4K would be bad either. It is a single new, which allocates varying amount depending on amount of data attached to a print request. I can't say that I've got enough instances yet to prove 4K is a hard limit. And I've never seen a new fail this way either. Is the heap screwed? May very well be, but not on our systems running with the same program levels and even print data. Help in figuring out why it's screwed is part of why I turned here. I'll see what I can do with your suggestion. Thanks AJ

Yes it is, but I'm drawing a blank on what virtual memory setting would function as an upper limit on a heap allocation request. (And also why the new would fail so catastrophically) AJ

I'm facing a situation where it appears from tracing in my application that an attempt to allocate memory via C++ new is failing, natually only at the customer, and there only if the allocation is large. Every failure instance I've seen involves sizes just beyond 4K (say 4100 - 4400 bytes). Otherwise no problem. Really scratching my head looking for a good next step in either diagnosis or adjustment / repair. AJ

Silly me, searching on just WM_CTLCOLOR. :-O I see COLORSTATIC is restricted to a thread, but I can work around that. Many thanks, John. Between you and kuphryn I feel the Force may be with me again.

Yes. That was one avenue that led to a feeling of stupidity. Put a handler in the Find Dialog and SendMesssage to its window. I have yet to find a description of the proper setup of WM_CTLCOLOR wparam, lparam. Do you know a good source for such info? Thanks. Alex.

I have a customized Find Dialog (based on CFindReplaceDialog) to which I've added amongst other things a static text box for displaying results of the search in the CListCntl to which the dialog is attached. No problem. Then I thought it would be nice visually to say display "Find failed" in red, success in green. For something that seems like it should be dirt simple, I've plowed through more MSDN doc and CodeProject seemingly related items than I can believe. I must be missing something. Recommendations? Thanks.