Если среди первых 256 байт файла встречается русская буква 'я', то то оболочка считает этот файл двоичным, и предлагает редактировать его в виде шестнадцатеричных кодов. Помогает только перекодировка файла сторонними средствами в UTF-8 или Unicode.
Ну или конечно можно просто вставить заголовок пустышку – например 256 символов ‘/’
Update 2 - Исправлено
Есть такая фича - пока редактируешь файл, тебе уже показывают ошибочки которые ты допустил - этакая проверка синтаксиса на фоне. Так вот она что-то не очень хорошо работает. Например есть файл который нормально компилируется, однако при редактировании показывает такое:
Update 2 - Воспроизвести не удалось
Update 2 - Проверить не удалось, в окно 'Model view' ничего вообще построить не удалось. Видать чего то не понял :).
Различаются левый и правый ALT. В частности, не работает RightALT+Backspace, RightALT+F12. Однако, LeftALT+Backspace, LeftALT+F12 работают нормально.
Update 2 - Смех да и только. Теперь, где-то работает, где-то нет. Например, RightALT+F12 нормально переключает из режима формы в режим текст, но обратно переключать не хочет!:)
Есть фрагмент:
uses
;
располагающийся в середине окна (по высоте). Далее, вводим символ ‘.’ (точка) после awString, и экран сролируется так, что строка с “,Registry” становится первой строкой окна.
Забавно, но если такое уже написано, то иногда это даже приводит к переключению вкладок. Т.е. если такое написано в открытом файле Unit1.pas, а ты редактируешь Unit2.pas, то тебя могут ни с того ни с сего переключить на Unit1.pas!
Update 2 - Проблема осталась
В модуле Graphics в процедуре InitDefFontData инициализируется структура DefFontData при этом, имя фонта устанавливается по значению параметра ‘MS Shell Dlg 2’ из раздела HKEY_LOCAL_MACHINE\ SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes реестра (если он есть). В Windows XP, в параметре ‘MS Shell Dlg 2’ обычно находится имя фонта ‘Tahoma’. А поскольку DefFontData используется как фонт по умолчанию для ВСЕХ создаваемых объектов tFont, то все формы отображаются именно фонтом Tahoma. В предыдущих версиях Delphi, в DefFontData всегда был задан фонт 'MS Sans Serif'. Поэтому, формы старых проектов начинают отображаться неправильно.
Как мне кажется, вместо значения параметра ‘MS Shell Dlg 2’ надо брать значение параметра ‘MS Shell Dlg’, который определяет имя шрифта семейства ‘MS Sans Serif’ для стандартных диалогов. Особенно учитывая тот факт что, поиск во всех файлах каталогов ‘Windows’ и ‘Programm files’ показал что кроме как некоторые программы из Delphi 2005, никто больше параметр ‘MS Shell Dlg 2’ не использует!
Мой рецепт лечения: Выполнить замену ‘MS Shell Dlg 2’ на ‘MS Shell Dlg 0’ в файлах: lib\Graphics.dcu, lib\debug\Graphics.dcu и <Windows>\System32\vcl90.bpl
Патч можно взять здесь. Однако замечу, исходники (Graphics.pas), этот патч НЕ МОДИФИЦИРУЕТ!
Update 2 - Проблема осталась, не смотря на то, что для Charset = SHIFTJIS_CHARSET теперь сделано исключение :)
В окне результатов поиска в файлах, русские символы отображаются «кракозябрами»
Update 2 - УРОДЫ! Теперь отображается нормально, а вот искать русские слова не хочет!
Под Windows нужно делать регистро-независимое сравнение
Update 2 - Проверять не стал
Очень часто в своих программах применяю подобную форму записи:
Msg+^M^J^I
Так вот, проверка синтаксиса выполняемая на фоне, такого не понимает и говорит что здесь ошибка. При нормальной компиляции это признается вполне допустимым, не вызывая даже предупреждений.
Update 2 - Ну точно уроды! Теперь, форма Msg+^M^J^I все так же дает ошибку, зато Msg+^M+^J+^I считается нормальным!
Форма Msg+#13#10 считается допустимой (ранее не проверял).
Как и ранее, все перечисленные формы нормально транслируются компилятором! В общем, бардак продолжается.
Ошибка в обозначении строк продуцирующих код (синие точки).
Похоже это связанно со способом определения константы ‘o’
Update 2 - Воспроизвести не удалось, возможно исправлено.
Ну тут вообще, ошибки не понятной природы.
Update 2 - Воспроизвести не удалось
Ошибка при сохранении значения свойств некоторого вида в поток.
Вот например определяем такой компонент:
type
tMyEnum = (me0,me1,me2);
tMyEnumSubrange = me1..me2;
tMyEnumSubrangeSet = set of tMyEnumSubrange;
tMyControl = class(TControl)
private
fMyEnumSubrangeSet :tMyEnumSubrangeSet;
published
property MyEnumSubrangeSet: tMyEnumSubrangeSet
read fMyEnumSubrangeSet
write fMyEnumSubrangeSet;
end;
Далее пишем такой код:
procedure TForm1.Button1Click(Sender: TObject);
var
sb, st :TMemoryStream;
c :tMyControl;
s :String;
begin
RegisterClass(tMyControl);
c := tMyControl.Create(Nil);
c.MyEnumSubrangeSet := [me1,me2]; // <--
sb := TMemoryStream.Create;
st := TMemoryStream.Create;
try
sb.WriteComponent(c);
sb.Position := 0;
ObjectBinaryToText(sb,st);
st.Position := 0;
SetLength(s,st.Size);
st.ReadBuffer(s[1],Length(s));
ShowMessage(s); // show MyEnumSubrangeSet = [me2,Unit1] !
finally
sb.Free;
st.Free;
c.Free;
end;
end;
Ну и в выводимом окне вместо [me1,me2] видим [me2,Unit1]!
Этот пример был сделан специально для локализации ошибки. А реально столкнулся с таким при использовании EhLib’овского tDbGridEh. Приводило это к тому, что при чтении формы из DFM-файла Delphi сообщал об ошибке в значении свойства. А иногда, даже ничего не говорил, а молча считывал не правильно!
Ошибка в модуле Classes. Есть там в методе TWriter.WriteProperty вложенная процедура WriteSet: Вот ее текст из Delphi 2005:
procedure WriteSet(Value: Longint);
var
I, MinValue: Integer;
BaseType: PTypeInfo;
begin
BaseType := GetTypeData(PropType)^.CompType^;
MinValue := GetTypeData(BaseType).MinValue;
WriteValue(vaSet);
for I := 0 to SizeOf(TIntegerSet) * 8 - 1 do
if I in TIntegerSet(Value) then
WriteStr(GetSetElementName(BaseType, I + MinValue));
WriteStr('');
end;
И для сравнения текст той же процедуры из Delphi 6:
procedure WriteSet(Value: Longint);
var
I: Integer;
BaseType: PTypeInfo;
begin
BaseType := GetTypeData(PropType)^.CompType^;
WriteValue(vaSet);
for I := 0 to SizeOf(TIntegerSet) * 8 - 1 do
if I in TIntegerSet(Value) then WriteStr(GetEnumName(BaseType, I));
WriteStr('');
end;
Думаю комментариев не требуется!
Полный тестовый проект демонстрирующий это ошибку можно взять здесь
Мой рецепт лечения: Либо патчить <Windows>\System32\vcl90.bpl, lib\debug\Classes.dcu и lib\Classes.dcu. Либо избавляться от свойств имеющих тип множества от поддиапазона базового типа.
Патч можно взять здесь. Однако замечу, исходники (Classes.pas), этот патч НЕ МОДИФИЦИРУЕТ!
Update 2 - Исправлено
Неправильно работает редактирование свойств-коллекций у компонентов принадлежащих форме от которой унаследована редактируемая форма. Та же проблема встречается и при редактировании свойств-коллекций у компонентов принадлежащих лежащему на редактируемой форме фрейму
Проще на примере.
1. Создаем проект с формой Form1;
2. Кладем на Form1 компонент tDBGrid;
3. Создаем еще одну форму Form2 наследуя (inherit) ее от Form1;
4. Редактируя Form2 вызываем редактор колонок унаследованного tDBGrid;
5. Добавляем несколько колонок;
6. Закрываем редактор колонок;
7. Снова открываем редактор колонок и пытаемся удалить любую колонку – возникает ошибка.
Причем, попытка удалить добавленные колонки не закрывая редактор колонок нормально выполняется.
Проблема в модуле ColnEdit.pas, причем, как выяснилось она возникла еще в Delphi 7. Как показал анализ модуля, в редакторе свойств-коллекций, была попытка добавить запрет на удаление элементов коллекции принадлежащих предку. Однако, на мой взгляд по ошибке, была вообще отрезана возможность удалять элементы коллекций у свойств объектов принадлежащих предку.
Более того, когда после возникновения такой ошибки мы закрываем окно редактора колонок, происходит переключение на другое Windows-приложение
Полный пример здесь. Нужно отрыть форму Form2 (в модуле Unit2), дальше двойной щелчок на DbGrid'е и вы в редакторе колонок. Теперь попробуйте удалить любую колонку.
Мой рецепт лечения: патчить <Delphi>\bin\designide90.bpl, либо переопределить стандартный редактор для свойств-коллекций (TCollectionEditor). Первый вариант реализован. Правда, вместо устранения ошибки, я просто выключил новоиспеченную проверку, и поведение редактора стало таким же как в Delphi 6.
Патч для <Delphi>\bin\designide90.bpl можно взять здесь.
Update 2 - Блин. Я офигиваю! Похоже в Borland остались работать одни студенты-первокурсники!
Судя по исходникам, была попытка что-то исправить. Но, получилось как в анекдоте: Резали яйца нее тому негру!
Когда включена опция Debuger Options -> Mark buffers read-only on run то иногда после завершения отлаживаемой программы, режим read-only с открытых окон редактирования не снимается. К сожалению, эффект проявляется не часто. Пока точно не могу формализовать когда это происходит, кажется тогда, когда при отладке возникали исключительные ситуации, но это пока не точно. Очень не удобно когда открыто файлов 15-20 - получаешь море "удовольствия" ходить потом и каждому снимать режим read-only. Приходится отказываться от режима Mark buffers read-only on run.
Update 2 - Проверять не стал
Ни с Shift, ни с Ctrl не позволяют выделить разнотипные не визуальные компоненты. Например tADODateSet и tDataSource. В Delphi 6 я этим пользовался для того чтобы скопировать (через буфер обмена) сразу несколько связанных не визуальных компонентов из одной формы(проекта) в другую форму(проект).
Update 2 - Исправлено
При редактировании модуля формы от которой унаследованы другие формы которые тоже открыты, периодически (при перерыве ввода более 2х секунд), "выскакивает" модальное окно с сообщением "В экземпляре объекта не заданна ссылка на объект.". Вероятнее всего это связанно с проверкой синтаксиса на фоне, и наверняка зависит от компонент лежащих на форме и их свойств. Выяснять подробнее не стал. Очень сильно мешает.
Update 2 - Воспроизвести не удалось, может исправлено.
"Сворачивание" кода функций/методов не работает когда функция попадает в неактивную ветку блока условной трансляции. При этом. [+] даже не показывается.
Update 2 - Проблема осталась
При редактировании длинной строки (>200 символов) наблюдал странное поведение редактора. Если встать на начало такой строки, и перемещать курсор стрелкой вправо, то сначала все как обычно - при каждом нажатии, курсор перемещается на один символ вправо. Однако, когда курсор стал приближаться к правому краю окна, поведение изменилось. Теперь при каждом нажатии, происходило не только смещение курсора, но и скролирование текста влево. Это конечно удобно, если бы не одно но. Скролирование выполняется не на одну позицию а на несколько! Т.е., если продолжать нажимать стрелку вправо, через некоторое время, курсор вовсе исчезает с экрана - он за левой границей окна. Особенно неприятен эффект при быстром автоповторе.
После того как я наткнувшись на это "поигрался" курсором туда-сюда, Delphi вообще "повис" намертво. Пришлось "душить" процесс Task Manager'ом. Естественно потерял сделанные изменения :(.
Возможно подвисание и не связанно с этим эффектом.
Строка на которой это возникало:
Права и обязанности сторон: ~~Отв.МТС:
~~Отв.контрагента: ~~Существенные условия: ~~Особенности расторжения: ~~Стандарты:
Опять "поигрался", и опять "подвесил".
Правда опять не запомнил как :), кажется
что-то связанное с выделением прямоугольным
блоком. Дальше "развлекаться" не стал.
Update 2 - Проблема осталась
До чего же Delphi 2005 не любит русские буквы. Вот еще.
У меня в файле есть следующий текст:
ForceDirectories(StartDir+'Filters\');
with FileNamesList('Filters\*.filter') do try
Sort;
if not frList.adbFilter.Checked then begin
AddMenuItem(NewMenuItem(popFilters,'Включить',-1,
popFiltersOnSelectOnOff));
end
else begin
AddMenuItem(NewMenuItem(popFilters,'Выключить',-1,
popFiltersOnSelectOnOff));
AddMenuItem(NewMenuItem(popFilters,'Сохранить
текущий ...',24,popFiltersOnSelectSaveAs));
end;
Теперь, если встать в позицию
50 первой строки этого фрагмента, а затем
нажимать клавишу "стрелка вниз",
то позиция в каждой последующей строки будет "скакать" вправо-влево.
Величина скачка находится в прямой зависимости от числа русских букв в
строке левее курсора. Более того, если например десять раз нажать
"стрелка вниз" а
потом десять раз "стрелка вверх" то, как и следует ожидать,
мы вернемся в ту же строку, однако позиция в строке будет уже другая
- 49!
На первый взгляд не так уж и страшно. Но, такое поведение неприемлемо при записи и выполнении макрокоманд, что очень сильно ограничивает их применение. А уж к чему это приводит если делать выделение прямоугольного блока, даже говорить не хочется, но покажу:
Update 2 - Проблема осталась
