Почему я не могу выполнить одношаговый буфер обмена в отладчике VS.NET?

В идеале читатель обновил родную программу C++ до Visual Studio 2008, которая содержит блок OpenClipboard (). Почему бы не попробовать установить точку останова сразу после получения успешного кода возврата от OpenClipboard () и выполнить свой код. Согласно Интернету, он может работать в вашей системе, но, конечно, не в моей, спасибо за попытку.

Поиск в Google, например, ((OpenClipboard 1418 vc6)) находит такие статьи, как «GetClipboardData не работает в отладчике» и «Нет ошибок в VC++ 6, но есть ошибки в VC++ 2005». На данный момент проблема решена прагматично - я просто не могу устанавливать точки останова в таком коде, мне нужно получить информацию и установить точку останова после выполнения операций с буфером обмена. Ошибка 1418: «У потока не открыт буфер обмена», но она работает нормально, пока вы не используете VS.NET, или, как я уже сказал, если вы сохраняете точки останова вне блока clipboard-open-close-block.

Мне было бы лучше знать, в чем именно заключается проблема отладчика VS.NET.

Как человек C++, я лишь смутно осознаю, что вы не должны думать в терминах потоков при работе с dot-Net. Во всяком случае, я не нашел качественного объяснения того, что на самом деле происходит, действительно ли проблема в том, что отладчик dot-Net каким-то образом неуловимо вмешивается в информацию о потоке, когда вы выполняете пошаговую работу через собственный код C++.

Системно: около года, два двухъядерных процессора Xeon, 4 процессора по данным XP-pro. Я только что закончил отладку кода, пошагово пропустив его в vc6 под XP-SP2-32-bit. Итак, я знаю, что с vc6 код был довольно хорош. Однако, когда я тестировал 10-мегабайтный CF_TEXT, у меня были исключения. Я подумал попробовать отладку в более красивой модели исключений XP-x64.

Перекомпилированный с помощью visual-studio-2008, я вообще не смог сделать код пошаговым. OpenClipboard работал, но EnumClipboardFormats () не работал, ничего не работало в пошаговом режиме. Однако, когда я установил точку останова ниже полного блока кода, все работало нормально. И ДА vc2008 сделал точную диагностику повреждения кадра стека вокруг szBuf. В vc2008 есть что любить. Было бы неплохо, если бы это была просто проблема с буфером обмена - не зная, что я буду чувствовать себя вынужденным беспокоиться о переходе через НИЧЕГО, могут ли проблемы с контекстом потока быть из-за dot-Net-debugger.