Портирование на Delphi XE4 идёт вполне успешно.
Всё меньше и меньше тестов не проходят.
Скорость работы правда существенно снизилась, так как я занимаюсь СОВСЕМ другими рабочими вопросами. Посему - портирую "в свободное от работы время".
ПРИНЦИПИАЛЬНЫХ сложностей не возникло, за исключением уже описанных ДВУХ ошибок - с открытыми массивами (http://18delphi.blogspot.com/2013/05/xe4.html) и "пустыми интерфейсами" (http://18delphi.blogspot.com/2013/06/blog-post_13.html).
С открытыми массивами - придумал workaround и жду update от Embarcadero (http://18delphi.blogspot.com/2013/05/resolved.html).
С интерфейсами - сложнее. Ошибка - плавающая. Пока "за хвост" - не поймал. Ловлю.
Ещё как-то странно себя ведёт TCanvas по сравнению с Delphi 7. Отдаёт ДРУГИЕ (немножко, буквально на пиксель) метрики шрифтов. И то - не всегда. Разбираться - пока не стал. Сделал для таких тестов ДРУГИЕ эталоны под XE4. По крайней мере - всё СТАБИЛЬНО работает в РАМКАХ новых эталонов. То есть - разница - систематическая, а не плавающая. Что УЖЕ радует. Если "ВДРУГ" будет "свободное время" - я конечно с этой разницей тоже поразбираюсь. Чисто из того, чтобы удовлетворить СВОЙ собственный интерес.
Пришлось ещё пока поправить "стандартные" ошибки VCL с которыми наши проекты - не живут (http://18delphi.blogspot.com/2013/06/embarcadero.html). Червь сомненья меня гложет - хочется сделать как-то по-другому. Без правки стандартного кода библиотек. Но я пока - не придумал как. Есть конечно опыт SuperVision и статьи от Багеля, про внедрение в код. Ну и "внерение в код" от ElPack/RX. Но я пока в этом - не очень силён. Всё ещё надеюсь придумать что-то менее хардкорное. Хотя бы "аккуратный" Cut'n'Paste на худой конец.
Серия про "ошибки" в VCL была тут - http://18delphi.blogspot.com/2013/04/vcl.html. Ну и рядом там. "Правки в VCL (N)".
Далеко не со всеми ПРИВЕДЁННЫМИ там правками наши проекты не живут. Но я уж привёл - ВСЕ известные правки. Так сказать "для полноты картины". Жаль, что нету "обратной связи"... Я думал - люди откликнутся... Начнут "бить ногами". Рассказывать, что "у меня руки кривые". Тишина... Тишина - она подозрительнее всего.
В общем - процесс идёт. Он пока не на "промышленной основе". Но идёт. Надеюсь, что всё будет удачно. И что и до 64-х бит - я тоже доберусь. А вот там - есть ВОПРОСЫ - http://18delphi.blogspot.com/2013/06/xe-64_7.html. ВОПРОСЫ - такие - СЕРЬЁЗНЫЕ. Что с НИМИ делать - ПОКА ВООБЩЕ - не знаю.
С правками VCL придумать бы что умное.... Чтобы не трогать стандартного кода.
Особенно вот этого:
procedure RegisterClass(AClass: TPersistentClass);
begin
RegGroups.Lock;
try
while not RegGroups.Registered(AClass) do
begin
try
RegGroups.RegisterClass(AClass);
except {V}
on E : EFilerError do
if (Format(SDuplicateClass, [AClass.ClassName]) = E.Message) then
// do nothing
else
raise;
end;//try..except {/V}
if AClass = TPersistent then Break;
AClass := TPersistentClass(AClass.ClassParent);
end;
finally
RegGroups.Unlock;
end;
end;
"Хозяин кода" ведь в дом вернулся...
Ибо приведённый код - это ну совсем не ошибка. Хотя мне и не очень понятно - ЗАЧЕМ все родительские классы регистрировать. Ибо и без этого - вполне себе работает. Но! Это - ЗАТОЧКА, под "мои конкретные нужды" с "хоккеем" с примесями в компонентах. Мы правда всё равно от dfm скоро откажемся. В их классическом виде. Есть МНОГО насущных потребностей. Например - инстанцирование контролов в формах с разными классами реализации в зависимости от внешних условий. dfm это всё равно не позволяет. Ну и IfDef в dfm не бывает. А "очень хочется". Ну и про FireMonkey - есть у меня пара "шальных мыслей" - как "разом" проект с VCL перевести на FireMonkey. Опять же - через условное инстанцирование. Взять и "ловко подменить" VCL-ные контролы на контролы FM. И получить - ДВЕ ВЕРСИИ приложения - на VCL и на FM. Там конечно есть сложности, но они - решаемы. Наверное - максиму, что придётся - "выделять фасады". Как мне пока кажется. Это пока только в теории правда. Но я кое что - уже обкатал на практических примерах. В основном на VGScene правда. Но "окна - они и в африке окна". Про мультиплатформенность - пока вообще - НЕ ГОВОРЮ и НЕ ДУМАЮ. Пусть Delphi XE5 или XE6 выпустят :-) С их то темпами. Тогда - и буду думать. Я боюсь, что раньше - я всё равно не успею. Разве что только FM ОТДЕЛЬНО от РЕАЛЬНЫХ проектов опробовать. И всё таки - тесты написать.
Всё меньше и меньше тестов не проходят.
Скорость работы правда существенно снизилась, так как я занимаюсь СОВСЕМ другими рабочими вопросами. Посему - портирую "в свободное от работы время".
ПРИНЦИПИАЛЬНЫХ сложностей не возникло, за исключением уже описанных ДВУХ ошибок - с открытыми массивами (http://18delphi.blogspot.com/2013/05/xe4.html) и "пустыми интерфейсами" (http://18delphi.blogspot.com/2013/06/blog-post_13.html).
С открытыми массивами - придумал workaround и жду update от Embarcadero (http://18delphi.blogspot.com/2013/05/resolved.html).
С интерфейсами - сложнее. Ошибка - плавающая. Пока "за хвост" - не поймал. Ловлю.
Ещё как-то странно себя ведёт TCanvas по сравнению с Delphi 7. Отдаёт ДРУГИЕ (немножко, буквально на пиксель) метрики шрифтов. И то - не всегда. Разбираться - пока не стал. Сделал для таких тестов ДРУГИЕ эталоны под XE4. По крайней мере - всё СТАБИЛЬНО работает в РАМКАХ новых эталонов. То есть - разница - систематическая, а не плавающая. Что УЖЕ радует. Если "ВДРУГ" будет "свободное время" - я конечно с этой разницей тоже поразбираюсь. Чисто из того, чтобы удовлетворить СВОЙ собственный интерес.
Пришлось ещё пока поправить "стандартные" ошибки VCL с которыми наши проекты - не живут (http://18delphi.blogspot.com/2013/06/embarcadero.html). Червь сомненья меня гложет - хочется сделать как-то по-другому. Без правки стандартного кода библиотек. Но я пока - не придумал как. Есть конечно опыт SuperVision и статьи от Багеля, про внедрение в код. Ну и "внерение в код" от ElPack/RX. Но я пока в этом - не очень силён. Всё ещё надеюсь придумать что-то менее хардкорное. Хотя бы "аккуратный" Cut'n'Paste на худой конец.
Серия про "ошибки" в VCL была тут - http://18delphi.blogspot.com/2013/04/vcl.html. Ну и рядом там. "Правки в VCL (N)".
Далеко не со всеми ПРИВЕДЁННЫМИ там правками наши проекты не живут. Но я уж привёл - ВСЕ известные правки. Так сказать "для полноты картины". Жаль, что нету "обратной связи"... Я думал - люди откликнутся... Начнут "бить ногами". Рассказывать, что "у меня руки кривые". Тишина... Тишина - она подозрительнее всего.
В общем - процесс идёт. Он пока не на "промышленной основе". Но идёт. Надеюсь, что всё будет удачно. И что и до 64-х бит - я тоже доберусь. А вот там - есть ВОПРОСЫ - http://18delphi.blogspot.com/2013/06/xe-64_7.html. ВОПРОСЫ - такие - СЕРЬЁЗНЫЕ. Что с НИМИ делать - ПОКА ВООБЩЕ - не знаю.
С правками VCL придумать бы что умное.... Чтобы не трогать стандартного кода.
Особенно вот этого:
procedure RegisterClass(AClass: TPersistentClass);
begin
RegGroups.Lock;
try
while not RegGroups.Registered(AClass) do
begin
try
RegGroups.RegisterClass(AClass);
except {V}
on E : EFilerError do
if (Format(SDuplicateClass, [AClass.ClassName]) = E.Message) then
// do nothing
else
raise;
end;//try..except {/V}
if AClass = TPersistent then Break;
AClass := TPersistentClass(AClass.ClassParent);
end;
finally
RegGroups.Unlock;
end;
end;
"Хозяин кода" ведь в дом вернулся...
Ибо приведённый код - это ну совсем не ошибка. Хотя мне и не очень понятно - ЗАЧЕМ все родительские классы регистрировать. Ибо и без этого - вполне себе работает. Но! Это - ЗАТОЧКА, под "мои конкретные нужды" с "хоккеем" с примесями в компонентах. Мы правда всё равно от dfm скоро откажемся. В их классическом виде. Есть МНОГО насущных потребностей. Например - инстанцирование контролов в формах с разными классами реализации в зависимости от внешних условий. dfm это всё равно не позволяет. Ну и IfDef в dfm не бывает. А "очень хочется". Ну и про FireMonkey - есть у меня пара "шальных мыслей" - как "разом" проект с VCL перевести на FireMonkey. Опять же - через условное инстанцирование. Взять и "ловко подменить" VCL-ные контролы на контролы FM. И получить - ДВЕ ВЕРСИИ приложения - на VCL и на FM. Там конечно есть сложности, но они - решаемы. Наверное - максиму, что придётся - "выделять фасады". Как мне пока кажется. Это пока только в теории правда. Но я кое что - уже обкатал на практических примерах. В основном на VGScene правда. Но "окна - они и в африке окна". Про мультиплатформенность - пока вообще - НЕ ГОВОРЮ и НЕ ДУМАЮ. Пусть Delphi XE5 или XE6 выпустят :-) С их то темпами. Тогда - и буду думать. Я боюсь, что раньше - я всё равно не успею. Разве что только FM ОТДЕЛЬНО от РЕАЛЬНЫХ проектов опробовать. И всё таки - тесты написать.
Комментариев нет:
Отправить комментарий