Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / FoxPro, Visual FoxPro Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8 9 10 .. 17   вперед  Ctrl
 Общие принципы построения приложения в FoxPro  [new]
sg12
Member

Откуда:
Сообщений: 454
Чтож, по просьбам откроем новую тему.

Сообщение было отредактировано: 27 янв 13, 13:52
25 янв 13, 19:50    [13830316]     Ответить | Цитировать Сообщить модератору
 Re: Общие принципы построения приложения в FoxPro  [new]
sg12
Member

Откуда:
Сообщений: 454
ВладимирМ
Объясните, пожалуйста, что вы имели ввиду под термином, вынесеным по вашей просьбе в заголовок темы?
25 янв 13, 19:54    [13830342]     Ответить | Цитировать Сообщить модератору
 Re: Общие принципы построения приложения в FoxPro  [new]
PaulWist
Member

Откуда:
Сообщений: 2236
sg12
Чтож, по просьбам откроем новую тему.
Sergey Ch, пожалуйста, снесите в старой теме все, начиная с моего провокационного поста.


Эту статью читали?
25 янв 13, 20:18    [13830440]     Ответить | Цитировать Сообщить модератору
 Re: Общие принципы построения приложения в FoxPro  [new]
ВладимирМ
Member

Откуда: г. Москва
Сообщений: 7864
Я имел в виду хотя бы общее представление о том, как приложение должно отображать/изменять данные. Интерфейс с пользователем, программная реализация этого интерфейса, хранение данных, способы обработки.

Обсуждение началось вот с этого

sg12
А здесь всего три процедуры "Добавить, Удалить, Изменить" в двух вариациях.

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

И ошибка была бы только в строке вызова, и то при неправильном синтаксисе.

Для начала примерно так:
LPARAMETERS tcCase
DOCASE
CASE tcCase == 'Add'
***
CASE tcCase == 'Delete'
***
CASE tcCase == 'Edit"
***
ENDCASE


Как Вы вообще представляете себе процесс модификации данных с использованием подобной процедуры? Пусть даже всего в одном проекте (приложении). Где, в каком месте, Вы будете вызывать этот код?

Вот пользователь открыл приложение. Очевидно, вызвал некую форму. Далее ему надо изменить существующую запись. Что надо сделать пользователю, чтобы это произошло? Каким образом действия пользователя приведут к использованию Вашего Do Case? Где в приложении место для подобного кода?
25 янв 13, 20:18    [13830442]     Ответить | Цитировать Сообщить модератору
 Re: Общие принципы построения приложения в FoxPro  [new]
sg12
Member

Откуда:
Сообщений: 454
PaulWist
Эту статью читали?


Читал.
Статья хорошая, но в ней допущены серьезные недоработки, к которым мы еще будем возвращаться. Поэтому я прошу ВладимираМ предъявить реальный пример.

ВладимирМ.
У нас есть родной фоксовский Проект. Он вполне работоспособен, фокс заточен на него, но на этом его преимущества заканчиваются.
Как вы думаете, что изменится, если из его главного модуля перенести процедуры добавления, удаления, редактирования, а также сохранения и восстановления в следующие процедуры объекта oTable, сменив строки их вызова:

Процедура DoEdit
LPARAMETERS tcCase
DOCASE
CASE tcCase == 'Add'
***
CASE tcCase == 'Delete'
***
CASE tcCase == 'Edit"
***
ENDCASE

Процедура DoSave
LPARAMETERS tcCase
DOCASE
CASE tcCase == 'Update'
***
CASE tcCase == 'Revert'
***
ENDCASE
25 янв 13, 20:41    [13830526]     Ответить | Цитировать Сообщить модератору
 Re: Общие принципы построения приложения в FoxPro  [new]
Dima T
Member

Откуда:
Сообщений: 15279
sg12
Как вы думаете, что изменится, если из его главного модуля перенести процедуры добавления, удаления, редактирования, а также сохранения и восстановления в следующие процедуры объекта oTable

Сместится точка возникновения ошибок. Ошибки будут происходить в этом коде. Сообщения об ошибках будут указывать на этот код и будет непонятно где реально ошибка.

И как в любом универсальном коде не обойтись без макроподстановок. Как следствие такой код будет тормозить, поэтому будет неприменим в тех случаях где критично время выполнения.

В остальном ничего не изменится.
25 янв 13, 21:03    [13830602]     Ответить | Цитировать Сообщить модератору
 Re: Общие принципы построения приложения в FoxPro  [new]
Dima T
Member

Откуда:
Сообщений: 15279
И потом сам предлагаемый шаблон изначально ущербный.
Например oTable.DoEdit('add') не сработает и ошибки не будет.
Если уж городить огород то делать oTable.Add()
25 янв 13, 21:22    [13830679]     Ответить | Цитировать Сообщить модератору
 Re: Общие принципы построения приложения в FoxPro  [new]
sg12
Member

Откуда:
Сообщений: 454
Dima T,

Нет, мы будем делать так и только так.
Эти коды отладим, один раз, и ошибки будут возникать только когда в эти процедуры будут передаваться неверные параметры.
Строка вызова увеличится только на один параметр.
И с макроподстановками разберемся, не надо преувеличивать.
А в тех немногих случаях когда критично, ничто не мешает вам в приложении использовать свои процедуры, и только когда в этом возникнет необходимость.

Что изменится? Главный модуль "похудеет" и станет менее "страшнее" на пять процедур, и это только начало.
А для работы с этими процедурами напишем объект класса CommandGroup с тремя кнопками, который будем навешивать на формы.
Или два класса - по 3 и 2, кому что по вкусу.
Т.е. избавим наши формы от необходимости чуть не в каждой писать индивидуально эти же процедуры, от которых рябит в глазах.
25 янв 13, 21:47    [13830738]     Ответить | Цитировать Сообщить модератору
 Re: Общие принципы построения приложения в FoxPro  [new]
sg12
Member

Откуда:
Сообщений: 454
Напишем еще одну процедуру DoNavigate:
LPARAMETERS tcCase
DOCASE
CASE tcCase == 'Top'
***
CASE tcCase == 'Bottom'
***
CASE tcCase == 'Prior'
***
CASE tcCase == 'Next'
***
ENDCASE

Перенесем туда существующие процедуры. Главный модуль похудеет аж на целый класс.
Создадим аналогичный объект класса CommandGroup с четырьмя кнопками, разрисуем их и еще один вопрос снят.
25 янв 13, 22:04    [13830790]     Ответить | Цитировать Сообщить модератору
 Re: Общие принципы построения приложения в FoxPro  [new]
Станислав С...кий
Guest
sg12,
Почитал Ваши рассуждения и не соглашусь с некоторыми из них.
1. Прежде всего, если исходить из понятия "таблица", как множества строк, то к таблице должны относиться только процедуры:

Update/Commit - фиксирование изменений
Revert/Rollback - откат изменений.

Процедцры Add - добавление строки и Delete - удаление строки должны относиться к классу записи/строки таблицы (oRow или oRecord)

Процедура Edit не может относиться к таблице: значения меняются не в абстрактной таблице, а в конкретной ячейке (на пересечнии конкретных столбца и строки). Поэтому процедура Edit должна относиться либо к классу поля (oField), либо к классу ячейки (oCell)...

Хотя нет, обманываю... Edit может быть у таблицы. Но она, по логике ООП, должна относиться не к редактированию записей, а к редактированию структуры таблицы (что-то типа alter table...). По той же логике Add должно создавать таблицу / копию таблицы, а Delete - удалять таблицу.

2. Чем выше уровень абстракции, тем труднее решать с его помощью некоторые практические задачи.
То есть, другими словами: что хорошо в теории не всегда выдерживает проверку практикой.

Мне на практике приходилось сопровождать систему (биллинговая система оператора связи), написанную на Alaska xBase (потомок Clipper'а) с высоким уровнем абстракции - на макроподстановках.
Да, она была компактна и, в чем-то даже изящна. Все ее программы ("скрипты") содержались в текстовых файлах. При работе программы из этих файлов читались строки и выполнялись через макроподстановку.
Все, что когда-то было отлажено - работало четко.
Но когда нужно было отладить новый алгоритм, тогда и начинались "пляски с бубном"... Синтаксические ошибки еще худо-бедно можно было отлавливать. А вот логические ошибки в макроподстановках искать - то еще удовольствие...
Примерно такое же, как отлаживать сложный SQL запрос, динамически формируемый на клиенте, при помощи SQLEXEC()...
25 янв 13, 23:06    [13831058]     Ответить | Цитировать Сообщить модератору
 Re: Общие принципы построения приложения в FoxPro  [new]
sg12
Member

Откуда:
Сообщений: 454
Станислав С...кий

Рассуждения ваши интересны, но пока будем делать так.
Пока мы просто перестраиваем существующие рабочие процедуры из родного фоксовского главного Проекта, сохраняя существующие функциональные возможности.
Подождем, пока наши главные гуру переварят написанное и пойдем дальше.
25 янв 13, 23:28    [13831162]     Ответить | Цитировать Сообщить модератору
 Re: Общие принципы построения приложения в FoxPro  [new]
Станислав С...кий
Guest
sg12
Напишем еще одну процедуру DoNavigate:
LPARAMETERS tcCase
DOCASE
CASE tcCase == 'Top'
***
CASE tcCase == 'Bottom'
***
CASE tcCase == 'Prior'
***
CASE tcCase == 'Next'
***
ENDCASE

Перенесем туда существующие процедуры. Главный модуль похудеет аж на целый класс.
Создадим аналогичный объект класса CommandGroup с четырьмя кнопками, разрисуем их и еще один вопрос снят.


Да ради бога... Сделайте себе набор классов, библиотеку... Кто запрещает-то? Хотите сделать что-то а ля Дельфийский Навигатор - нет проблем. Делайте...

Я сейчас работаю на промышленном предприятии. ИТ в ней не главное подразделение, но и не то, о которое можно ноги вытирать... Разработка учетной системы ведется собственными силами на VFP8+PostrgreSQL более 10 лет, очень высокая культура разработки ПО.
В начале разработки была создана библиотека классов, где стандартным компонентам FoxPro была добавлена нужная функциональность, а также разработаны новые компоненты.
Например, у всех компонентов библиотеки есть способность "привязываться" к месту на форме. Таким образом, внешний вид формы остается неизменным при ресайзинге. Все, что нужно сделать, это указать точку привязки, скажем, грида... И написать пару строчек в методах формы...
Как результат - никто из разработчиков не использует стандартные компоненты Фокса, только из "собственной" библиотеки...

К чему я это говорю? Да к тому, что всегда надо думать, стараться учитывать нюансы, продумывать развитие на несколько шагов вперед.
Если есть наработки - используй их для облегчения решения возникающих задач. Если нет - начинай коллекционировать решения... Свои или чужие... Главное, чтобы они полезными были....
И не важно: ООП ты используешь или без него обходишься... на Фоксе пишешь, на С# или на С(без плюсов)
25 янв 13, 23:47    [13831263]     Ответить | Цитировать Сообщить модератору
 Re: Общие принципы построения приложения в FoxPro  [new]
Станислав С...кий
Guest
Станислав С...кий
К чему я это говорю? Да к тому, что всегда надо думать, стараться учитывать нюансы, продумывать развитие на несколько шагов вперед.
Если есть наработки - используй их для облегчения решения возникающих задач. Если нет - начинай коллекционировать решения... Свои или чужие... Главное, чтобы они полезными были....
И не важно: ООП ты используешь или без него обходишься... на Фоксе пишешь, на С# или на С(без плюсов)

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

Хотя, чего это я тут основы программирования тут рассказываю....
25 янв 13, 23:56    [13831319]     Ответить | Цитировать Сообщить модератору
 Re: Общие принципы построения приложения в FoxPro  [new]
sg12
Member

Откуда:
Сообщений: 454
Станислав С...кий

Никто никому не мешает изобретать свой собственный велосипед. Только не надо свое творчество называть основами программирования.

Продолжим.
В том же объекте oTable создаем процедуры DoDatabase,DoTable,DoBuffer,DoIndex,DoFilter,DoSort,DoTransact.
И по той же вышеописанной схеме через DO CASE переносим из главного Проекта все процедуры, связанные с таблицами.
Останавливаться на этом подробно не будем - сейчас это не актуально, к ним можно будет вернуться позже.
И с ужасом замечаем, что наш "страшный" Главный Проект на глазах стремительно худеет.

Если вопросов нет, то можно перейти к более "страшному" объекту - oSetting.
26 янв 13, 10:11    [13832319]     Ответить | Цитировать Сообщить модератору
 Re: Общие принципы построения приложения в FoxPro  [new]
НеМогуПройтиМимо
Guest
sg12
И с ужасом замечаем, что наш "страшный" Главный Проект на глазах стремительно худеет.
ты че, придурок?
- "Главный Проект" не похудеет, ибо все в нем и останется
- exe тоже
ну идиот!
26 янв 13, 10:40    [13832357]     Ответить | Цитировать Сообщить модератору
 Re: Общие принципы построения приложения в FoxPro  [new]
Dima T
Member

Откуда:
Сообщений: 15279
sg12
Что изменится? Главный модуль "похудеет" и станет менее "страшнее" на пять процедур, и это только начало.
А для работы с этими процедурами напишем объект класса CommandGroup с тремя кнопками, который будем навешивать на формы.
Или два класса - по 3 и 2, кому что по вкусу.
Т.е. избавим наши формы от необходимости чуть не в каждой писать индивидуально эти же процедуры, от которых рябит в глазах.

Я с этого начинал десять лет назад. На сегодня для создания простого справочника мне достаточно написать одну строку в командном окне. Просто вызвать функцию создания форм справочника и передать ей имя таблицы
CreateSprForm('tovar')

Она создает и добавляет в текущий проект две формы: для просмотра и редактирования. Добавляет таблицу в DE формы, прописывет необходимые свойства формы и контролов, в форме просмотра прописывает грид (ставит таблицу источник данных, создает там одну колонку "Наименование", прописывает туда первое текстовое поле таблицы). В форме правки вытаскивает на форму все поля.
Дальше остается только орудовать мышкой распределяя контролы по форме и прописывать Caption.

Вот для примера сделал с нуля проект за 10 минут. Два справочника.
+ Тут весь код для создания
lcPath = 'C:\Test\Base\'
create table (lcPath + 'Tovar.dbf') free (nTovarId i autoinc, cTovar c(50), nGroupId i)
index on nTovarId tag nTovarId
index on cTovar tag cTovar
create table (lcPath + 'Group.dbf') free (nGroupId i autoinc, cGroup c(50))
index on nGroupId tag nGroupId 
index on cGroup tag cGroup 
close Databases all

CreateSprForm('Tovar')
CreateSprForm('Group')

На картинке скриншот того что получилось. Теперь о доступном функционале:
Все формы немодальные. Можно открыть несколько записей справочника на правку. Автоизменение размера шрифта в зависимости от разрешения экрана и возможность задать свой размер.
В форме с гридом все необходимое для работы без мыши: поиск по первым буквам, установка фильтра, "горячие" клавиши (Ins добавить, Del удалить и т.д.). В меню по правой кнопке мыши копирование в буфер обмена всего показанного в гриде.
В форме редактирования прописана буферизация на случай отмены изменений.

Еще раз подчеркиваю - не писал вообще ни одной строчки кода внутри форм.
Осталось написать код создания меню, start.prg из десятка строк и прога готова. Как-то так должно быть как мне кажется.

К сообщению приложен файл. Размер - 143Kb
26 янв 13, 10:58    [13832373]     Ответить | Цитировать Сообщить модератору
 Re: Общие принципы построения приложения в FoxPro  [new]
sg12
Member

Откуда:
Сообщений: 454
Dima T

В этот раз согласен.
Но даже не зная твоей проги, могу уверенно сказать, что она легко впишется в описываемый перестроенный главный модуль.
И при этом значительно упростится, так как часть ее функционала уже будет сидеть в нем.
К примеру кнопки - пара кнопок Сохранить и Отмена это стандартный объект на основе CommandGroup, пригодный куда угодно. Другую группу кнопок я уже описал.
Твой текстбокс с кнопкой "..." тоже выносится в базовые классы в виде контейнера и его не надо будет писать в каждой проге.
Автоизменение сам бог прописал решить универсально в классе на основе Custom, добавляемым в формы.
26 янв 13, 11:37    [13832440]     Ответить | Цитировать Сообщить модератору
 Re: Общие принципы построения приложения в FoxPro  [new]
sg12
Member

Откуда:
Сообщений: 454
Продолжим перестройку главного модуля VFP9.
В объект oSetting из него переносятся многочисленные процедуры, выполняемые при запуске и при закрытии программ.
Они группируются попарно - то, что открыто, по идее должно быть закрыто.

Структура этих процедур едина:
LPARAMETRS tcCase
DO CASE
CASE tcCase == 'Otkr"
* Выполняется при запуске
CASE tcCase == 'Zakr'
* Выполняется при выходе из программы.
ENDCASE

Примерный перечень этих процедур, при необходимости он дополняется:
DoGlobal,DoCheck,DoEnvironment,DoSystToolbars,DoProectWindow,DoScreen,DoSplash,DoTable,DoToolbar,DoMenu,DoForm
26 янв 13, 13:09    [13832635]     Ответить | Цитировать Сообщить модератору
 Re: Общие принципы построения приложения в FoxPro  [new]
PaulWist
Member

Откуда:
Сообщений: 2236
Dima T
Вот для примера сделал с нуля проект за 10 минут. Два справочника.
...
Все формы немодальные. Можно открыть несколько записей справочника на правку.
...


Вот с этого места по подробнее:

- что является базовым классом для пары форм ФормаСправочник-ФормаРедактирование, form или formset ?

- как пара ФормаСправочник-ФормаРедактирование связаны с данными, те 'эта пара разделят одну сессию данных или у каждой своя?

- как две пары ФормаСправочник-ФормаРедактирование и ФормаСправочникГруппа-ФормаРедактированиеГруппа возвращают значения в обратном порядке, поясню: открыли СправочникТовар - открыли СправочникРедактированияТовара через новую запись товара - открыли СправочникГрупп - открыли СправочникГрупп через создание новой группы,... закрыли форму СправочникГрупп (ведь формы не модальные) , вопрос - куда вернёт ФормаРедактированияГрупп новую запись группы?

Как это реализовано?
26 янв 13, 14:33    [13832867]     Ответить | Цитировать Сообщить модератору
 Re: Общие принципы построения приложения в FoxPro  [new]
reware
Member

Откуда: Хабаровск
Сообщений: 585
sg12
Чтож, по просьбам откроем новую тему.
Sergey Ch, пожалуйста, снесите в старой теме все, начиная с моего провокационного поста.

а что за старая тема (да фиг с ней) и об чём тут речь ? не, ежели чо, я Изю тудым пошлю, он всё принесёт.
26 янв 13, 15:05    [13832960]     Ответить | Цитировать Сообщить модератору
 Re: Общие принципы построения приложения в FoxPro  [new]
sg12
Member

Откуда:
Сообщений: 454
Закончим первый этап, а то похоже на сворачивание на базар.

Добавим объект oFoxObj.
В нем создадим процедуры DoForm,DoForms,DoToolbar,DoMenu,DoMenuShortcut, при необходимости можно добавить новые.
Перенесем в него соответствующие процедуры аналогично объекту oTable, к их отладке можно вернуться позже.
Взглянем на Главный проект, в нем осталось совсем немного и его "страшнота" куда-то подевалась.

Создадим шаблон приложения, назовем его "Test". В нем создадим дочерние объекты и из него отладим Новый Главный модуль.
Уберем в нем шереховатости, причешем, добавим функциональности.
И после отладки удивимся - шаблон-приложение почти пустой, но он прекрасно работает.

ВладимирМ, как видите, простая перестройка Главного модуля перечеркивает ваши основы построения goApp.
Вы в свое время спасовали перед этим вопросом и совместно с несколькими гуру создали взамен эту свою теорию создания альтернативного главного модуля в приложении.
Которую защищаете не всегда корректно и не только со мной.
И вреда от нее достаточно много.
26 янв 13, 17:48    [13833449]     Ответить | Цитировать Сообщить модератору
 Re: Общие принципы построения приложения в FoxPro  [new]
Dima T
Member

Откуда:
Сообщений: 15279
sg12
Dima T

В этот раз согласен.
Но даже не зная твоей проги, могу уверенно сказать, что она легко впишется в описываемый перестроенный главный модуль.
И при этом значительно упростится, так как часть ее функционала уже будет сидеть в нем.

Хочешь делать oTable - делай. Мое мнение он нафиг не нужен. Это что-то из серии когда с паскаля пересаживаются на Си и дефайнами прописывают замену сишных { } на паскальный BEGIN END. Только чтобы по привычке пользоваться BEGIN END в коде.
Кстати ты бы хоть просвятил что это за такой главный модуль. Я как-то пропустил где его обсуждали.

sg12
К примеру кнопки - пара кнопок Сохранить и Отмена это стандартный объект на основе CommandGroup, пригодный куда угодно. Другую группу кнопок я уже описал.

В фоксе все завязано на формах, поэтому рекомендую начинать с именно с построения своего класса формы. Сама пара кнопок "Сохранить и Отмена" без формы не используется, поэтому можешь конечно сделать их отдельно, но этим только разработку себе усложнишь. Часть кода в одном классе часть в другом, а используются всегда вместе. Да и две пары таких кнопок на одну форму тоже не потребуются.
sg12
Твой текстбокс с кнопкой "..." тоже выносится в базовые классы в виде контейнера и его не надо будет писать в каждой проге.

Он так и сделан как отдельный контрол с текстбоксом и кнопкой внутри.
sg12
Автоизменение сам бог прописал решить универсально в классе на основе Custom, добавляемым в формы.

Универсально не всегда удобно. Лично я это все прописал в классе формы.
Я предпочитаю укрупненные классы "ФормаПросмотр", "ФормаПравка" и т.д. у меня десяток классов форм на разные случаи.
26 янв 13, 19:40    [13833863]     Ответить | Цитировать Сообщить модератору
 Re: Общие принципы построения приложения в FoxPro  [new]
Dima T
Member

Откуда:
Сообщений: 15279
PaulWist
Dima T
Вот для примера сделал с нуля проект за 10 минут. Два справочника.
...
Все формы немодальные. Можно открыть несколько записей справочника на правку.
...


Вот с этого места по подробнее:

- что является базовым классом для пары форм ФормаСправочник-ФормаРедактирование, form или formset ?

Базовый класс "БазоваяФорма". От нее унаследованы ФормаСправочник, ФормаРедактирование и вообще все классы форм. Вобщем все построено на классе БазоваяФорма.
formset никогда не использую. Если честно так и не понял зачем он вообще нужен.

PaulWist
- как пара ФормаСправочник-ФормаРедактирование связаны с данными, те 'эта пара разделят одну сессию данных или у каждой своя?

У каждой формы своя.
Form.DataSession = 2 Private Data Session

PaulWist
- как две пары ФормаСправочник-ФормаРедактирование и ФормаСправочникГруппа-ФормаРедактированиеГруппа возвращают значения в обратном порядке, поясню: открыли СправочникТовар - открыли СправочникРедактированияТовара через новую запись товара - открыли СправочникГрупп - открыли СправочникГрупп через создание новой группы,... закрыли форму СправочникГрупп (ведь формы не модальные) , вопрос - куда вернёт ФормаРедактированияГрупп новую запись группы?

Как это реализовано?

После вызова дочерней формы ей передается ссылка контрол родительской формы куда вернуть фокус. По закрытию дочерней фокус возвращается на этот контрол родительской если она существует. Если родительской формы не существует - никуда не вернет.
В данном примере две ситуации:
1. ФормаСправочник вызывает ФормаРедактирование. Передается ссылка на форму ФормаСправочник. По закрытии вызывается метод ФормаСправочник куда передается ID записи которая была добавлена/исправлена. ФормаСправочник обновляется и текущая запись ставится на полученный ID, а фокус на грид.
2. Контрол ввода из справочника на ФормаРедактирование вызывает ФормаСправочник. Передается ссылка на Контрол ввода из справочника. По окончании выбора ФормаСправочник вызывает метод контрола передавая ID в параметрах. Дальше контрол сохраняет ID в таблицу, меняет отображаемый текст и устанавливает фокус на себя.

Я думаю уже понятно что длина цепочки ничем не ограничена. Можно открыть хоть сотню ФормаРедактирование одного справочника. ФормаСправочник тоже, но во избежания бардака ФормаСправочник у меня всегда одна для одного справочника.
26 янв 13, 20:06    [13833961]     Ответить | Цитировать Сообщить модератору
 Re: Общие принципы построения приложения в FoxPro  [new]
PaulWist
Member

Откуда:
Сообщений: 2236
Dima T
PaulWist
- как две пары ФормаСправочник-ФормаРедактирование и ФормаСправочникГруппа-ФормаРедактированиеГруппа возвращают значения в обратном порядке, поясню: открыли СправочникТовар - открыли СправочникРедактированияТовара через новую запись товара - открыли СправочникГрупп - открыли СправочникГрупп через создание новой группы,... закрыли форму СправочникГрупп (ведь формы не модальные) , вопрос - куда вернёт ФормаРедактированияГрупп новую запись группы?

Как это реализовано?

После вызова дочерней формы ей передается ссылка контрол родительской формы куда вернуть фокус. По закрытию дочерней фокус возвращается на этот контрол родительской если она существует. Если родительской формы не существует - никуда не вернет.
В данном примере две ситуации:
1. ФормаСправочник вызывает ФормаРедактирование. Передается ссылка на форму ФормаСправочник. По закрытии вызывается метод ФормаСправочник куда передается ID записи которая была добавлена/исправлена. ФормаСправочник обновляется и текущая запись ставится на полученный ID, а фокус на грид.
2. Контрол ввода из справочника на ФормаРедактирование вызывает ФормаСправочник. Передается ссылка на Контрол ввода из справочника. По окончании выбора ФормаСправочник вызывает метод контрола передавая ID в параметрах. Дальше контрол сохраняет ID в таблицу, меняет отображаемый текст и устанавливает фокус на себя.
...


Про базовые классы - ОК, понятно.

Про связку ФормаСправочник вызывает ФормаРедактирование ссылка на ФормаСправочник передаётся непосредственно форме ФормаРедактирование или через посредника МенеджерФорм, код схематично покажи?
26 янв 13, 20:24    [13834021]     Ответить | Цитировать Сообщить модератору
 Re: Общие принципы построения приложения в FoxPro  [new]
Dima T
Member

Откуда:
Сообщений: 15279
sg12
Закончим первый этап, а то похоже на сворачивание на базар.

Добавим объект oFoxObj.
В нем создадим процедуры DoForm,DoForms,DoToolbar,DoMenu,DoMenuShortcut, при необходимости можно добавить новые..

Простой вопрос: ты планируешь писать хэлп по результату своего творчества?

По сути ты замахнулся на создание новой среды разработки. А без описания она понятна только ее разработчику.
Все эти объекты это набор абстрактного кода, который очень не просто сходу понять непосвященному человеку.
Иногда даже сам не понимаешь почему на ровном месте что-то работать перестало после вроде бы незначительного изменения в конечном коде. Оказывается просто забыл про некоторые незначительные ограничение своих же классов.

Так что советую по минимуму отходить от штатных возможностей фокса. Выводить в классы то что действительно необходимо, а не все подряд. Хотя бы просто из уважения к тем кто будет сопровождать этот код после тебя.
26 янв 13, 20:30    [13834059]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8 9 10 .. 17   вперед  Ctrl
Все форумы / FoxPro, Visual FoxPro Ответить