В прежние времена, новой функциональности, представленной в этом «наборе обновлений» хватило бы на новую версию или уж как минимум на промежуточную, которая кладется в самостоятельную коробку, снабжается документаций и пр. Так что можно считать что с выходом Visual Studio Service Pack 3 (SP3) на рынке появился Visual FoxPro 6.5.
Что же там такого. Ну, как обычно исправление довольно большого числа ошибок самого Visual FoxPro. Исправление неправильно работчающего кода в примерах. Но это мелочи и ради них я не стал бы тратить ваше время.
Действительно серьезными изменениями является реализация раннего связывания объектов и многопоточность DLL, которые строятся средствами Visual FoxPro. Вот с них-то мы и начнем. Поддержка раннего связывания. Что было раньше, то есть сейчас. Вы работаете с ADO. Создаете объект Recordset, размещаете на форме объект Microsoft DataGrid 6.0 (OLEDB). И что. Да почти ничего. Основная проблема в том, что до момента запуска вашей формы Visual FoxPro не имеет ни малейшего представления о том, что за объекты используются его приложениями. Но когда форма запущена, дело уже сделано. Объект создан и попытка «прикрепить» к нему объект, оканчивается сообщением об ошибке. Это может быть не так уж страшно для данных, которые открываются только на чтение. В конце концов, Recordset можно разобрать и руками. Гораздо хуже дело обстоит при необходимости модификации и отслеживания редактирования данных. Короче говоря, куда как проще использовать стандартный курсор Visual FoxPro, наполнять его из Recordset и привязывать к обычному объекту Grid из числа базовых объектов. Но ведь это ненормально! Инструменты и технологии, разработанные одной и той же фирмой должны работать вместе, тем более что Microsoft постоянно заявляет о своей приверженности к компонентной модели приложений, когда собранная из кусочков система предстает как единое целое для пользователя. Вот и на. Кусочки есть, работы нет. По крайней мере не было до выхода SP3. Теперь мы можем сделать следующее (спасибо Мише Корнееву за пример):
Создаем форму. Помещаем на нее один из новых объектов Microsoft DataGrid 6.0 (OleDB) и в коде метода Init формы помещаем такой код:
LOCAL lo_ADOR
lo_ADOR=CREATEOBJ(‘ADODB.RecordSet’)
WITH lo_ADOR
.FIELDS.APPEND(«F1»,129,20)
.FIELDS.APPEND(«F2»,129,20)
.OPEN .AddNew
.FIELDS(‘F1’).VALUE=»Это просто»
.AddNew
.FIELDS(‘F2’).VALUE=»Работает»
ENDWITH
THIS.CONTROLS(1).DATASOURCE=lo_ADOR
Запустим форму и если все прошло как следует, мы получаем наш Recordset, привязанный к объекту DataGrid. Так решена динамическая привязка источника данных к объекту. Но это на этапе исполнения.
Что если нам нужно привязать Recordset на этапе проектирования формы, например, чтобы выполнить какие-то действия над DataGrid? В первую очередь необходимо получить ссылку на DataGrid. После того как мы поместили этот объект на форму нужно выполнить несколько шаманских пассов для получения желаемого результата. Тут я пользуюсь решением, предложенным Джоном Петерсеном: 1. Создаем в командном окне ADO Recordset.
*!* Для примера я использую стандартную базу Visual FoxPro и
*!* DSN по имени tastrade
*!* oConn = CreateObject(«adodb.connection»)
*!* oConn.Open(«tastrade»)
*!* ors = CreateObject(«adodb.recordset»)
*!* With ors
*!* .activeconnection = oconn
*!* .source = «Select * From Customer»
*!* .CursorLocation = 3
*!* .Open
*!* EndWith
*!* Важно, чтобы переменная, которая содержит ссылку на
*!* Recordset имела видимость Public.
*!* 2. Имея готовый объект Recordset создаем форму и помещаем на нее
*!* Microsoft DataGrid, Versin 6.0 (OLEDB).
*!* 3. Для получения ссылки на DataGrid помещаем курсор мыши на него,
*!* переходим в командное окно и исполняем команду:
*!* oGrid = Sys(1270)
*!* Теперь, когда у нас есть все необходимые ссылки можно выполнить привязку
*!* Recordset и DataGrid
*!* oGrid.DataSource = oRS
*!* 4. Тереь щелкните правой клавишей мыши на объекте DataGrid,
*!* в появивишемся меню выберите команду DataGrid Object, Clear Fields.
*!* Снова щелкните правой клавишей и выберите команду Retrieve Fields.
*!* Мы получаем список полей, из нашего источника данных.
*!* Во время исполнения нужно будет еще раз выполнить привязку
*!* источника данных, но мы уже определили все объекты Column
*!* в коллекции Columns объекта DataGrid.
Новости COM серверов. Много раз мне приходилось отвечать «Нет» на вопрос о том поддерживает ли Visual FoxPro истинную многопоточность. Теперь на этот вопрос можно ответить «Да». Хотя и с некоторыми оговорками. После того как вы установите SP3 на своем компьютере. В каталоге System32 появится еще одна динамическая библиотека с именем Vfp6t.dll. Это специальная библиотека поддержки исполненя (runtime library), предназначенная для работы COM серверов, выполненных в форме DLL. Основная задача этой библиотеки — поддерживать серверы, созданные для работы в среде Microsoft Transaction server. В отличие от стандартной библиотеки поддержки исполнения Vfp6r.DLL, новая библиотека более легкая и, как следствие, не поддерживает некоторые команды, полный перечень которых вы сможете найти в файле помощи Vfpsp3.chm, описывающем все нововведения.
В основном речь идет о командах, которые обеспечивают взаимодействие с пользователем. При этом, новая библиотека поддерживает многопоточность и многочисленные клиенты, желающие получить доступ к функциональности COM сервера не должны топтаться в очереди, ожидая когда будет выполнен текущий запрос. Согласитесь, что это обеспечивает гораздо лучшую производительность. Теперь, при создании DLL средствами Visual FoxPro, вам предлагается на выбор несколько вариантов сборки. В зависимости от выбранного варианта, ваша DLL получает метку, которая говорит ей, какую библиотеку поддержки исполнения следует искать при загрузке. Эта метка может быть изменена только при последующих сборках. Если вы собираете проекты из командной строки, то новая функциональность поддерживается новой командой:
BUILD MTDLL FileName FROM ProjectName
Кроме всего прочего, новая библиотека всегда существует в единственном экземпляре, тогда как существующая библиотека Vfp6r.DLL при определенных ситуациях копируется под новым именем, чтобы избежать блокировки от другого процесса, который уже использует ее в монопольном режиме. Для конфигурирования COM серверов теперь используется тот же самый Config.fpw, только он должен быть встроен внуть сервера. Это означает, что пользователь, на машине которого расположено несколько файлов конфигурации, не сможет испорить работу вашего сервера только потому что его файл конфигурации попался серверу первым.
