DAX40 #if.never в LedgerBondServer_RU

[Eldar9x]

А если в ClassDeclaration ввести пробел, или другое изменение, которое не изменяет сам код, а потом сохранить и перекомпилировать класс?

[DSPIC]

Опишу проблему - возможно, корень и решение общее.
Проблема
Некорректное обновление класса-наследника при смене его родителя.
Воспроизведение
1. Создаём класс-наследник RunBase
2. Создаём в этом классе произвольный метод и вызываем в нём любой метод базового класса, напр:
this.saveLast();
3. Компилируем.
4. Отвязываем класс от RunBase, т.е. делаем его самостоятельным, не наследником (убираем extends RunBase). Компилируем.
Симптомы
Что видим - класс всё-равно остался наследником RunBase. (об этом свидетельствует отсутствие ошибок в нашем методе, где вызывается метод базового класса. При выполнении происходит вызов методов родителя). Как его не компилируй, как не модифицируй и снова компилируй, а от RunBase он не отвязывается. Инкрементная компиляция RunBase также не помогает.
Решение
a. Раньше лечил так: экспорт класса, удаление из системы, импорт
b. Нашлось более изящное решение - обновление перекрестных ссылок именно для проблемного класса. Но не по контекстному меню, а из главного меню IDE.
Итак:
1) Tools->DevelopmentTools->CrossReference->Periodic->Update
2) В фильтре появившегося диалога устанавливаем фильтр на поле Имя=ВашКласс
3) Выполняется мгновенно, после чего с классом всё в порядке.
Что именно происходит внутри, и что конкретно исправляет этот недочёт компилятора - разбираться уж не стал.

Может поможет. (ещё раз обращу внимание, что нужно обновить CrossReference из меню IDE, а не по контексту. По контексту (как я предложил в 1-ом посту) не помогает)

[sukhanchik]

Цитата:

Сообщение от DSPIC

Опишу проблему - возможно, корень и решение общее.
Проблема
Некорректное обновление класса-наследника при смене его родителя.
Воспроизведение
1. Создаём класс-наследник RunBase
2. Создаём в этом классе произвольный метод и вызываем в нём любой метод базового класса, напр:
this.saveLast();
3. Компилируем.
4. Отвязываем класс от RunBase, т.е. делаем его самостоятельным, не наследником (убираем extends RunBase). Компилируем.
Симптомы
Что видим - класс всё-равно остался наследником RunBase. (об этом свидетельствует отсутствие ошибок в нашем методе, где вызывается метод базового класса. При выполнении происходит вызов методов родителя). Как его не компилируй, как не модифицируй и снова компилируй, а от RunBase он не отвязывается. Инкрементная компиляция RunBase также не помогает.

Попробовал.
Выполнил пп. 1-4.
Получил следующие симптомы:
1. Класс НЕ остался наследником RunBase. Об этом свидетельствует:
а) пустое поле Extends в свойствах класса (хотя я допускаю, что оно просто смотрит на ClassDeclaration)
б) невозможность выбрать метод из списка.
в) невозможность принудительно указать другой метод (например this.getLast())

2. Существующая строчка this.saveLast() в моем новом методе не "пострадала" и честно проходит компиляцию. Закомментаривание ее и последующая компиляция погоды не делают. Т.е. при раскомментировании - она снова проходит компиляцию.

Не пробовал глобальную компиляцию. Думаю, что должна помочь.

Почему я скептически отношусь к идеям про "волшебные" перекрестные ссылки.
Делов том, что аксапта при компиляции записывает откомпилированный код в отдельное поле таблички UtilElements. Т.е. каждый метод имеет свое "откомпилированное" значение. Эта табличка лежит в *.aod-шнике.
Соответственно - зачем нужна инкрементная компиляция? Чтобы пробежаться по всем наследникам и заново "пересобрать" ИХ откомпилированный ранее код (во время компиляции - код родителя как бы "копируется" в код наследника, т.е. конечный класс собирается "по чертежам" всех своих родителей).

Что получается здесь. Класс - то мы отвязали от RunBase (это подтверждается тем, что инкрементная компиляция RunBase до нашего класса не доходит, т.к. список классов для инкрементной компиляции генерируется на основе исходного кода, а не откомпилируемого).
Однако, отвязка получилась некорректной - ранее скопированные (необходимые для компиляции наследника) копии родительских методов остались в откомпилированном коде. И удалить их можно увы - только путем удаления всего откомпилированного кода.

При попытке удаления и создания метода - вызов saveLast() все равно "разрешается" в любом методе - что приводит к выводу - что этот метод в откомпилированном коде сохраняется при самом объекте (метод saveLast и только он был скопирован с родителя, но не был удален при отвязке родителя).

Что происходит, когда класс удаляется и снова импортируется. Ведь наверняка Вы экспорт/импорт делали без сохранения ID. А коли так - то нисколько не удивительно, что ошибки появились - ведь объекты в UtilElements идентифицируются по ID-шникам, который у Вас изменился. А соответственно - старая информация от компиляции не подтянулась.

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

Хотя - имеет смысл проверить.