1) Как получить ячейку памяти? 2)...

[GSerg]

Да нет такого DC...
DC - это структура, в которой описаны возможности устройства, а также графические инструменты, в него выбранные. На винт оно вообще никогда не сохраняется. Есть функции для работы с DC и всё. Не вижу ни одной причины быть недовольным этими функциями.

А что значит "скопировать байты в строку"? Смысл в этом-то какой? Что получить требуется? И если уже есть массив байт, то это может и неудобно, но он же assignment-compatible со строкой-то.

[Approximator]

Да нет такого DC...

Знаю, но надо было как-то лаконично объяснить, потому я так "неаккуратно" выразился.

DC - это структура, в которой описаны возможности устройства, а также графические инструменты, в него выбранные.

И что с того? Что "структура" это не данные? Строке какая разница чё в неё будут пихать?

На винт оно вообще никогда не сохраняется. Есть функции для работы с DC и всё. Не вижу ни одной причины быть недовольным этими функциями.

Не, ты не понял. Возможно, я невнятно выразился. Разумеется, часть данных из DC сидит на винте (иначе, в чём суть виртуальной памяти?). Короче, плевать на весь DC нужно скопировать байты данных ("картинка") в строку (желательно уметь делать обратное), но чтобы обмен между "картинкой" и строкой был как можно быстрее... безо всяких лишних посредников. По идее видимо пойду через GetDIBits (или GetBitmapBits?) и далее буду копировать данные из структуры BITMAPINFO прямо в строку. Если в этой моей идее что-то не так, то поясни.

А что значит "скопировать байты в строку"? Смысл в этом-то какой? Что получить требуется?

Подробно долго объяснять. Попробую вкратце, пояснить суть проблемы. Мне необходимо, как-то избежать преобразования StrConv(Str,vbFromUnicode)<->StrConv(Str,vbUnicode). Понятное дело, что обычная строка на каждый символ отводит по два байта. Причём адрес младшего байта каждого i-того символа StrPtr(Str)+(i-1)*2. Функция StrConv жутко медленная и при многократном повторении она пожирает массу времени. Мне было бы удобнее записывать данные числовых байтов в младшие байты строки (по идее это куда быстрее (примерно раза в 4)). Однако, эта сволочь (CopyMem) после операции, скажем,

Код: Выделить всё

Dim lStr as String, lV as Byte
lStr=" "
lV=255
CopyMem StrPtr(lStr),VarPtr(lV), 1

В младший байт записывает вовсе не 255, а 121...
Приходится делать так:

Код: Выделить всё

Dim lStr as String, lTS as string, lV as Byte
lStr=" "
lTS=StrConv(lStr,vbFromUnicode)
lV=255
CopyMem StrPtr(lTS),VarPtr(lV), 1
lStr=StrConv(lTS, vbUnicode)

Что неимоверно долго.

И если уже есть массив байт, то это может и неудобно, но он же assignment-compatible со строкой-то.

Правда? А если попробовать нижеследующий код:

Код: Выделить всё

Dim lS As String, lB() As Byte, lBv As Variant, lV As Long
lV = 255
lS = "Test"
lB = lS
For Each lBv In lB
  Debug.Print lBv
Next lBv
lS = lB
MsgBox lS
lB(LBound(lB)) = 255
lS = lB
MsgBox lS
For Each lBv In lB
  Debug.Print lBv
Next lBv

Первая буква должна стать "я"(255), а становится "у"(121), и это при том, что в первом lB(LBound(lB)) по прежнему содержится 255. То есть почему-то он часть слова воспринимает, как анси... Как бороться с этой хренью без StrConv'а я не знаю... Об том и вопшаю.

[GSerg]

Интересно, как же отвязаться от strconv, а главное, зачем

Это в английском языке юникод совпадает по кодировке с анси, а второй байт всегда 0. А в русском юникоде оба байта имеют значение.
Ну попробуй побаловаться с апишками WideCharToMultiByte и MultiByteToWideChar.

[Approximator]

Интересно, как же отвязаться от strconv, а главное, зачем

За стеклом. Правда, очень долго объяснять. Проверяется математическая работа, посвящённая поиску гомео- и гомо- морфизмов в информационных потоках.

Это в английском языке юникод совпадает по кодировке с анси, а второй байт всегда 0. А в русском юникоде оба байта имеют значение.

Причём здесь русский? Юникод по определению интернациональный. Возьми любой РУССКИЙ текст и переводи его в массив байтов. Если найдёшь хоть один старший байт в РУССКИХ СИМВОЛАХ не равный нулю сообщи, я буду очень долго удивляться. Ты шрифты когда-нибудь сам делал? Если да, то поймёшь почему.

Но, на самом деле меня беспокоит не это. Плевать мне на то, русский это или турецкий. Меня волнует вопрос сохранности информации при подобном преобразовании. Если у меня в массиве байтов заполнены все младшие байты, то почему какой-то один (или несколько, главное, что НЕ ВСЕ) символ воспринимается так, а какой-то иначе... вот этот бред мне не ясен. Короче, куда надо прописать, чтобы пара байтов в цепочке строки воспринималась так же, как и весь остальной текст. Я обратил внимание, что это происходит только с теми байтами, что были изменены "ручками".

Ну попробуй побаловаться с апишками WideCharToMultiByte и MultiByteToWideChar.

Уже, и довольно давно... тот же хрен, тьфу, прости, тот же StrConv, только "вид с боку". Как вообще от этого отказаться. Не в том вопрос, что что-то (целиком строку) нужно конвертировать во что-то... это была бы ерунда. Вопрос в том, что эта хрень совершенно нелогична, с моей точки зрения. Я понимаю, что после принудительной записи где-то выставляется значение, что эта пара байт уже не юиникод... где? Короче, как на уровне пропихивания байт можно эмулировать айпишные функции конвертирования не перенося инфы, а лишь поправляя заголовок или что-то ещё... Мне сдаётся, что это должно быть возможным.

[Approximator]

Всё, свой вопрос снимаю. Спасибо.

P.S. Понастоящему просто выглядит проблема, если копировать не в массив байтов, а если копировать строку в массив целых чисел... младший байт юникода просто нельзя выставить в число большее 127