Переполнение памяти во время работы макроса

Здравствуйте. Ох уж эта память. Сложно рекомендовать, так как рекомендации иногда понимаются неправильно, потом получается только хуже :(.

А большой скрипт? Оптимизировать и ускорить можно значительно. Щас темку кину по оптимизации (ну это по скорости). Нужно простой примерчик который вызывает проблемы, мы попробуем показать как его можно оптимизировать.

И еще по памяти.  Часто бывает что это в TechnologiCS проблема, при обычной работе вы этого не заметите, а при использовании в АПИ многие вещи вылезти могут. Так что тут не всегда оптимизация поможет. И нужно на каждой версии смотреть.

Да получил. Посмотрим, точную версию TechnologiCS скажите пожалуйста.

Ну в вашем случае все просто.

Объекты, которые создаются от Application как правило глобальные, и создаются один раз на весь сеанс работы программы. Таким образом мы можем безопасно писать такой код

Do While Not TCSApp.DocParams.DBTree.Selected.ParentNode Is Nothing '
  rNode=TCSApp.DocParams.DBTree.Selected.ParentNode.nodeid 
  TCSApp.DocParams.DbTree.DbNodeByNodeId(rNode).Selected = True  
Loop 

так как в течении всей работы объект TCSApp.DocParams будет один и тот же.

тоже самое относится и к строке  (которая у вас выполняется в цикле)

Set DOC_module=TCSApp.SingleDoc( CSDN_ … sInteger)

Это объект полученный от Application, и он тоже создается один раз (но один раз для каждого документа). При интенсивной работе это может вызвать проблемы с памятью.

Для того чтобы управлять данным поведением, предназначены методы

• IModule2.UserModuleName  Пользовательское уникальное имя модуля

• IModule2.UniqueUserModuleName Получить уникальное значение для UserModuleName
  

• IOcs_Application2.DeleteModuleByUserModuleName Удалить модуль по пользовательскому уникальному имени

• IOcs_Application2.ModuleByUserModuleName Получить модуль по пользовательскому уникальному имени
  

Таким образом, с помощью данных методов мы можем управлять временем жизни нужны нам объектов (НО!! не надо пользоваться этим повсеместно, могут быть другие побочные эффекты, которые вместо  контроля над объектами дадут серьезные проблемы)

Если ваш код переписать вот к таком виду

 Set DOC_module=TCSApp.SingleDoc( CSDN_Const.dspSearchDocByDocID,Vib_Module.Properties("PRJ_ID").AsInteger)
 If  Not DOC_module Is Nothing Then 
   ................
   DOC_module.UserModuleName = DOC_module.UniqueUserModuleName   
   Call TCSApp.DeleteModuleByUserModuleName(DOC_module.UserModuleName)
 End If

вы будете уничтожать созданные вами объекты.
Или еще лучше вот к такому виду, чтобы еще меньше  сделать вероятность влияния ошибки ( поскольку UniqueUserModuleName создаст уникальное имя, которое никому не будет известно).

 Call TCSApp.DeleteModuleByUserModuleName("MyUniqueName") 
  For ....
    Set DOC_module=TCSApp.SingleDoc( CSDN_Const.dspSearchDocByDocID,Vib_Module.Properties("PRJ_ID").AsInteger)
    If  Not DOC_module Is Nothing Then 
       DOC_module.UserModuleName = "MyUniqueName"
       ................
      Call TCSApp.DeleteModuleByUserModuleName( "MyUniqueName" )
    End If
 Next

надеюсь это поможет.

По желанию. Скриптовый движок сам отлично отслеживает все ссылки, так что особого смысла в таком коде нет, кроме может красоты. Бывает правда необходимо уничтожить объект в определенном месте программы, или просто ссылку убить дабы исключить последующее использование, тогда конечно требуется подобный код. Или скажем после вот такого кода

DOC_module.UserModuleName = DOC_module.UniqueUserModuleName   
Call TCSApp.DeleteModuleByUserModuleName(DOC_module.UserModuleName)
....
MsgBox DOC_module.UserModuleName

обращение к DOC_module после вызова DeleteModuleByUserModuleName вызовет ошибку, так как DOC_module в скрипте существует и валиден, а внутренний объект TechnologiCS уже уничтожен. В этом случае сброс DOC_module может быть и полезен, хотя система все равно отслеживает это.

По поводу

скажем так. Как я говорил выше, объекты, которые создаются от Application как правило глобальные, и создаются один раз на весь сеанс работы программы. Остальные объекты, полученные через Properties, ChildModules  и пр. уничтожаются автоматически, и никаких дополнительных действий с ними не требуется. Если же начать пользоваться приведенными выше функциями, то наоборот мы получим кучу глобальных объектов, да еще и с уникальным именем, до которых потом вы уже вряд ли достучитесь, а автоматически они уже не уничтожатся.

Вообще смысл вышеприведенных методов не столько для того, чтобы делать удаление, а для того чтобы можно было создавать свои собственные глобальные настройки и хранить их между запусками скриптов. Способы применения зависят от конкретных задач.
Пример. Запускается скрипт, который просит пользователя сделать кучу настроек, или выбрать что либо. Затем пользователь запускает другой скрипт, которому тоже нужны эти же самые  настройки. Мы можем через глобальные объекты создать (или запомнить уже существующий) некий нужный нам модуль и на старте скрипта попытаться найти его, если не нашли, то запустить выбор/создание настроек.

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

Кроме того, в вашем примере скорей всего можно было вообще обойтись без создания объекта TCSApp.SingleDoc( CSDN_ … sInteger), так как если он запускается например из режима Папки, то все необходимые свойства для работы не сильно отличаются от доступных в ISingleDoc (а вот в выборках к сожалению не так). Ну тут надо смотреть универсальность/гибкость, и без  TCS API Explorer тут никак не обойтись.