neznajkaПривет всем!
Мне иногда приходится (ну так надо!) создавать довольно громоздкие формы, содержащие в DataEnvironment много "повязаных (relation)" и "одиноких" таблиц. Вроде бы уже и привык, методику отработал - хоть и сложновато, но - работает прилично. Хотелось бы, все же упростить и разработать некий "более универсальный" подход для таких случаев.
Поэтому хочу спросить - если кто-нибудь сталкивался с чем-либо подобным, может у вас есть какая-нибудь "собственная" стратегия решения подобных вопросов? Поделитесь.
Заранее благодарен.

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

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

На форме можно легко вывести такой массив или строка+ "I" + строка

Плюсы:
1. Четко можно отследить указатели позиций, т.е нумерация строк
2. В случае редактирования можно сбрасывать или откатывать изменения (при многопользовательской работе разрешение конфликтов редактирования), если кто-то уже отредактировал ту же запись... Хотя в принципе перед началом редактирования конкретной строки можно ее попытаться залочить
3. Если массив, то не более 65000 записей
5. Универсализм подхода в других приложениях, если четко заранее написать библиотеку своих функций не привязываясь к структуре проекта

Минусы:
1. Для нормального выравнивания приходится пользоваться моноширинным шрифтом текста
2. В случае изменения логики бд приходится сопровождать и интерфейс работы формы
3. Память тратиться на хранение
4. Некоторая трудоемкость написания базовой библиотеки функций для такой работы

В общем где-то так

Igor Korolyov
Hi Copyright!

Не, ну конечно рисовать с нуля свой грид это круто, но нужно ли оно нынче...

Posted via ActualForum NNTP Server 1.1

Ну если стандарт дружественного к пользователю интерфейса сегодня не нужен то хочу заметить что коммерческий успех собственных разработок именно от этого в основном зависеть и будет

Естественно функционал тоже и ориентированность потребности заказчика и его пользователей

В общем глупый спор мы же все-таки о VFP говорим и о хорошем стиле программирования интерфейса

Ну а насчет того что с нуля, то это не так - просто GRID далеко не самый удобный способ работы с логически связанными данными (это когда много таблиц и они связаны например по индексу числовому), тем более что приведенный мной вариант решения опирается именно на стандартные обьекты интерфейса VFP

P.S Для примера могу привести Norton Commander ->Volcov commander -> Far Manager или вы утверждаете что проводник самая удобная форма для работы с файловой системой для пользователя???