Разработчики из SV меня не перестают удивлять!
Они или лентяи, или там вообще планирование разработок новых версий/исправление ошибок поставлено «из рук вон плохо».
Начал вот перевод некоторых своих приложений с C50 на C55. И сразу на «H» релиз.
Кстати, что-бы не забыть — после перевода не обнаружил никаких проблем с полями файлов, в именах которых есть символ «_». О чем тут как раз шло обсуждение.
Да и вообще — переход прошел настолько гладко, что даже как-то не посебе:) Так и жду, что где-то рано или поздно вылезет какая-либо гадость. Приложения очень большие и практически невозможно их протестировать за приемлемое время.
Проблема обнаружилась только одна — в одном месте производится переадресация колонок List-а на разные поля очереди. И, в связи с тем, что в C55 немного по другому производится нумерация полей групп/очередей, то переадресация попала на поля-массивы.
А с такими полями, как и раньше, в C55 БОЛЬШИЕ проблемы! Как не умели функции WHAT/WHO/WHERE корректно работать с такими полями, так и не умеют. Что, естественно, сказывается на работе List-ов.
Ну, да ладно! Речь о другом. Уже не один раз в рассылке обсуждался вопрос о проблемах при работе с рефералами на группы. В частности, о невозможности нормального создания новых экземпляров групп, типа:
MyGrp &= NEW(TInfoGrp)
В качестве решения данной проблемы, например Александр Бирюков предлагал использовать конструкцию типа:
MyGrp &= (NEW(STRING(SIZE(TInfoGrp))))
Но, созданный таким методом, реферал является неполноценным, что довольно существенно ограничивает его использование. О чем уже писалось в данной рассылке.
Так вот, приятная новость!
В C55 релиз «H» появилась-таки возможность создавать нормальные новые экземпляры групп, которые являются полностью полноценными рефералами на группы.
Правда, как можно догадаться из начала этого письма, не все так хорошо, как хотелось-бы. Опять-же, как и раньше, создать новый экземпляр стандартным способом невозможно — не пропустит компилятор. Но разработчики немного модифицировали как сам компилятор, так и ядро Клариона.
В компилятор, в частности, ввели правильную обработку операторов присваивания типа:
MyGrp &= (…)
Если прежние версии просто записывали в первый LONG реферала MyGrp значение в скобках, то в новом релизе уже предпринята попытка заполнения ВСЕХ полей реферала, который для групп, как известно, состоит из 3 LONG-полей. Но, опять-же, все сделано так, что больше напоминает попытку латания дыр «на ходу»!
Как я уже упомянул в ядро Клариона, для поддержки вышеописанного кода, введена новая функция Cla$String2Ref. Эта функция производит обычный разбор входной строки, предполагая найти в ней три числа, разделенные символом «:».
Вообщем, суммируя все вышесказанное, предлагаю код функции, которая позволяет создавать новые экземпляры групп.
Map
NewGroup(*GROUP _Grp),STRING
End
TGrp GROUP
Name STRING(10)
Code LONG
Index LONG
END
FRec &TGrp
Code
FRec &= (NewGroup(TGrp))
! Получили ПОЛНОЦЕННЫЙ реферал на группу TGrp
! Следует заметить, что в пределах декларации
! реферала FRec этот реферал будет обрабатываться
! компилятором ВСЕГДА как группа типа TGrp,
! независимо от параметра функции NewGroup.
! А вот за пределами видимости этой декларации,
! например в процедурах, в которые этот реферал
! передавался просто как &GROUP, он будет
! обрабатываться именно как группа типа
! параметра функции NewGroup.
Return
NewGroup PROCEDURE(*GROUP _Grp)
RefInfo STRING(32)
RefStr &STRING
RefGrp GROUP
Ref &GROUP
GROUP,OVER(Ref)
Addr LONG
DefPtr LONG
Size SIGNED
END
END
Code
RefGrp.Ref &= _Grp
RefStr &= NEW(STRING(RefGrp.Size))
RefInfo = Address(RefStr) &':'& Size(RefStr) &':'& RefGrp.DefPtr
RefStr &= Null
Return(RefInfo)
Кстати, можно не боятся опИсаться, и написать, например:
FRec &= NewGroup(TGrp)
Компилятор просто не пропустит подобную конструкцию.
Больше надо опасатся опИски типа:
FRec = NewGroup(TGrp)
или
FRec = (NewGroup(TGrp))
Вообщем, опять, в который раз, разработчики поленились довести дело до логического завершения!