It’s the WM_NC class messages. For example, you can handle the WM_NCLBUTTONDBLCLK message.

And you can alse reponsible the  WM_SYSCOMMAND messages.  In particular, the special cases of SC_MINIMIZE and SC_MAXIMIZE are what are called from the system menu, which is what is available from the taskbar.

The simplest way to change the row height in a CListCtrl is:

Display an icon with the desired height.

All other ways that I know of require significant programming (such as owner draw, which is often too much work).

It’s a CListCtrl like control, but it binds a CTreeCtrl in the first column. But you can also consider it as a CTreeCtrl and each of the items has the list style.

All roads lead to Rome. But in 1999, David Lantsman has already given a solution on CodeProject and named it CTreeList: A TreeList Control.

You can Download demo project – 60 Kb and Download source files – 21 Kb from codeproject.

OK, you are on the wrong way now.

The CListView does not use or contain the MFC CListCtrl, it only wraps a subclassed SysListView32 control as a CCtrlView, in the other hand, the view is the control.

If all you’ve done in your custom CListCtrl derived class is to handle the reflected NM_CUSTOMDRAW message, your best bet to get this working as a custom CListView is to derive a class from CListView and handle the reflected message for it just as you do in your CListCtrl derived implementation.

If you want get  more custom control or you have already make an extended version of CList, It may be easier to derive a view class from CView and use your own CListCtrl in the view.

There are two articles about this topic on CodeGuru:

• http://www.codeguru.com/doc_view/custom_view.shtml
• http://www.codeguru.com/doc_view/Control2View.shtml

If you override OnCtlColor in your property page, then you can return a different background color and that seems to work with CStatic and other items.

But what if you want is a background that’s not just a simple color? You’d like to be able to draw a background (maybe an watermark-style image) as your property page background and not have CStatic and other controls draw their own background. you would have though the transparent option in the CStatic class would do this when set from the dialog editor, but it doesn’t seem to.

I’m trying to create a UI thread to do constant background work, but I’m having some design problems.

The thread needs to fetch records from a database. do some processing on each record and, when there are no more records, sleep for 1 minute before check the database again. The process will be controlled with thread messages (to start, pause, query…).

My problem is where should I put the processing work. I need it to be responsive between cycles, where the process waits for 1 minute, so I can stop it in that period. My only idea is using OnIdle to do the work.
But then, how should I make it real idle when waiting for 1 minute?

Could anyone give some hints on what is the way to go?

Scott McPhillips [VC++ MVP]

You can’t use Sleep and still be responsive to messages. Instead of using Sleep you could use SetTimer in the main thread and post a message to the thread, or SetTimer to a hidden window within the thread, or you could use a loop within the thread and use MsgWaitForMultipleObjects within the loop.

MsgWaitForMultipleObjects has a timeout parameter that gives you the sleep period, but it also returns early if a message or event comes along.

Almond and Joseph M. Newcomer [MVP]

I would be strongly disinclined to use MsgWaitForMultipleObjects. You don’t gain anything by using it over using WM_TIMER, and it requires that you have to write your own message pump, always a dangerous proposition.

BUT, SOME MORE DISCUSSION ABOUT THE UI THREAD AND WORKER THREAD…

Almond

Do not use UI threads for this kind of thing.

David

I would create a worker thread (not a UI thread) unless you need a UI thread for some specific purpose not apparent in this description. The worker thread would do it’s work and then do a WaitForSingleObject() with a timeout of 1 minute (60000 ms), which causes WaitForSingleObject() to return when either the main thread sets an event for starting, pausing, querying, etc. or the 1 minute has elapsed. If you need separate events each for starting, pausing, querying, etc. use WaitForMultipleObjects() instead of WaitForSingleObject().

Joseph M. Newcomer [MVP]

UI threads are actually ideal for this sort of thing. Don’t be confused by the phrase ‘UI’ meaning something with windows; think of it as “a thread with a built-in queuing mechanism”. They’re really very good for things that require timed events as the OP described.

There are some advantages to UI threads; for example, a UI thread has a built-in queue.
Also, for some kinds of interfacing require a message pump to deal with event handling. I don’t do databases so I don’t know if databases have this requirement, but there are On-Anything handlers involved in the database interface, then a UI thread is required.

I’m trying to create a UI thread to do constant background work, but I’m having some design problems.

The thread needs to fetch records from a database. do some processing on each record and, when there are no more records, sleep for 1 minute before check the database again. The process will be controlled with thread messages (to start, pause, query…).

My problem is where should I put the processing work. I need it to be
responsive between cycles, where the process waits for 1 minute, so I
can stop it in that period. My only idea is using OnIdle to do the work.
  But then, how should I make it real idle when waiting for 1 minute?

Could anyone give some hints on what is the way to go?

Scott McPhillips [VC++ MVP]

You can’t use Sleep and still be responsive to messages.  Instead of using Sleep you could use SetTimer in the main thread and post a message to the thread, or SetTimer to a hidden window within the thread, or you could use a loop within the thread and use MsgWaitForMultipleObjects within the loop.

MsgWaitForMultipleObjects has a timeout parameter that gives you the sleep period, but it also returns early if a message or event comes along.

Almond and Joseph M. Newcomer [MVP]

I would be strongly disinclined to use MsgWaitForMultipleObjects.  You don’t gain anything by using it over using WM_TIMER, and it requires that you have to write your own message pump, always a dangerous proposition.

BUT, SOME MORE DISCUSSION ABOUT THE UI THREAD AND WORKER THREAD…

Almond

Do not use UI threads for this kind of thing.

David

I would create a worker thread (not a UI thread) unless you need a UI thread for some specific purpose not apparent in this description.  The worker thread would do it’s work and then do a WaitForSingleObject() with a timeout of 1 minute (60000 ms), which causes WaitForSingleObject() to return when either the main thread sets an event for starting, pausing, querying, etc. or the 1 minute has elapsed.  If you need separate events each for starting, pausing, querying, etc. use WaitForMultipleObjects() instead of WaitForSingleObject().

Joseph M. Newcomer [MVP]

UI threads are actually ideal for this sort of thing.  Don’t be confused by the phrase ‘UI’ meaning something with windows; think of it as “a thread with a built-in queuing mechanism”.  They’re really very good for things that require timed events as the OP described.

There are some advantages to UI threads; for example, a UI thread has a built-in queue.
Also, for some kinds of interfacing require a message pump to deal with event handling.  I don’t do databases so I don’t know if databases have this requirement, but there are On-Anything handlers involved in the database interface, then a UI thread is required.