Страницы: 1 2 3 След.
RSS
Восстановление связи с Ribbon
 
При работе с Ribbon бывает нужным переменная, содержащая интерфейс ленты (IRibbonUI).
В XML-файле мы указываем callback-процедура, которая вызывается при загрузке ленты.
XML:
Код
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<customUI xmlns="http://schemas.microsoft.com/office/2006/01/customui" on Load="OnRibbonLoad">
   <ribbon startFromScratch="false">
      <tabs>
         <tab id="rxTab1" label="Ribbon Pointer Test">
            <group id="rxGroup1" label="Error Generator">
               <button id="rxButton1"
                     on Action="GenerateError"
                     imageMso="HappyFace"
                     size="large"
                     label="Сгенерировать ошибку"
               />
               <button id="rxButton2"
                     on Action="InvalidateRibbon"
                     imageMso="HappyFace"
                     size="large"
                     label="Invalidate Ribbon"
                     tag=":)"
               />
            </group>
         </tab>
      </tabs>
   </ribbon>
</customUI>

Callback:
Код
Public ribbon As IRibbonUI
Sub OnRibbonLoad(ByRef IRibbon As IRibbonUI)
    Set ribbon = IRibbon
End Sub


Всё бы ничего, но когда возникает ошибка, переменная ribbon становится Nothing.
В прилагаемом мною файле я создал новую вкладку "Ribbon Pointer Test". В ней две кнопки:
1. Сгенерировать ошибку - генерирует ошибку делением единицы на ноль.
2. Invalidate Ribbon - обновляет ленту.

Код "Сгенерировать ошибку":
Код
Private Sub GenerateError(ByRef ctrl As IRibbonControl)
    Dim r As Long
    r = 1 / 0
End Sub


Код "Invalidate Ribbon":
Код
Private Sub InvalidateRibbon(ByRef ctrl As IRibbonControl)
    'RestoreRibbon
    ribbon.Invalidate
End Sub


После генерации ошибки нажатие на Invalidate Ribbon VBA выдаёт такое сообщение: "Object variable or With block variable not set". Другими словами, ribbon Is Nothing.

Решение данной проблемы может быть решено путём сохранения адреса ленты в памяти
Для этого:

1. Создаём именованный диапазон:
Код
Sub AddNameForRibbonPointer()
    Names.Add Name:="RibbonPointer", RefersTo:="", Visible:=False
End Sub


2. Объявляем Win32 API функцию RtlMove:
Код
#If VBA7 Then
Public Declare PtrSafe Sub CopyMemory Lib "kernel32" _
    Alias "RtlMoveMemory" (ByRef destination As Any, ByRef Source As Any, ByVal length As LongPtr)
#Else
Public Declare Sub CopyMemory Lib "kernel32" _
    Alias "RtlMoveMemory" (ByRef destination As Any, ByRef Source As Any, ByVal length As Long)
#End If


3. Сохраняем адрес ленты в именованный диапазон во время загрузки ленты:
Код
Public ribbon As IRibbonUI
Sub OnRibbonLoad(ByRef IRibbon As IRibbonUI)
    Set ribbon = IRibbon
    Names("RibbonPointer").Value = ObjPtr(ribbon)
End Sub


4. Создаём процедуру для восстановления адреса:
Код
Sub RestoreRibbon()
    
    If ribbon Is Nothing Then
#If VBA7 Then
        Dim lPointer As LongPtr
        lPointer = CLngPtr([RibbonPointer])
#Else
        Dim lPointer As Long
        lPointer = CLng([RibbonPointer])
#End If
        CopyMemory ribbon, lPointer, LenB(lPointer)
    End If

End Sub


Для проверки раскомментируйте строку 'RestoreRibbon в процедуре InvalidateRibbon.
There is no knowledge that is not power
 
аааааа.... весь мозг сломал. не работает эта зараза
 
Эксперты, помогите пожалуйста, через некоторое время работы отваливается ссылка на  ribbon. Не в результате ошибки, а просто через длительное время работы что ли, не могу понять. Как ее можно восстановить не перезагружая Ексель? Иногда открыто куча файлов и закрывать и заново открывать их не вариант вообще.
 
toxamstr, А что - мой способ не работает?
There is no knowledge that is not power
 
Да чет никак
 
и так код работает
вопрос, как проверить перед кодом
Код
CopyMemory ribbon, lPointer, LenB(lPointer)
наличие сохраненного обьекта, так как ексель виснет и пропадает.
проверки на пустое значение или очищать перед выходом и потом проверять на пустое значение не расматриваю, так как
не закривает вопрос вслучае аварийного закрития ексель.
 
Уважаемый, Johny!
В вашем коде допущена ошибка пункт 4.
Код
Names("RibbonPointer").Value = ObjPtr(ribbon)
записывает не число, а формулу. Например, записав число 33333333,
Код
Names("RibbonPointer").Value =  33333333
вы получите формулу "=33333333",
Код
 lPointer = CLng([RibbonPointer]) =CLng("=33333333")
что приводит к ошибке.
Правильно написать так, чтобы убрать знак равно:
Код
lPointer = CLngPtr(Mid(ThisWorkbook.Names("RibbonPointer").Value, 2))
VBA  (в отличие от VB) не умеет правильно обрабатывать конструкцию типа
Код
#If VBA7 Then
Public Declare PtrSafe Sub CopyMemory Lib "kernel32" _
    Alias "RtlMoveMemory" (ByRef destination As Any, ByRef Source As Any, ByVal length As LongPtr)
#Else
Public Declare Sub CopyMemory Lib "kernel32" _
    Alias "RtlMoveMemory" (ByRef destination As Any, ByRef Source As Any, ByVal length As Long)
#End If
После Else строка останется красной. Поэтому лучше сразу определить код для 64 битной системы - VBA 7
Код
Public Declare PtrSafe Sub CopyMemory Lib "kernel32"  Alias "RtlMoveMemory" (ByRef destination As Any, ByRef Source As Any, ByVal length As LongPtr)
или для 32 битной системы
Код
Public Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (ByRef destination As Any, ByRef Source As Any, ByVal length As Long)
А в остальном оригинальное, простое и отличное решение!
:idea:  :idea:  :idea:  
Изменено: despot69 - 01.10.2019 17:59:39
 
Цитата
despot69 написал:
VBA  (в отличие от VB) не умеет правильно обрабатывать конструкцию типа
Откуда инфа?
Цитата
despot69 написал:
После Else строка останется красной. Поэтому лучше сразу определить код для 64 битной системы - VBA 7
Условная константа компилятора Vba7 применяется, чтобы определить, работает ли программный код в версии 7 редактора VB (версия VBA, которая поставляется в Office 2010). Условная константа компиляции Win64 применяется, чтобы определить, какая версия (32-разрядная или 64-разрядная) Office функционирует на компьютере.
Поэтому так:
Код
#if Vba7 then 
'  Code is running in the new VBA7 editor 
     #if Win64 then 
     '  Code is running in 64-bit version of Microsoft Office 
     #else 
     '  Code is running in 32-bit version of Microsoft Office 
     #end if 
#else 
' Code is running in VBA version 6 or earlier 
#end if 

Мне microsoft по секрету рассказал.
«Бритва Оккама» или «Принцип Калашникова»?
 
Цитата
despot69 написал:
После Else строка останется красной
да, намекая на то, что эта строка не подходит под версию Excel или VBE. Но тем не менее сам проект при этом работает и компилируется прекрасно. Так что утверждение
Цитата
despot69 написал:
VBA  (в отличие от VB) не умеет правильно обрабатывать конструкцию
весьма ошибочно. Все там правильно обрабатывается и даже показывает, что именно не может быть выполнено в текущей версии.
Изменено: Дмитрий(The_Prist) Щербаков - 02.10.2019 09:08:01
Даже самый простой вопрос можно превратить в огромную проблему. Достаточно не уметь формулировать вопросы...
 
Добрый день, господа.
Если вы имеете ввиду, что конструкция #If...else работает в принципе, я согласен. Вопрос в том для чего ее применять. Декларация API - это не тот случай, и лучше так не делать, потому что может вызвать ряд серьезных проблем в  различных версиях и разрядности приложений MS Office. Так, например, использовать эту конструкцию для декларации API {x32;x64} на Win10 x64 в Excel 2016 x64 не получится в принципе. Т.к. редактор VBA выдаст ошибку, которую я прилагаю в скриншотах.

Одна из значительных проблем VBA - проскальзывание (неисполнение) кода. Кому приходилось сталкиваться с разработкой приложений, знает о чем я пишу. Даже если код работает - не значит, что его нужно использовать! Я накопил собственный опыт по использованию удачных (читай стабильных) приемов при разработке небольших корпоративных приложений на Access, начиная где-то с 2005 г. Есть ряд вполне рабочих конструкций, НО которых стоит избегать. Ярчайший пример - динамическое подключение/отключение библиотек. То, что стабильно никогда не работает, но ведь можно :) ))). Стабильно - это от PC к PC, от версии MSO к версии MSO.

VBA - не Java, обратная совместимость в новых объектах и их методах/свойствах/событиях может отсутствовать, и это вторая очень серьезная проблема.  
 
Уважаемый despot69, коллега! Этот форум читают тысячи пользователей, не вводите их в заблуждение! Конструкция, приведенная Вами в #10, корректно компилируется на любых конфигурациях Excel, она многократно упоминается разработчиком в документации.
Сообщение об ошибке на экране свидетельствует о неправильной установке у Вас MS Office - не определена переменная условной компиляции VBA7. Вы можете в этом сами убедиться. Зайдите в VBE Tools/VBAProject Properties и в окне "Conditional Compilation Arguments:" введите
Код
VBA7 = 1
Компиляция пройдет успешно.
Изменено: sokol92 - 15.10.2019 15:34:05
Владимир
 
Уважаемые коллеги, уважаемый sokol92. Я прекрасно знаком с Conditional Compilation Arguments, а также с Conditional Compiler Constant типа Win64, Win32,..., Vba7, Mac,... Сам код  
Код
#if Vba7 then 
'  Code is running in the new VBA7 editor 
     #if Win64 then 
     '  Code is running in 64-bit version of Microsoft Office 
     #else 
     '  Code is running in 32-bit version of Microsoft Office 
     #end if 
#else 
' Code is running in VBA version 6 or earlier 
#end if
верен, компилируется и работает! Я же написал, что конструкция #If...else работает в сообщении выше. Не в этом проблема. А проблема в том, что в этой конструкции объявление API x32 в #if OR #else вызывает ошибку! Внимательно посмотрите на скиншоты, вы не поняли о чем я пишу. И именно в Win10 Pro x64, MSO 2016 Pro x64, именно с последними обновлениями. И VBA7=True, и не глючит, и ни одна проверка не выявила причина. Это баг компилятора VBA, о чем я написал в MS. Когда отпишутся о причине, я непременно поделюсь.
И такие проблемы возникают периодически с разными объектами VBA. Именно поэтому я избегаю декларирования функций для x32 и x64, например. Либо 32, либо 64. Гораздо проще в офисе поставить на все рабочие машины ПО MS одинаковой разрядности. Я пишу прикладные программы для решения наших внутри корпоративных задач, и достаточно испытал проблем с обратной совместимостью, и различными версиями Win и MSO.  
 
Ни разу не сталкивался с подобной проблемой. Подобная конструкция кода используется многими коммерческими надстройками.
Специально обновил сейчас  MS Office профессиональный плюс 2016 с 1909 (сборка 12026.20320) Monthly Channel до 1909 (сборка 12026.20334) - всё работает штатно.
Уточните, пожалуйста, версию и  номер сборки Вашего MS Office, а главное - канал подписки, с которым происходят такие сбои, как в сообщении 10.
Интересно было бы посмотреть и новую книгу с таким кодом, которая у Вас не компилируется.
Возможно, у Вас включена Программа предварительной оценки Office (Insider), с этой подпиской многое чего случается, т.к., по сути, это версия бета-тестирования.
 
Приятно, ZVI, что вы вникли в суть проблемы). Но это лишь заметка на этом форуме, потому что я исключил альтернативное декларирование в VBA ещё с момента выхода первых версий mso x64. Корни этой проблемы гораздо глубже, и вызвана отношением самой MS к своему детищу VBA. Я начинал с VB5, и использовал Excel, как источник данных с драйверами  MS, а все коды были в VB. По мере развития VBA, и эволюционирование  VB6 в VB.NET, я не стал эволюционировать))), а для MSO стал использовать VBA. Вот и начались проблемы одна интереснее другой. Я конечно понимаю, что VBA - облегченная версия VB6, но ее уж слишком "облегчили". Поэтому наработанные в vb шаблоны пришлось перерабатывать заново. Я определил для себя набор объектов и конструкций, которые нестабильно работают от компа к компу, от версии к версии. Эти объекты я просто не использую.
ZVI, согласитесь, что мои баги могут всплыть у другого пользователя, и вы не станете каждый раз узнавать номер сборки и подписку. И представьте, что ко мне станут регулярно обращаться наши сотрудники из офисов в Москве, Туле, Рязани, Твери... Я вам могу сказать абсолютно точно, что ПО (win + office), установленное одним и тем же админом, с одного и того же дистрибутива, на одних машинах работает стабильно, на других даёт сбои. Поэтому, изрядно намучившись, я просто исключил коды, которые могут вызвать сбои...
Если интересно могу поделиться своими наблюдениями в области взаимодействия Ribbon Fluent и VBA). В частности, о странной последовательности событий между onLoad и workbook_open))  
 
Как по мне, несколько голословно. Одни эмоции, дайте факты.
«Бритва Оккама» или «Принцип Калашникова»?
 
Цитата
despot69 написал:
посмотрите на скиншоты, вы не поняли о чем я пишу
Надеюсь, что понял. Если открыть книгу на любом компьютере с Excel 2016(64), добавить в нее модуль, отображенный в первой картинке #10, задать переменную условной компиляции
Код
VBA7 = 0
то при компиляции мы получим точно такую же "картинку", как в #10.
Владимир
 
Цитата
Ткач Александр написал: я просто исключил коды, которые могут вызвать сбои...
Александр, Ваше решение выстрадано и понятно, но мне интереснее попытаться понять причину, поэтому и попросил Вас уточнить номер версии, сборки и типа подписки MS Office, а также поделиться пустой книгой с кодом, который дает подобные сбои.
 
Скрытый текст
Уважаемый bedvit, в скриншоте как раз факты). А можно и   серьёзный баг, который выдаст ошибку на старте, и не даст дальше воспользоваться набором объектов. Напишите в макросе код для Reference через GUID для подключения библиотеки, которая по умолчанию не подключена к проекту (например библиотеку Access). Затем воспользуйтесь какими-либо обектами из этой библиотеки. Включите макрос в workbook_open. Сделайте это в MSO 2013, и попробуйте открыть файл на другом компе с  MSO 2016. Можно и наоборот из 2016 в 2013. Ошибки в обе стороны. Библиотека не подключится, как ни странно. Это о совместимости версий, и проскальзываниях в исполнении кода VBA. Таких грубых багов в VB  не было.
Уважаемый sokol92, вы совершенно правильно поняли, и абсолютно правы. Я сделаю небольшую ремарку.
Conditional Compilation Arguments предназначен, чтобы задать аргументы компиляции. Можно написать любое имя константы и присвоить значение (можно и несколько констант задать), например
Код
А=1:В="чужой":С=3.14

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

Посмотрите ссылку, так будет понятнее.

http://dailydoseofexcel.com/archives/2006/02/16/conditional-compilation-arguments/

Константы типа Vba7, Win64 определяются автоматически в зависимости от операционной системы и офиса.

 
Цитата
Ткач Александр написал:
Уважаемый bedvit, в скриншоте как раз факты).
Извините, это картинка, со всем уважением.
sokol92 Владимир, указал в каком из возможных случаях это может появляться.
Цитата
Ткач Александр написал:
Напишите в макросе код для Reference через GUID для подключения библиотеки, которая по умолчанию не подключена к проекту (например библиотеку Access). Затем воспользуйтесь какими-либо обектами из этой библиотеки. Включите макрос в workbook_open. Сделайте это в MSO 2013, и попробуйте открыть файл на другом компе с  MSO 2016. Можно и наоборот из 2016 в 2013. Ошибки в обе стороны. Библиотека не подключится, как ни странно. Это о совместимости версий, и проскальзываниях в исполнении кода VBA. Таких грубых багов в VB  не было.
Все так и сделал. Работает в разных сочетаниях Excel2010x64-Excel2013x64-Excel2016x64 на Win7x64.
Код
Код
Option Explicit

Private Sub Workbook_Open()
RUN
End Sub

Sub RUN() 'ЗАПУСКАЕМ ДЛЯ РАННЕГО СВЯЗЫВАНИЯ
On Error Resume Next 'в случаях, если забыли отключить в прошлые разы
ThisWorkbook.VBProject.References.AddFromGuid "{77D79CA3-15A0-4310-B8D8-0BCBE3F72D96}", 1, 0: Continue ' подключаем библу "BedvitCOM" в References - version(1.0) для раннего связывания (если библа уже подключена - On Error Resume Next)
End Sub

Sub Continue()
Dim I As BignumArithmeticInteger: Set I = New BignumArithmeticInteger 'Создаем массив целых больших чисел и арифметикой (класс)
I.Bignum(1) = "111" & String$(30, "1") 'добавляем число из 33 единиц в первое целое длинное число
I.Sum 1, 1, 1 'складываем  длинное число само с собой
Debug.Print I.Bignum(1) 'смотрим результат в первом числе
I.Clear 'освобождаем память для всего объекта I (число =0)
ThisWorkbook.VBProject.References.Remove ThisWorkbook.VBProject.References("BedvitCOM") 'отключаем библу в References
End Sub

Так же прилагаю файл.
Библиотека для References здесь
Изменено: bedvit - 16.10.2019 14:52:51 ((поправил комментарии к коду))
«Бритва Оккама» или «Принцип Калашникова»?
 
bedvit, Виталий, может в этом проблема?
Цитата
despot69 написал:
Win10 Pro x64
Не касаемо Excel и VBA, неоднократно натыкался на изменение поведения при переходе на Win10. При этом бывает что именно конкретная сборка win10 виновата и со следующим обновлением все уходит.
По вопросам из тем форума, личку не читаю.
 
Михаил, дома стоит win10 x64, не замечал проблем. Но соглашусь, что возможно есть такая проблематика. Тогда Интерпретатор VBA здесь не при чем. Или дайте факты )
«Бритва Оккама» или «Принцип Калашникова»?
 
Цитата
bedvit написал:
Или дайте факты )
Согласен, ибо проблема может быть в любой ячейке памяти и секторе винчестера конкретного ПК :-)
По вопросам из тем форума, личку не читаю.
 
Добрый день, уважаемые коллеги!
Хочется отметить профессиональный подход bedvit  :idea:!
После того, как я написал, подумал, что нужно будет код приложить для ссылок на библиотеки, чтобы его могли скопировать или повторить. Радостно, что этого делать не пришлось.
Однако проблема с библиотеками в файле access. Я не могу однозначно сейчас утверждать будет ли этот баг в excel, нужно проверить. Но это VBA, не С#, не Java. И ссылка адресована на библиотеку Microsoft Excel object library. При смене версии mso (между 13 и 16) после исполнения кода можно открыть Tools - > References и увидеть missing.
Access конечно не в теме форума, но если вы будете не против, я загружу этот проект, скорее всего в пятницу, запарка на работе. В проекте есть несколько моментов, которые могут быть интересны:
1. Модуль класса индикатор прогресса с формой.
2. Процедура перезаписи кода из кода  "на лету", с последующей перекомпиляцией.
3. Подробная информация по пользователю на базе API.
4. Строка adodb.connection с возможностью одновременной работы в обоих файлах access + excel, подобранная после многочисленных неудачных попыток работать в excel, не выходя из access, а также в real time обновлять данные в excel. В Excel находится набор сводных таблиц, подключенных к базе access.
 
Коллеги, разве столь важно какая сборка и версия WIN'10'7x64 и MSO'19'16'13x64? Когда в корпоративной сети сотни пользователей, да еще регионы, подобная нестабильность превращается в огромную головную боль. Поэтому для сетевых файлов мы конечно же не используем VBA. Платформо-сборочно-версионно зависимый язык не подходит для таких задач. Есть у MS C#, который поддерживается на порядок лучше. Точно также, как Access не может заменить SQL server. VBA больше подходит для моделирования интерфейса, а Access для моделирования БД. Можно конечно писать надстройки, автоматизировать исполнение определенных задач для персонального использования или небольшой группы. VBA прост в освоении, имеет достойный редактор кодов, доступен, и самодостаточен, поэтому у него есть и перспектива, и большая аудитория юзеров. Я же не принижаю язык, а стараюсь поделиться своим опытом в том, что не стоит использовать при написании кодов. О том, что будет устойчиво работать на практически любой сборке MSO в среде WIN10.
 
Ткач Александр, понимаете, дело в том, что:
1. Вы зашли в тему  "Восстановление связи с Ribbon", на форуме по Excel/VBA, и написали
Цитата
despot69 написал:
VBA  (в отличие от VB) не умеет правильно обрабатывать конструкцию типа
, и с другими обвинениями в неработоспособности/нестабильности, на что спецы по VBA, резонно попросили обосновать. Обоснования до сих пор нет.
2.
Цитата
Ткач Александр написал:
MS C#, который поддерживается на порядок лучше.
Простой пример можно?
3.Для каждой задачи есть свой оптимальный инструмент. На ваше замечание, что Шарп лучше, я могу ответить так "я могу написать продукт на плюсах, который будет на порядок быстрее, которому не нужен framework, даже windows не обязателен - это будет эффективнее и универсальнее, чем ваш Шарп" - есть чем возразить? :)
Изменено: bedvit - 16.10.2019 21:56:47
«Бритва Оккама» или «Принцип Калашникова»?
 
Александр, спасибо, что подняли данную тему о Ribbon.
В теме "Восстановление связи с Ribbon", Евгений (Автор темы) привел полезный код с решением, Вы его подправили – замечательно! Но указали, что в некоторых случаях у Вас  #If VBA7 не работает, что не совпадает с опытом участников форума и что вызвало интерес.  Но Вы ещё посоветовали в VBA Excel не использовать такой вариант применения операторов условной компиляции, что уже явно противоречит общепринятой практике и моей, в частности. При попытке уточнить проблему, ответов на мои конкретные вопросы получено не было, пример пустой книги с проблемой не приложен.  Ответы важны для наc, так, например, если Вы участвуете в 'Программе предварительной оценки Office (Insider)', то для меня это вполне себе объяснение (не протестированные до конца  версии, чего только там не бывает), но чтобы в будущем можно было бы объяснять подобные проблемы другим, мне хотелось бы узнать в какой версии и сборке проявились такие глюки. Это не важно Вам, но важно для меня.

Возможно, ответ по проблеме был в ответе Владимиру (Sokol92) в #10:
"Уважаемый sokol92, вы совершенно правильно поняли, и абсолютно правы"
То есть, ошибка была в Conditional Compilation Arguments? Уточните, пожалуйста.

Позже была обозначена совершенное иная проблема с программной установкой Reference, которую, наверное, разумнее было бы обсуждать в отдельной теме. Виталий (bedvit) показал, что при правильном кодировании всё работает, а так как примера с проблемой нет, то дальнейшее обсуждение пока не имеет смысла.

Затем обозначена еще одна проблема с References из одного приложения на другое, здесь понятны как причины, так и варианты решений (VBA не при чем, это известная и давно описанная особенность компилирования). Проблема уже обсуждалось на форуме, искать не буду, но могу еще раз кратко написать. Только, может, все же не станем такую полезную тему по Ribbon оттенять другими вопросами?
Изменено: ZVI - 16.10.2019 23:51:58
 
Добрый день.
Уважаемый bedvit , я не писал о неработоспособности, это явный перебор)). По поводу плюсов я конечно соглашусь, спорить бессмысленно  :D .
По поводу  C# можно привести простой пример разработки не только в Win, но и в Linux (MonoDevelop из Ubuntu Software Center, Visual Studio Code и т.д.). Я думаю вы сами об этом знаете, поэтому сравнение VBA и C# похожа на провокацию  :)  :)  :) .

Уважаемый ZVI, применение операторов #if... else я не советовал для декларирования API функций, потому что неоднократно сталкивался с багами. В иных случаях - пожалуйста. Но я использую другой подход, который на протяжении 12 лет показал самую высокую стабильность: отдельно коды для х32 и х64. Пользователь привык к тому, что подавляющее большинство дистрибутивов различных программ выложены в 2-х вариантах на сайтах разработчиков. Поэтому, когда я кому-то отправляю 2 файла, даже домохозяйка понимает какой нужно открыть)). А дополнительное программирование по замене типов данных переменных и declare  - дело 10-20-30 минут. И такой подход я считаю правильной и надежной практикой.
В  Conditional Compilation Arguments ошибок не было и быть не могло, потому что я не создавал пользовательские аргументы. Я не участвую в 'Программе предварительной оценки Office (Insider)'. Я постараюсь сегодня выложить файл (он на сервере, к которому сейчас у меня нет доступа), чтобы вы могли его посмотреть. Файл с данными, с моей лентой, поэтому сразу напишу вход, если вы разрешите запустить макросы при открытии:
  лог: разработчик (выбрать из списка)
  пар: 123654
Сразу сообщаю высылаю данные о системе.
Есть еще один баг. При запуске кода на Protect, а затем ThisWorkbook.SaveAs AccessMode:=xlShared изменения вступают в силу, но не сохраняются. При следующем открытии снова монопольный доступ, шара не сохраняется. Эти процедуры содержаться в модуле ЭтаКнига (ThisWorkbook for en MSO).
 
данные о системе
 
Высылаю ссылку на файл на google disk (править на 100 kB слишком долго, а пустой не вижу смысла отправлять):
https://drive.google.com/drive/folders/1AS5trm8jDqfkZbn9gdbApu833MJOUUun?usp=sharing

Данный файл является частью проекта по разработке пользовательского интерфейса управления строительными проектами для взаимодействия с 1С:ERP, Project online, SQL server, MSO Access + Excel

Уважаемый ZVI, ваше пожелание выполнено).
 
Вот еще один баг вспомнил.
Сообщение, которое изображено на картинке (Err №6) имеет два последствия:
1. переполнение кэша. Например вызванное слишком большим массивом данных, что просто лечится
2. поломка файла). А это уже совсем другое дело. Можно отключить VBA, удалить все коды, перезагрузить комп, но это не поможет. Каждый раз, когда файл будет загружаться, это сообщение будет появляться. Вы сейчас возможно скажите: при чем VBA? При том, что именно в VBA был скомпелирован и запущен код, который привел к необратимым последствиям поломки файла. Что-то сохранилось и вызывает ошибку.
Конечно, такое явление случается редко, но раз в пол года оно лично у меня случается). И причина этого не в кэше, а в неправильно написанном коде, который приводит к поломке.  Не в смысле самого языка а в способе написания, ведь можно по разному написать код для достижения одной и той же цели. А учитывая наследие прошлых версий начала 2000-х, таких способов достаточно много. MS закрытая система, и что происходит при компиляции неизвестно, и неизвестно какой мусор сохраняется. Как правильно заметил bedvit
Цитата
Интерпретатор VBA ...
потому что компиляция условная, скорее интерпритация и проверка
Изменено: Ткач Александр - 17.10.2019 14:52:05
Страницы: 1 2 3 След.
Наверх