Note that the assertion is getting thrown because ::IsWindow() is failing in the CProgressControl::SetPos(..) member. This tells you for sure that the progress control has certainly not been created the first time this function has been called. Try the following: Replace: m_progress.SetPos(speed); With: if (::IsWindow(m_progress.GetSafeHwnd())) { m_progress.SetPos(speed); } Replace: m_slider.SetPos(speed); With: if (::IsWindow(m_slider.GetSafeHwnd())) { m_slider.SetPos(speed); } With these modifications, you should not have to alter you architecture too much, and it should work as soon as the controls are created. The code is being called before within the context of the dynamic data exchange function (i.e. your dialog's DoDataExchange(CDataExchange* pDX)). The first time this function is called, the controls have not yet been created, so the modifications I have suggested to not hurt you. Once the controls have been created and you can intereact with them, then the ::IsWindow() function will succeed for each and you should get the desired effect. Ronald L. Russell Jr. (Ron) rrussell@ygrest.com

Which line of code in OnChangeSpeed(..) is causing the assertion? When you get the assertion, the message in the Abort/Retry/Ignore message box should tell you where the assertion is coming from. You can then track it back through the call stack. Without knowing more about where the message is coming from and when you are receiving it, I would assume that it is coming off the initial dynamic data exchange operation when your dialog is being created. If this is the case, then you can try one (or both ) of: Replace: m_speed.GetWindowText(SomeValue2) With: if (::IsWindow(m_speed.GetSafeHwnd())) { m_speed.GetWindowText(SomeValue2) } Replace: m_speed2.SetWindowText((LPCTSTR)SomeValue2) With: if (::IsWindow(m_speed2.GetSafeHwnd())) { m_speed2.SetWindowText((LPCTSTR)SomeValue2) } If this fixes your problem, then you will no that your routine is getting called before your control windows are actually getting created. Ronald L. Russell Jr. (Ron) rrussell@ygrest.com

Thank you for your response, but I am sorry I was not clearly describing what I am trying to do in my last post. I am looking for a way, on Windows NT, to hide an application's icon from the ALT+TAB list. If anyone knows how this can be accomplished, I would appreciate the information. Ronald L. Russell Jr. (Ron) rrussell@ygrest.com

I have seen several articles on various sites about how to prevent an application from showing on the taskbar. Can anyone point me at some information on how to hide an application from the tasklist as well?

I am in the process of developing a custom desktop for Windows NT. In my implementation of this custom desktop, there is a window along the bottom of the screen that emulates the behavior of the Windows NT Taskbar. This taskbar implementation sets a WH_SHELL hook and a WH_CALLWNDPROC hook to receive notifications concerning window creation, title changes, etc. During the early portions of development, this custom shell was always ran on top of Explorer.exe. Eventually the custom shell was moved to a test system whose policy file (ntconfig.pol) directs windows to run the custom shell at boot time rather than Explorer.exe. I have noticed that when this is the case, I no longer receive callbacks from the WH_SHELL hook procedure, although I still receive callbacks from the WH_CALLWNDPROC hook procedure. I can launch Explorer.exe from the custom shell and I begin to receive callbacks from the WH_SHELL hook. I can even end the Explorer.exe task from the taskmanager, and I still receive shell hooks. It seems that Explorer.exe must at least run once before I receive any callback from the WH_SHELL hook. I have discovered no information anywhere on MSDN that indicates that this is the case. Does anyone have any information as to why an application would not receive WH_SHELL hook procedure callbacks unless Explorer.exe has been started at least once on a system?

From what I can tell, the project's .NCB file becomes corrupt. Closing the project and deleting the .NCB and then reopening the project (which rebuilds the .NCB) usually will bring back the auto-complete feature. I have read other postings that indicate that the .NCB and .CLW both need to be deleted, but I personaaly have never run into a case where I had to delete the .CLW to get auto-complete bac