Вопрос простой. Извиняюсь за тривиальность.
Dim a(10) As Integer
Dim c(10) As Integer
...
b = a() ' это присвоение работает (по крайней мере значение переменной b  в отладочном окне читаются как массив.
...
c() = b ' Это присваивание не работает. 

Прошу подсказать, как правильно упаковать массив в одну переменную, а затем снова распаковать в массив.

Необходимость в этом возникла из-за того, что есть несколько подпрограмм, которые запускаются событийно время от времени, и между ними необходимо передавать большой объем информации, причем не через параметры, а просто через глобальные переменные проекта. Сами глобальные переменные тоже имеют несколько наборов-контекстов, которые храняться в массиве типа Variant. В конкретный момент массив разворачивается в некий конкретный контекст по определенному индексу, и уже этот контекст передается одной из подпрограмм в виде конкретных переменных с конкретными значениями. Беда в том, что среди этих переменных есть и массивы. Чтобы все работало, желательно сделать рабочей схему хранения данных типа e(f,g)=h, где h - Variant, в том числе и массив с некоторой произвольной размерностью.
 

Правильно. Потому что а() - это не массив, а ссылка на массив. Переменная может хранить ссылку, переменной можно присвоить значение ссылки.


Тоже правильно - ссылке нельзя присвоить значение переменной.


Хотелось бы больше внятности в описании проблемы. Скажем, в виде максимально упрощенного кода.
Впрочем, из того что удалось понять, вылезает предложение получать абсолютные адреса (VarSeg, VarPTR) и именно их передавать - вне зависимости от типа контента адреса есть переменные типа LongInt. 

Если делается копия массива, то это значит, что делается копия всех его элементов! 

 может так 

Staruha, спасибо. Но не то. Все учавствующие в этом деле переменные образно-виртуальны, т.е данные в них формируются отдельно от конкретных worksheets, и ни на одном из них не храняться Это относится и к массивам (- они не в принципе не велики). Время их жизни - пока открыта рабочая книга.

Добавлено @ 21:25 
Akina, Спасибо.
Идея со ссылками при всей ее очевидности мне совсем не пришла в голову.
Это выход. Я еще помозгую. Если возникнут вопросы, буду задавать 

Добавлено @ 21:33 
Akina, нет букваря по VBA, подскажи пожалуйста, как правильно связать массив со ссылкой вместо моего c() = b 

А кнопка F1 есть? букварь лежит прямо под ней...


Это что - попытка задать тот же вопрос другими словами?  

F1 in Einglesh.
What should I search?
I therefore ask, that I can not take advantage of the information. 

НеуФазендник
Есть, по крайней мере, 2 варианта (хотя в действительности их больше).
1-й вариант

Посему присваиваем каждому элементу массива его значение в отдельности.
Для начала инициализируем массив a().

Потом работаем с массивами b() и c()


2-й вариант

В переменной типа Variant можно хранить (ссылку на) массив. (На это собственно указал Akina).
При этом остается возможность использовать обычную (для массивов) нотацию при обращении к отдельным элементам.

    

Это сообщение отредактировал(а) Aloha - 26.5.2006, 20:57

Только к отдельным элементам копии! (а не ссылки или указателя), что показывает след. пример
 

Aloha, спасибо. Второй вариант то - что искал. Первый не пройдет, т.к. не решена исходная задача - сохранить некий контекст переменных, в том числе и массивы в некотором массиве f(g,h) as variant, где g-номер контекста а h-условный номер некоторой переменной. К примеру 
f(1,0)= имя рабочего листа, которому принадлежит контекст номер 1
а
f(5,16)= к примеру array(10) of integer 'как раз наш массив a() для контекста номер 5

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

Теперь же, думаю, все реализуется по задумке! Спасибо! 

cardinal, спасибо за дополнение. Все понятно. 

Пожалуйста.   

НеуФазендник
Если все так сложно в твоем приложении, может быть имеет смысл создать некую объектную модель приложения. И использовать, например, при обращении к свойствам нотацию:

вместо
 

Aloha, я ,в общем, уверен, что так было бы правильнее сделать. Просто мешает этому мой консерватизм. Так уж вышло, что Excel как оболочку я узнал в тот момент, когда уже немного умел работать в Delphi и делал в дельфях не сложные базы данных.
Так вот почувствовав силу Excel я забыл про Delphi. Причина элементарна - она в простоте Excel. Здесь достаточно сложные вещи создаются и модифицируются с минимумом затрат времени. Сейчас не будем говорить об обратной стороне медали - она тоже есть. Тем не менее Excel очень подходящая среда для реализации новых идей именно на той стадии, пока концепция и логика только формируются, и все на ходу переделывается и меняется. Как только всё устаканиться - можно формулировать техзадание программисту и писать нормальное ЕХЕ приложение в любой другой среде.
Так вот по этой же причине я не леплю в Excele никаких форм. Рабочий лист Excel настолько напичкан всевозможными встроенными полезностями от формул с функциями до условного форматирования, что большинство не тривиальных задач решается вообще самим листом. Ну уж если не решается - берусь дописывать код. Но опять таки - никаких объектов не на листе ни в коде! В том числе и управляющих кнопок. Изменения любой ячейки листа прекрасно анализируются в Worksheet_Change. А смещение фокуса ввода через Worksheet_SelectionChange. А дальше могучий оператор IF решает все вопросы.
В моем коде все как у первоклассника в прописях. Никакого излишнего ООП. Чем проще код, тем он надежнее работает. Хотя, как видишь, коль тема поднята, иногда появляются нетривиальные структуры, где можно было бы и отступить от принципов. Но, поверь - тяжело