Преобразование целых чисел в двоичные — как это делается на Android (по сравнению с Windows) — XE5

Итак, вчера я открыл вопрос о преобразовании целых чисел в двоичные, который был мне немного неясен, о том, как это работает (с операциями сдвига). Теперь у меня есть еще один вопрос, который нужно отвлечь: как это делается на Android, почему это приводит к другому результату, чем в Windows, и как получить фактический двоичный результат, а не то, что я получаю сейчас (и об этом я еще не говорил). ясно, что это такое; это какой-то шестнадцатеричный с неправильным значением).

У меня есть этот код в мобильном проекте firemonkey, в котором в качестве целей установлены платформы Android и Windows. Таким образом, тестирование кода может быть выполнено с ориентацией на окна, чтобы он быстрее компилировался и отображался как виртуальная мобильная форма; Ну, по крайней мере, намерение состоит в том, чтобы сделать это, но похоже, что это не такой надежный источник ошибок...

В то время как тот же проект, запущенный на Win32, работал нормально, его запуск на Android приводит к тому, что бинарный результат не получается из функции.

Я использую этот код для преобразования:

function IntToBin(Value: Integer): string;
var
  i: Integer;
begin
  SetLength(Result, 9);
  for i := 1 to 9 do begin
    if (Value shr (9-i)) and 1 = 0 then begin
      Result[i] := '0'
    end else begin
      Result[i] := '1';
    end;
  end;
end;

Отладчик показывает это при попытке преобразовать значение «1»:

Result: 0x6d09d738
   *Result: #0'00000000'                      [expanded from Result]
Value: 1

Теперь я знаю, что причина, по которой я тогда (после завершения основной процедуры, которая вызывает эту функцию преобразования) получает ровно половину значения того, что должно быть (1 вместо 3, 2 вместо 4, 8 вместо 16 , 6 вместо 12...) потому что в *Result ясно, что это только 8 бит, когда мне нужен 9-битный результат (я делаю преобразования из Integer (1..512) в двоичный...), и поэтому вместо чтения 2 как 0010 я получаю 001, что равно 1, вместо 6 (0110) я получаю 3 (011), 8 (1000) я получаю 4 (100) и т. д....

Теперь я действительно хочу знать, почему сначала он даже выдает результат как 0x6d09d738 / 0x6d09d738, а не просто двоичный, и почему он не 9-битный, поскольку я задал длину строки результата?

Кроме того, вот еще одна интересная и непонятная для меня вещь:

Это моя процедура, которая вызывает покрытие:

procedure TForm1.CalculateAddress1;
var SetDip: string;
    C: integer;
begin
  SetDip := IntToBin(StrToInt(MergeAddr));
  //Text1.Text:=SetDip;
  for C := 1 to 9 do
    begin
      if Copy(SetDip, b, 1) = '1' then
      DipSW[10-b].IsChecked:=True
      else DipSW[10-b].IsChecked:=False;
    end;
end;

// (Я использую это для преобразования адреса dmx в конфигурацию DIP-переключателя...)

SetDip получает что-то вроде значения #0'00000000'. (он отличается; это тот случай, когда целое число, которое было преобразовано, равно 1; для 11 я получаю #0'00000101' );

В результате получается точное половинное значение, как и должно быть (как я упоминал выше; и я понимаю, почему это происходит, поскольку отсутствует один бит результата...).

Однако, если я удалю // из Text1.Text:=SetDip;, который я поставил туда, чтобы увидеть результат на экране телефона, я получаю следующую ошибку, только на телефоне! (опять же, таргетинг на окна работает нормально):

'Индекс строки вне допустимого диапазона (-1). Должно быть >= 0 и ‹= 8';

После этого возникает ошибка сегментации, 2 ошибки нарушения доступа и, наконец, приложение закрывается.

Похоже, он не может скопировать SetDip в поле Text1.Text; Это то, о чем я думал. Но позже я узнал, что эта ошибка возникает не всегда, что было странно, поскольку она должна, и не только: она должна происходить, даже когда я оставляю Text1.Text:=SetDip вне кода; -> Я не знаю, как он копирует строку с индексом 9, если она не такая длинная; Я знаю, что именно по этой причине он выдает ошибку, но опять же: почему не всегда?

[[ Ps: +, обнаружил, что Firemonkey автоматически обрабатывает фиксированные массивы, если код пытается создать запись за пределами определенного размера. Интересно... :) Может быть, это означает, что он сам обрабатывает длину строки и индексы копирования..? ]]