Раздел: Программирование>ВзаимодействиеСОкружением>Active X
Если ваши компоненты требуют внешних Com объектов и надо автоматически установить их на клиенте.
- разместить dll с компонентом в папке приложения Share\Include
- создать подкласc Класс / Sys File Delpoyment Dll?
- перекрыть метод filename – и написать в его теле return «имя_файла» (без пути)
- добавить classNum(Имя Вашего Подкласса?) в перечень в методе Класс / Sys File Deployer / Files To Deploy?
- увеличить на 1 значение макроса #define.CurrentVersion(1) в Класс / Sys File Deployer / Class Declaration?
После входа пользователя в систему осуществляется следующий набор действий:
- проверяется признак установленности файлов (он сохраняется в Таблица / Sys Last Value?)
- если он отсутствует, то проверяется наличие на клиенте всех файлов, которых надо устанавливать
- если есть файл, остутствующий на клиенте, запрашивается подтверждение установки у пользователя
- если установка подтверждена, он переписывается на клиент («C:\Program Files\Navision\Client\Bin») и регистрируется
В версии 4 Microsoft Dynamics Ax данный механизм сломался ввиду новой функциональности — Code Access Security? (при работе на сервере с опасными API надо предварительно программно просить разрешение) и был отключен.
И в части вызовов demand() в новоиспеченном Win API Server? все в порядке. А вот в классах Sys File Deployment?* требования по вызову assert() соблюдены не везде – видимо, не хватило времени дотестировать. Если конкретно, то:
- в SysFileDeploymentFile.serverVersion() нет соотв. вызова assert() перед вызовом WinAPIServer::getFileModifiedDate();
- в SysFileDeployment.getServerFileTimeAccessed()/Modified()/Created() нет соотв. вызова assert() перед вызовом WinAPIServer::getFileTime();
- в SysFileDeployment.isNameValid() полный путь к файлу разбивается с помощью fileNameSplit() на составляющие, после чего между именем и расширением вставляется лишняя точка (fileNameSplit() и так возвращает расширение с начальной точкой) – в результате isNameValid() всегда возвращает false, из-за чего опять-таки не происходя соотв. вызовы assert();
- ну и, наконец, SysFileDeployment.sourcePath() по умолчанию возвращает xInfo::directory(Directory Type?::Include), а как нам известно, результат этого вызова сильно различается в зависимости от того, происходит ли он на клиенте или на сервере; разумеется, по закону подлости работа SysFileDeploy* построена так, что SysFileDeployment.sourcePath() вызывается в обоих контекстах и, соотв., выдает разные результаты, что окончательно рушит логику работы.
Во
вложении — небольшие модификации, с помощью которых удалось заставить работать Sys File Deployer? с тестовым классом-наследником Sys File Deployment File?.
см.: