Взаимосвзь между интерфейсами

[n0where]

Доброе время суток.
Есть такой вопрос:
Есть интерфейс 1, в котором прописана временная таблица. Хочу сделать объект быстрого выбора поля этой таблицы. Объект быстрого выбора (как я понял) можно сделать только в другом интерфейсе 2, в котором эта таблица отсутствует (не заполнена). Можно ли как-то получить данные этой временной таблицы из интерфейса 1 в интерфейс 2? либо объект быстрого выбора сделать в 1 интерфейсе?

[n0where]

Вопрос снят. Если временную таблицу не объявить local то она ко всем интерфейсам приминима.

[mwoland]

я всегда делал так:

Код: Выделить всё

table struct tt (
  fld1: string
);
interface ifc1;
  create view as select * from tt;
  handleevent
    cminit: {
       insert tt set tt.fld1 := 'asdf';
       mtChangeRefCount(#tt,1)
    }
  end;
end.
interface ifc2;
  create view as select * from tt;
  browse br1;
    table tt;
    fields
      tt.fld1 'fld1': protect;
    end;
  end;
end.

мб я и не прав

[n0where]

В моём случае mtChangeRefCount(#tt,1) делать и не понадобилось. все так отработало.

Но теперь новый горизонты.
Ситуация 1.
Когда в одном vip файле прописаны все фейсы типа

Код: Выделить всё

table struct temptable (
...
);
interface 1
...
end.
interface 2
...
end.

Все работает. таблица видна всем.

Ситуация 2.
Есть 2 vip файла, откомпилированные отдельно

Код: Выделить всё

// vip1
table struct temptable (
...
);
interface 1
...
end.

Код: Выделить всё

// vip2
table struct temptable (
...
);
interface 2
...
end.

Тут уже не работает.
Ставил и так

Код: Выделить всё

  mtChangeRefCount( #temptable,  1 );
  RunInterface('interface 2');
  mtChangeRefCount( #temptable, -1 );

В чем может быть проблема? или что нужно сделать чтобы работало.
Ограничений на таблицу temptable нет, прописана в файлах одинаково.

Для реализации возможности сохранения экземпляра данных в таблице в памяти после закрытия последнего интерфейса, использующего эту таблицу в памяти, используется метод логической таблицы mtChangeRefCount.
Если необходимо, чтобы информация автоматически скачивалась в момент открытия таблицы в памяти, то в дополнении к fmMemory указывается еще один режим открытия fmAutoLoad.
Если программист хочет перечитать заново данные в таблице в памяти, он должен вызвать метод Retrieve этой таблицы.
Если таблица открыта стандартным образом, то существует возможность динамически включить режим работы в памяти. Аналогично, если таблица открыта в памяти, этот режим можно выключить. Это достигается путем применения функции ReinitTable.
Если программист хочет, чтобы при модификации данные сразу попадали на диск, при открытии таблицы необходимо указать дополнительный режим fmWriteThru. При этом флаги модифицированности записей не выставляются. При выполнении операций update и delete происходит проверка пассивных блокировок.
Если программист желает, чтобы при закрытии таблицы изменения автоматически были отражены в БД, при открытии таблицы следует указать дополнительный режим fmAutoFlush. В данном случае изменения будут внедряться с применением транзакции. Следует заметить, однако, что тут программист лишается возможности обработать ошибки, которые могут возникнуть при внедрении изменений.

Использовал ReinitTable с fmMemory и fmAutoLoad - результата нет

[RAJAH]

Может быть, имеет смысл описать проект prj, а уже туда инклюдить файл с описанием таблицы, файл с vip1, файл с vip2?

[n0where]

Смысла нет, ибо это получается ситуация 1.

Необходимо разделить ресурсниками эти файлы, т.к. 2 интерфейс планируется использовать в 10 других проектов. И все их сводить в 1 нет желания

[RAJAH]

Сделайте 10 проектов и в каждый включайте файл описания таблицы. Я так сальдо считаю: написал интерфейс, который считает и сбрасывает результаты в ТП, и использую его в разных проектах, не забывая в *.prj указывать #include <<ТП>>.vpp.

[n0where]

RAJAH
Чем ваше предложение отличается от ситуации 2?

Собственно с этим у меня и проблемы. 2 интерфейс не видит данные в таблице.

[RAJAH]

Чем ваше предложение отличается от ситуации 2?

Тем, что таблица "принадлежит" проекту, а не интерфейсу.

[edward_K]

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

[n0where]

Тем, что таблица "принадлежит" проекту, а не интерфейсу.

В ситуации 2 таблица принадлежит не фейсу. (Да и вообще компилю через Viper - там нет проектов prj у меня)

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

Тогда имеет смысл делать объект, а не интерфейс. Но хотелось бы все же с интерфейсом. Так проще.