Outlook не видны скрипты в окне скриптов

[kibernetics]

Форумчане,
написал небольшой обработчик на VBA. Сам скрипт виден на панели инструментов
http://forum.oszone.net/attachment.php?attachmentid=151326&d=1519068542

но когда добавляю правило к обработке письма, и среди прочих действий устанавливаю флаг "запустить скрипт", то в окне с выбором скриптов ничего не отображается.
Ни одного скрипта
http://forum.oszone.net/attachment.php?attachmentid=151327&d=1519068656

как так то? Что где включить можно?

[a_axe]

kibernetics, если макросы запускаются через кнопку (то есть их выполнение разрешено и они загружены), то вероятно причина в параметре (источник - support.microsoft.com - Создание сценария для мастера правил в Outlook (https://support.microsoft.com/ru-ru/help/306108/how-to-create-a-script-for-the-rules-wizard-in-outlook)):
Для реализации обработки сообщения настраиваемым кодом необходимо создать подпрограмму в Visual Basic for Applications. Само по себе имя подпрограммы значения не имеет, но оно должно принимать один аргумент, так как мастер правил будет передавать подпрограмме сообщение (MailItem) или запрос о встрече (MeetingItem). Тип аргумента должен быть MailItem или MeetingItem, иначе подпрограмма будет недоступна в мастере правил.
Нижеприведенный код Outlook Visual Basic for Applications демонстрирует процедуру создания подпрограмм:

Sub CustomMailMessageRule(Item As Outlook.MailItem)
MsgBox "Mail message arrived: " & Item.Subject
End Sub

Sub CustomMeetingRequestRule(Item As Outlook.MeetingItem)
MsgBox "Meeting request arrived: " & Item.Subject
End Sub
Подпрограммы можно разместить в любом модуле, включая ThisOutlookSession, но при перемещении подпрограммы в другой модуль или изменении имени подпрограммы необходимо изменить правило для указания на обновленную подпрограмму.
то есть достаточно указать параметр в качестве аргумента, использовать его в коде не обязательно, например код ниже доступен в мастере правил:
Public Sub dsf(Item As Outlook.MailItem)
MsgBox "Yes"
End Sub

[kibernetics]

Вот жеш... и видел же это где-то на форумах, про передачу параметра.
И не проверил, подумал чёта, что после какого-то там ноябрьского обновления это условие убрали. Ан нет...

Спасибо дорогой товарищ! Заработало.

[kibernetics]

Эх, зараза малая,
даёт выбрать скрипт, но не хочет в него входить.
Поставил брейк на макросе, включаю обработку входящего письма - зеро бадимувинг.
Чё делать?

И, вообще, может авторитетнее писать через
Private Sub Application_NewMailEx(ByVal EntryIDCollection As String)?

Но, как-то не очень удобно правила в таком случае прописывать.

[a_axe]

даёт выбрать скрипт, но не хочет в него входить. »
kibernetics, сложно сказать не увидев кода. Мой пример Код:
Public Sub dsf(Item As Outlook.MailItem)
MsgBox "Yes"
End Sub »
у меня выполняется именно через правило, т.е. саму процедуру outlook обрабатывает.
Поставил брейк на макросе, включаю обработку входящего письма »
Соответственно, выполняется ли само правило (добавьте какое-нибудь действие - вывести текст или оповещение, которое даст визуальное подтверждение, что само правило выполняется).
Если в процедуру попадаете - после брейка продолжите выполнение пошагово через F8, основные переменные скопируйте в окно Watches и отследите, присвоены ли им значения, как они меняются в процессе выполнения и т.д.

[kibernetics]

Надо провести ещё кое-какие исследования, но по ходу человек дело говорит,
A "run a script" rule is not a good choice for heavy traffic applications, as Outlook is likely to skip applying the rule if too many items arrive that meet the rule's conditions.

To avoid security prompts when accessing properties like Body and Recipients, you must use the technique above to get the item indirectly, through its EntryID property and the Namespace.GetItemFromID method (or Application.Session object). If you attempt to access MyMail.Body or MyMail.SenderName, for example (MyMail being the name of the parameter for the "run a script" rule procedure), you will get a security prompt.

Generally, items that you want to process by a "run a script" rule should not be processed by other rules or other actions in the same rule. Put that rule high on the list, and include the "stop processing" action. Include in your VBA procedure all the actions you want to take on the items that meet the rule's conditions.

WARNING: I have seen cases where a machine running "run a script" rules completely loses the VbaProject.otm file that contains all the Outlook VBA code. If you use "run a script" rules, be sure to back up VbaProject.otm regularly or export the individual modules.
Источник (http://www.outlookcode.com/article.aspx?id=62)

Дословно, если есть run script, то больше не должно быть других обработок.
К тому же, наблюдались случаи потери файла проекта.