В идеале читатель обновил собственную программу C ++ до Visual Studio 2008, которая содержит блок OpenClipboard (). Почему бы не попробовать установить точку останова сразу после получения успешного кода возврата из OpenClipboard () и пройтись по своему коду. Согласно Интернету, он может работать на вашей системе, но, конечно, не на моей, спасибо за попытку.
поиск в Google, например, ((OpenClipboard 1418 vc6)) находит такие статьи, как «GetClipboardData терпит неудачу в отладчике» и «Нет ошибки в VC ++ 6, но ошибка в VC ++ 2005». На данный момент, прагматично, проблема решена - я просто не могу установить точки останова в таком коде, мне нужно сжимать информацию и устанавливать точку останова после выполнения операций с буфером обмена. Ошибка 1418: «Поток не имеет открытого буфера обмена», но он работает нормально, если вы не переходите с VS.NET, или, как я говорю, если вы сохраняете точки останова вне буфера обмена-open-close-block.
Я бы чувствовал себя лучше, зная, в чем именно проблема с отладчиком VS.NET.
Будучи человеком C ++, я лишь смутно осознаю, что вы не должны думать с точки зрения потоков при работе в dot-Net. Во всяком случае, я не нашел качественного объяснения того, что происходит на самом деле, в действительности ли проблема в том, что отладчик dot-Net каким-то образом слегка вмешивается в информацию о потоках, когда вы выполняете одношаговое выполнение кода C ++.
По системе: около года, два двухъядерных Xeon, 4 процессора в соответствии с XP-pro.
Я только что закончил отладку кода, пошагово пройдя его в vc6 под XP-SP2-32-bit. Так что я знаю, что код был довольно-таки хорошо под vc6. Однако, когда я тестировал CF_TEXT на 10 мегабайт, я получил исключения. Я подумал попробовать отладку под более приятной моделью исключения XP-x64.
Перекомпилированный с visual-studio-2008, я не смог сделать код одним шагом. OpenClipboard работал, но EnumClipboardFormats () не работал, ничего не работало, когда пошагово. Однако, когда я установил точку останова ниже полного блока кода, все работало нормально. И YES vc2008 сделал точную диагностику «повреждение кадра стека вокруг szBuf. В vc2008 есть что понравиться. Было бы неплохо, если бы это была просто проблема с буфером обмена - не зная, что я буду вынужден волноваться о переходе НИЧЕГО, могут ли проблемы с контекстом потока возникать из-за dot-Net-отладчика.