Форматирование — топовая беда данного блога.
http://superhabr.ru/ — ждем =)
Странные вы... Бу!
Какой-то ужас в
MakeLink()
- магические числа, дикая смесь
Encoding
и
StringBuffer
- если считаете байты, то и выводие результат в байтах, а не в абстрактной строке, привязанной к определенной кодировке, непереносимые переводы строк - правильнее
Environment.NewLine
...
Сори, минус вместо плюса нажал)
На самом деле MakeLink() не должно быть отдельной функцией вообще, т.к. больше нигде не нужна в принципе.
Но хотелось для наглядности все-таки разделить формирование буфера и запихивание его в буфер.
А касательно Environment.NewLine — мне кажется, как-то неуместно рассуждать о том, что правильнее, когда в описании четко сказано:
End of lines in the clipboard format header could be CR or CR/LF or LF.
Это, скорее, из разряда "читабельности". У меня в VS2008 не видны переносы в Watch, потому как переносы не те.
Если вы пишите на .NET - старайтесь избегать импорта DLL функций и обходиться внутренними.
Я считаю, что в данном случае импорт функций лишний и некрасивый.
Вот интересная статья по этой теме
Насчет кодировки - если погуглите - найдете ответ.
Угу. Вот что по этому вопросу пишет любезный Джеффри Рихтер:

"Microsoft .NET Framework позволяет разработчикам в гораздо большей степени задействовать готовые технологии, чем предыдущие платформы разработки от Microsoft. В частности, .NET Framework предоставляет реальные возможности повторного использования кода, управления ресурсами, многоязыковой разработки, защиты, развертывания и администрирования. При проектировании этой новой платформы Microsoft учла недостатки существующих Windows-платформ. Вот далеко не полный список преимуществ CLR и FCL.

• Единая программная модель В отличие от существующего подхода, когда одни функции ОС доступны через процедуры динамически подключаемых библиотек (DLL), а другие — через СОМ-объекты, весь прикладной сервис представлен общей объектно-ориентированной программной моделью.

• Упрощенная модель программирования CLR избавляет от работы с разными потаенными структурами, как это было с Win32 и СОМ. Так, разработчику не нужно разбираться с реестром, глобально-уникальными идентификаторами (QUID), lUnknown, AddRef, Release, HRESUIT и т. д. CLR не просто позволяет разработчику абстрагироваться от этих концепций — их просто нет в CLR в каком бы то ни было виде. Конечно, если вы хотите написать приложение .NET Framework, которое взаимодействует с существующим не-.NET кодом, вам нужно разбираться во всех этих концепциях.

• Отсутствие проблем с версиями Все Windows-разработчики знают о проблемах совместимости версий, известных под названием «ад DLL». Этот «ад» возникает, когда компоненты, устанавливаемые для нового приложения, заменяют компоненты старого приложения, и в итоге последнее начинает вести себя странно или перестает работать. Архитектура .NET Framework позволяет изолировать прикладные компоненты, так что приложение всегда загружает компоненты, с которыми оно строилось и тестировалось. Если приложение работает после начальной установки, оно будет работать всегда. Врата «ада DLL» закрыты."
Конкретно эта "интересная статья" ничего нового, в принципе, не рассказала.
Зато глубинное гугление намекнуло, что в отличие от строки и массива, Stream (и его производные, типа MemoryStream) сериализируется в буфер обмена правильно.

Так что в целом — спасибо за наводку. В следующий раз надо лениться чуть меньше :)
Хорошая статья.
Хотел бы обратить внимание по этой теме на еще один вариант (более тяжелый, но и более полный) решения проблемы:

http://blogs.msdn.com/jmstall/pages/samp…

Здесь тоже самое реализовано без импорта DLL.
Не проверял, но на первый взгляд у этого решения тоже будут косяки с кодировкой.
Да и нашлось уже, в принципе, полное решение без импорта.
Может следующий код поможет победить кодировку?

byte[] data = Encoding.UTF8.GetBytes(text);
text = Encoding.Default.GetString(data);
когда начал читать статью, вспомнил, как работал с буфером обмана на Borland Pascal for Windows больше десяти лет назад.
а когда вы в статье о .NET решили обратиться к WinAPI, понял, что за десять лет в программировании под Windows мало что изменилось :)
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.