KnigaRead.com/
KnigaRead.com » Компьютеры и Интернет » Программирование » А. Григорьев - О чём не пишут в книгах по Delphi

А. Григорьев - О чём не пишут в книгах по Delphi

На нашем сайте KnigaRead.com Вы можете абсолютно бесплатно читать книгу онлайн А. Григорьев, "О чём не пишут в книгах по Delphi" бесплатно, без регистрации.
Перейти на страницу:

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

Освободившуюся память менеджер памяти не сразу возвращает системе придерживает, чтобы иметь возможность быстрее выделить память при следующем запросе. Таким образом, после завершения работы DoGetClassInfo память, в которой хранится вычисленное имя оконного класса (и на которую указывает CI.lpszClassName), по-прежнему принадлежит процессу, но менеджер памяти полагает ее свободной и считает себя вправе использовать ее по своему усмотрению.

Когда присваивается значение переменной S, для размещения новой строки менеджер памяти выделяет ту самую область, в которой ранее хранилось имя класса. Так как CI.lpszClassName по-прежнему содержит этот адрес, обращение к этому полю возвращает новую строку, которая присвоена переменной S.

Примечание

В Delphi до 7-й версии включительно описанный эффект наблюдается при любой длине строки, присваиваемой переменной S, в более новых версиях Delphi — только в том случае, если длина этой строки находится в пределах от 5 до 11 символов. Это связано с тем, что новый менеджер памяти, появившийся в этих версиях Delphi, с целью уменьшения фрагментации разбивает кучу на несколько областей, в каждой из которых выделяет блоки памяти, укладывающиеся в соответствующий данной области диапазон размеров блоков. Если строка, присваиваемая переменной S, слишком сильно отличается по размеру от 'TForm1' для этой строки выделяется память в другой области, и подмены не происходит.

Если в данном примере не выносить вызов функции GetClassInfo в отдельную процедуру DoGetClassInfo, а вызывать ее напрямую из Button1Click, описанного эффекта не будет, потому что в этом случае освобождение памяти, занятой для вычисленного имени класса, будет производиться в эпилоге Button1Click, и на момент присваивания значения переменной S эта память будет считаться занятой, поэтому для S менеджер памяти выделит другую область.

Принципиально и то, что в обоих случаях (в функции GetClassInfo и при присваивании значения переменной S) используются не строковые литералы, а выражения, вычисляемые только на этапе выполнения программы. Строковые литералы размещаются компилятором в сегменте кода, и указатели, переданные в GetClassInfo и присвоенные переменной S, будут указывать не на динамическую память, а на эти литералы, и подмены не произойдет.

Избежать проблемы можно двумя способами. Во-первых, не следует передавать значение поля lpszClassName за пределы той функции, в которой была вызвана GetClassName. Во-вторых, имя оконного класса должно быть известно программе до вызова GetClassName. Лучше использовать ту строку, в которой хранится это имя, чем поле lpszClassName.

3.4.5. Ошибка EReadError при использовании вещественных свойств

Если в секции published компонента имеются свойства вещественного типа (Single, Double или Extended), то попытка присвоить в режиме проектирования формы этим свойствам некоторые вполне корректные значения приводит к ошибке EReadError при чтении ресурсов формы (т.е. при создании формы). Для типов Double и Extended ошибка возникает, если значение свойства X лежит в одном из указанных диапазонов:

-1e15 < х <= MinInt - 1

или

MaxInt + 1 <= X < 1e15

Не совсем понятно, при чем здесь значения MaxInt и MinInt, если речь идет о вещественных числах, но проблема существует. Типу Single не хватает точности, чтобы передавать значения MaxInt и MinInt без искажений. Тем не менее, с поправкой на уменьшение точности границ диапазонов, эта же ошибка возникает и для свойств типа Single. Ошибка возникает только в случае текстовой формы dfm-файла (все версии Delphi, начиная с пятой, по умолчанию используют эту форму). При бинарной форме dfm-файла ошибки не происходит.

Ошибка обнаружена в Delphi 5 и 6, причем в Delphi 5 попытка ввести значение из указанного диапазона также может привести к ошибке и в режиме проектирования, при переключении между текстом модуля и формой. В Delphi 6 были замечены ошибки только при запуске программы, в режиме проектирования они не возникали. В Delphi 7 эта проблема уже решена, указанные значения свойств не приводят к ошибкам. В более ранних версиях Delphi проблема, естественно, также отсутствует, потому что в них dfm-файл всегда представляется в бинарной форме.

Для решения проблемы могут быть рекомендованы два способа.

1. Обновить Delphi до седьмой (или более поздней) версии.

2. Выбрать бинарную форму dfm-файла. Для этого нужно щёлкнуть правой кнопкой мыши на форме и в открывшемся меню убрать галочки с пункта Text DFM

Можно также отказаться от присвоения проблемных значений свойствам в режиме проектирования и присваивать их во время выполнения программы.

3.4.6. Ошибка List index out of bounds при корректном значении индекса

Windows позволяет с каждой строкой списка элементов управления ListBoх и ComboBox связать либо число, либо указатель (точнее — некоторую четырехбайтную величину, которую программа может трактовать как число, как указатель или как что-либо еще). В VCL эта возможность обеспечивает привязку к строкам списка объектов (четырёхбайтная величина по умолчанию трактуется как TObject). Доступ к этим объектам осуществляется через свойства TComboBox.Items.Objects[Index] и TListBox.Items.Objects[Index].

Иногда все-таки требуется привязывать к строкам не объекты, а числа. Для этого можно воспользоваться явным приведением типов, например:

ComboBox1.Items.Objects[I] := TObject(17);

I := Integer(ComboBox1.Items.Objects[I]);

Если таким образом связать со строкой значение -1, то при попытке получить его во всех версиях Delphi до 7-й включительно возникнет исключение EStringListError с комментарием "List index out of bounds". Рассмотрим следующий код (листинг 3.56. пример ListIndex на компакт-диске).

Листинг 3.56. Пример кода, вызывающего исключение EStringListError

procedure TForm1.Button1Click(Sender: TObject);

var

 I: Integer;

begin

 ComboBox1.Items.Clear;

 ComboBox1.Items.AddObject('Text', TObject(-1));

 I := Integer(ComboBox1.Items.Objects[0]); { * }

 Label1.Caption := IntToStr(I);

end;

Исключение возникнет при попытке выполнить строку, отмеченную звездочкой, хотя очевидно, что индекс в данном случае корректен. Чтобы понять причину ошибки, необходимо рассмотреть, как осуществляется чтение значения, привязанного к строке, на уровне Windows API. Рассмотрим это на примере TComboBox. Для получения значения необходимо послать окну ComboBox сообщение CB_GETITEMDATA. Результатом обработки этого сообщения будет значение, связанное с указанной строкой, или CB_ERR, если при обработке сообщения возникнет ошибка. При этом документация не уточняет, какие именно ошибки могут в принципе возникнуть и как узнать, какая из них произошла.

Метод TComboBoxStrings.GetObject, через который читается значение свойства Objects, в Delphi 7 и более ранних версиях интерпретирует получение CB_ERR однозначно: генерирует исключение EStringListError с комментарием "List index out of bounds".

Проблема заключается в том, что константа CB_ERR имеет численное значение -1. Поэтому и в случае ошибки, и в случае, когда строке сопоставлено значение -1, системный обработчик сообщения CB_GETITEMDATA вернет одинаковый результат. И метод TComboBoxStrings.GetObject интерпретирует его как ошибку. (А что ему еще остается делать?)

Аналогичная проблема по тем же причинам возникает и для ListBox (аналогичная по смыслу константа LB_ERR также имеет значение -1). Это прямое следствие документированных особенностей работы Windows и модели работы VCL встречается во всех версиях Windows. Та же проблема возникает при попытке указать значение 4 294 967 295, т.к. на двоичном уровне это число записывается той же комбинацией битов, что и -1.

При использовании свойства Objects по прямому назначению, т.е. для хранения объектов, эта проблема не может возникнуть, потому что $FFFFFFFF — это адрес самого старшего байта в четырехгигабайтном виртуальном адресном пространстве программы. Эта область адресного пространства зарезервирована системой, и менеджер памяти Delphi не может выделить память для объекта в этой области. Рекомендуемые способы решения проблемы:

1. Пересмотреть алгоритм и отказаться от связывания значения -1 со строками.

2. Напрямую посылать CB_GETITEMDATA окну ComboBox, а попадание индекса в диапазон контролировать самостоятельно другими методами. Приведенный в листинге 3.57 код иллюстрирует последний совет.

Перейти на страницу:
Прокомментировать
Подтвердите что вы не робот:*