В HELP по Команда CREATE VIEW написано, что она сохраняет следующие настройки среды окружения

VFP9 Create View
Все файлы таблиц, индексов, альтернативные файлы и файлы формата, открытые на данный момент во всех рабочих областях
Все поля, включенные в список SET FIELDS
Все отношения, установленные между открытыми таблицами
Все фильтры, действующие для открытых таблиц
Установки DEFAULT и PATH
Установка файла процедуры
Текущий файл справки
Текущий файл ресурсов
Статус SET SKIP
Статус строки состояния (ON или OFF)

Вообще-то, идея сохранения среды окружения (CREATE VIEW / SET VIEW) заключалась в том, что в FP2.x было ограниченное количество одновременно открытых рабочих областей. Поэтому была настоятельная необходимость закрывать не использующиеся в данный момент рабочие области, чтобы высвобоить место. Но спустя некоторое время, надо было вернуться к "забытому" состоянию.

В Visual FoxPro такой проблемы нет. Есть другая потребность - разделить "среды" работы разных форм. Для этой цели используется Private DataSession. Так что, строго говоря, нет необходимости сохранять/восстанавливать среду данных. Просто каждая форма работает как бы в своем "сеансе данных" практически не влияя на работу других форм.

Впрочем, можно использовать класс DataEnvironment или Session для настройки нужной среды данных.

АлексейОвместо буфферизации курсорадаптер ?
в моем случае многовато переделывать
а так чтобы буфферизацию оставить и сохранение/восстановление работало?
Ну, напиши класс-обертку над твоим Create View / SET View в котором через AUSED() получаешь список открытых таблиц и сканиря их через CursorGetProp() получаешь факт буферизации. Сохраняешь эту информацию в глобальном массиве (или в свойствах класса-обертки) и при восстановлении среды выполняешь обратные действия через CursorSetProp()

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

АлексейОпри выполнение set view to Run_object
получаю диалоговое окно "Open Table"
укажу или не укажу какуюто таблиц - выполнение продолжается и вообщемто результат достигается, но иключить этот диалог неудается

с чем может быть связан вывод этого диалога?

как бы заглянуть внуть команды и узнать какую вдруг таблицу её потребовалось?
c xtv 'nj
Для начала, можешь попробовать открыть файл Run_object.VUE любым низкоуровневым редактором. FAR, Norton Commander, Disco-Commander и т.п. Можно даже блокнотом или напрямую в Foxpro


Имена таблиц там написаны прямо, без какого-либо шифрования.

Иногда, открытие диалога Open Table сопровождается указанием имени того файла, который надо найти. Либо в заголовоке диалога, либо в окне имени выбранного файла.

Можно еще попробовать сделать настройку


И отлавливать сообщение об ошибке. Но, не уверен, что для SET VIEW эта настройка поддерживается. По крайней мере в HELP нет упоминания.

А вообще-то, поскольку Вы занимаетесь "антиквариатом", то придется искать собственные способы, чтобы справляться с самыми разными глюками, которые снова и снова будут появляться. По большому счету, Вы зря тратите время. Просто нет никакого смысла в том, что Вы делаете.

Можете хотя бы самому себе объяснить зачем? Какую задачу Вы хотите решить, при помощи сохранения среды окружения? Нельзя ли эту же самую задачу решить другими способами?

АлексейОгрубо говоря: при запуске неродного програмного кода из ядра мне надо востановить сохранить и восстановить по возврату свое окружение.
Почему не сделать это "ядро" напрямую? В лоб. Прямыми командами открытия и настройки нужных таблиц. Ну, так прямо и писать


По мере необходимости, модифицировать процедуру загрузки "ядра". В этом случае, процесс формирования и загрузки "ядра" будет управляемым, нагядным и очевидным.

В используемом Вами варианте, Вам надо сначала вручную настроить ядро, потом только формировать файл VUE. И есть риск чего-то не заметить.


Еще раз напомню о классе DataEnvironment. Можно просто "накидать" в него нужные таблицы, настроить связи и режим буферизации, а потом просто в нужной DataSession создавать экземпляр этого класса. Правда, "накидывать" придется через дополнительные классы Cursor или CursorAdapter.

Если лень возится с классом DataEnvironment, можно сделать невидимую форму. В ее DataEnvironment настроить нужное окружение, а потом просто запускать эту форму. Если установить AutoClose = .F., то после закрытия этой формы настроенная среда окружения останется "как есть".

Зачем Вы используете явно устаревший и слабо-контролируемый инструмент, когда есть более простые, наглядные и лучше управляемые способы?

АлексейО ВладимирМПочему не сделать это "ядро" напрямую? В лоб.
потому, что возможны варианты вызовов ядровых функций из прикладных программ которые вызваны из других прикладных программ. т.е. мне надо не только сохранить ядровое окружение но и то окружение что настроили себе каждая из этих прикладных форм или программ.

Возможно, я что-то не понимаю.

Как правило, логика работы примерно такая

- Настройка среды окружения
- Выполнение действий в этом окружении
- Восстановление среды окружения в состояние до настройки

- Настройка среды окружения
- Выполнение действий в этом окружении
- Восстановление среды окружения в состояние до настройки

По-умолчанию, это стандартная логика работы DataEnvironment формы. Т.е. форма (вызываемая по DO FORM) настраивает среду перед своим открытием и, по возможности, приводит ее в исходное состояние перед своим закрытием. Ничего специально вообще делать не надо.

Если форма открывается в Private DataSession (это свойство формы), то одна форма вообще никак не влияет на среду окружения другой формы.

Предположим, Вам надо настроить среду окружения не для формы, а для выполнения неких программных действий. На языке программирования "действия" - это процедуры и методы. Так какая разница, как именно я настрою среду окружения командой set view to или вызовом процедуры DO MySet.prg?

Почему для Вас одна команда настолько сильно отличается от, тоже одной команды, но которая внутри себя выполняет несколько команд? Только потому, что последовательность команд "зашифрованная" в set view была создана разработчиками FoxPro, а процедуру надо писать самому?

Чем принципиально SET VIEW отличается от DO MyProg.prg ?

Один из принципов программирования вообще и ООП в частности - это принцип "черного ящика". Объект (процедура) "не знает" какие есть настройки во-вне этого объекта, но и внешние объекты "не знают" какие есть настройки внутри этого объекта.

Другими словами, выполняя настройку среды окружения, ВСЕГДА желательно исходить из предположения, что не было выполнени НИКАКИХ настроек во вне. Как минимум, следует убедится в наличие или отсутствии этих настроек. Это значит, что в общем случае, процедура настройки среды окружения выглядит примерно так:

Если не открыта таблица 1, то открываем ее. Если уже открыта, то пропускаем процедуру открытия
Выполняем настройки таблицы 1 (фильтры, индексы, связи, буферизация)

Таблица 2

Таблица 3

...

Ваш пример - это расчет на "честное слово". Это работает, если ты сам, один, разрабатываешь приложение. Точно знаешь, что вот эта настройка будет обязательно, а вот это надо настроить. Или же есть "некто", кто следит за разработкой различных модулей приложения и увязывает их в единое целое. Менеджер проекта.

С другой стороны, а кто мешает писать процедуры настройки среды окружения, исходя из предположения, что часть уже настроена раньше?

Кстати, с формами (DO FORM) работать пробовал? Не смотрел, что происходит со средой окружения, если в DataEnvironment включены таблицы?

АлексейОcreate/SET VIEW сохранить и восстановит любой набор открытых баз/таблиц, а DO MyProg.prg только тот набор что я прописал
А откуда появился этот самый набор открытых баз/таблиц? Разве не ты сам его открыл? Ну, или разработчик соответствующего модуля?

Разница только в способе, но не в сути.


Вообще, прежде чем спрашивать, попробуйте "примерить" ситуацию, ну, хотя бы на процедурое программирование (оно проще в понимании). Разве нельзя сделать все то, что Вы описываете процедурами?