总出现错误提示：Debug Assertion Failed!
Program:E:\MP3INFOMODIFY\MP3INFOMODIFY.EXE
File:occmgr.cpp
Line:410
....其中，MP3INFOMODIFY.EXE是我的程序，使用VS.Net 2003在WinXP SP1环境下开发，虽然用的是VC.Net，但没有用托管，只用了MFC开发，此程序在未装.Net Framework的WinXP Sp1环境下运行正常，但在98/ME下运行不正常，甚至在2000下也有问题软件内嵌了Windows Media Player，是不是这个原因？我的Windows Media Player版本是9.0小弟急等！
Program:E:\MP3INFOMODIFY\MP3INFOMODIFY.EXE
File:occmgr.cpp
Line:410
....其中，MP3INFOMODIFY.EXE是我的程序，使用VS.Net 2003在WinXP SP1环境下开发，虽然用的是VC.Net，但没有用托管，只用了MFC开发，此程序在未装.Net Framework的WinXP Sp1环境下运行正常，但在98/ME下运行不正常，甚至在2000下也有问题软件内嵌了Windows Media Player，是不是这个原因？我的Windows Media Player版本是9.0小弟急等！
1。Mediaplyer控件在你使用的98下面没有2。你在程序中使用了某些API函数，而Win系列的操作系统，有些API函数是不能兼容的。即在2000下有，98下不一定有，XP下有，2000下不一定有。你最好检查一下。
2 你有可能调用了只有WIN2K + 上才能使用的ＡＰＩ
３你９８上没装最新的ＤＩＲＥＣＴＸ （试一下，有可能就好了９８是Ｄ６）
SYMPTOMS
When an MFC 4.0 control container has one or more invisible-at-run-time OLE controls along with other OLE and non-OLE controls placed on a dialog template, the following assertion might occur based on the tab-order of the controls in the dialog:
Debug Assertion Failed!
Program: <app name>
File: occmgr.cpp
Line: 388
CAUSE
When the MFC framework creates an invisible-at-run-time OLE control, it is reparented to the desktop window. This makes the control's window not a sibling of the other windows present in the dialog. Now if this invisible- at-run-time control has another OLE control (visible at run time) next in tab order, then the framework places the latter OLE control at the end of the dialog's child window list. Later when the framework attempts to find the "next" sibling window of the OLE control (now at the end of the dialog's child window list), it returns NULL because there is no "next" sibling window to this OLE control.
RESOLUTION
The assertion can be safely ignored, but the tab order will probably be incorrect. To work around this assertion, place the invisible-at-run-time controls at the end of the tab order in the dialog template.
STATUS
Microsoft has confirmed this to be a bug in the Microsoft products listed at the beginning of this article. This bug was corrected in Visual C++ 4.1.
MORE INFORMATION
The MFC framework creates OLE controls placed on a dialog template resource, if any, by calling COccManager::CreateDlgControls. This function in turn makes a call to COccManager::CreateDlgControl to create a specific OLE control. The code present in CreateDlgControl attempts to setup the tab order of each OLE control after it is created, for which it calls CWnd::SetWindowPos, passing in the handle of the window that the control will be inserted after (in the code, this window is referred to as pWndAfter). For a clear understanding of what would generate the above described ASSERT, consider the following reproducible scenario.
Steps to Reproduce the Assertion Failure
Create a dialog-based control container application, and place the following controls with the specified tab order in its main dialog template resource:
MS-COMM OLE Control (or any invisible-at-run-time control) : 1
GRID OLE control (or any control that is visible at run time) : 2
Static control (or any standard Windows control) : 3
GRID OLE control (or any control that is visible at run time) : 4
Because the MS-COMM OLE control is reparented to the desktop, the GRID control next to it in the tab order will be created and placed at the end of this dialog's child window list. Later when the framework creates the final GRID control, it tries to find the static control that should precede this GRID control in the Z order, by finding the next sibling window of the second GRID control. But because there is no next sibling window to the second GRID control, it returns NULL, which triggers the ASSERT.
SYMPTOMS
When an MFC 4.0 control container has one or more invisible-at-run-time OLE controls along with other OLE and non-OLE controls placed on a dialog template, the following assertion might occur based on the tab-order of the controls in the dialog:
Debug Assertion Failed!
Program: <app name>
File: occmgr.cpp
Line: 388
CAUSE
When the MFC framework creates an invisible-at-run-time OLE control, it is reparented to the desktop window. This makes the control's window not a sibling of the other windows present in the dialog. Now if this invisible- at-run-time control has another OLE control (visible at run time) next in tab order, then the framework places the latter OLE control at the end of the dialog's child window list. Later when the framework attempts to find the "next" sibling window of the OLE control (now at the end of the dialog's child window list), it returns NULL because there is no "next" sibling window to this OLE control.
RESOLUTION
The assertion can be safely ignored, but the tab order will probably be incorrect. To work around this assertion, place the invisible-at-run-time controls at the end of the tab order in the dialog template.
STATUS
Microsoft has confirmed this to be a bug in the Microsoft products listed at the beginning of this article. This bug was corrected in Visual C++ 4.1.
MORE INFORMATION
The MFC framework creates OLE controls placed on a dialog template resource, if any, by calling COccManager::CreateDlgControls. This function in turn makes a call to COccManager::CreateDlgControl to create a specific OLE control. The code present in CreateDlgControl attempts to setup the tab order of each OLE control after it is created, for which it calls CWnd::SetWindowPos, passing in the handle of the window that the control will be inserted after (in the code, this window is referred to as pWndAfter). For a clear understanding of what would generate the above described ASSERT, consider the following reproducible scenario.
Steps to Reproduce the Assertion Failure
Create a dialog-based control container application, and place the following controls with the specified tab order in its main dialog template resource:
MS-COMM OLE Control (or any invisible-at-run-time control) : 1
GRID OLE control (or any control that is visible at run time) : 2
Static control (or any standard Windows control) : 3
GRID OLE control (or any control that is visible at run time) : 4
Because the MS-COMM OLE control is reparented to the desktop, the GRID control next to it in the tab order will be created and placed at the end of this dialog's child window list. Later when the framework creates the final GRID control, it tries to find the static control that should precede this GRID control in the Z order, by finding the next sibling window of the second GRID control. But because there is no next sibling window to the second GRID control, it returns NULL, which triggers the ASSERT.
谢谢你的帖子，但我现在很郁闷的是自己现在根本都找不到98的环境让我操作，这都是用户的反馈信息
大家可以看看我的程序界面，看看究竟是那些控件出了问题！http://www.exue.org/html/80/Interface.jpg