2 Hummer

кинь мне пустое мыло, я тебе пришлю в ответ готовый пример, а то твое мыло скрыто.

Есть у таблицы свойство Form! :) хоть это и звучит неправдаподобно для некоторых СПЕЦИАЛИСТОВ, но это уже не ко мне...
В редакторе свойств ты его не увидишь... :)

Зачем зря воздух гонять, я тебе готовый пример, ты сам же в форум и напишешь - есть там такое или нет, бред или небред (это для Лоха).

А предложения такого типа:

не есть самые оптимальные, потому как эти проперти персистентные, т.е. в базу пишуться, т.е. лишние телодвижения и задержки.

2 Лох

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

Ну не смеши ты людей ради бога. :)
А использовать форму вместо отчета полезно именно на динамических вещах. Можно, ясен пень создать один универсальный отчет, у которого полно полей с запасом. Но мой подход более визуальный.

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

У меня в одном учетном проекте было около 150 отчетов по всяким итогам, рейтингам и пр.пр.пр (это помимо приличного количества обычных отчетов, типа: накладная, прайсы, налоговая и еще несколько десятков). Причем, все такие отчеты по требованию заказчика должны были быть в двух вариантах - в печатном и в экранном (экранный отчет - это не предварительный просмотр :), это просто те же данные что и в отчете, но только в удобном именно для просматривания на экране виде).
Т.е. идя напрямую, мне пришлось бы ваять 300 шаблонов, а эт гемморой, особенно если вдруг надо общий стиль поменять всех отчетов по требованию заказчика.

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

Создаешь пустой подчиненный объект. Потом в рантайме этому объекту присваиваешь SourceObject =StoredProcedure.MyReport1 или View.MyReport2 и т.д.

Тут progist обмолвился: Табличные формы (вот откуда свойство таблицы Form) тоже удобно использовать для печати
Уже теплее. :) Весь прикол в том, что подчиненная талица, view, stored proc или просто подчиненная форма ведут себя одинаково! :)
И оттуда там и свойство Form у ЛЮБОГО подчиненного объекта - все как у подчиненной формы! Хотя саму подчиненную форму ваять не потребовалось - просто указываешь какой вью или proc. (И ваще, че я очевидное доказываю да еще и оскобления выслушиваю? Лень что ли просто самим взять да посмотреть? :) )

Конечно потом "ручками" ставить проперти и ширину каждого поля - это садомазохизм, когда у тебя 150+150 отчетов. Поэтому у меня есть пара таблиц с метадатами, куда я прописываю с помощью весьма простой служебной формы, что и как должно выглядеть. Все это множество отчетов разбивается на несколько групп по подобиям. Для каждой группы была сделана своя главная форма или главный отчет (всего у меня было 12+12, что гораздо интереснее, чем 150+150), и в метаданных все прописано - какой отчет (ВИРТУАЛЬНЫЙ ОТЧЕТ) в какой форме отображается, заголовок, столбцы и пр.пр.пр. После этого сваять новый подобный отчет для меня было равно по времени проектированию соотв. запроса или процедурки, и добавления пункта в меню или кнопки на форме. (А пожелания заказчиков сыпались как из рога изобилия, особенно когда он просек, что на новый отчет у меня уходит около 2-10 мин.)

По поводу использования форм в качестве шаблонов для отчета (и по поводу восклицаний на этот счет). Так вот, когда открываешь отчет на просмотр или ДАЖЕ на печать (2 ЛОХ), то ничего в СТРУКТУРЕ объекта поменять уже невозможно. :(
Поэтому я и использовал в некоторых случаях вместо шаблонов отчета формы, там где "дешевле" было все сделать динамически (это когда есть масса похожих по структуре отчетов).

Весь прикол в том, что от подчиненной таблицы, вьюшки, процедуры можно перехватывать все такие же события как от формы. Я, например, по просьбе заказчика выделял текущую строку целиком в режиме экранного отчета (всего одна строка кода на основной форме, которой ваще пофиг, что ИМЕННО за объект лежит в качестве подчиненного).

На всей этой ерунде сэкономил около 300 объектов проекта и не меньше месяца нуднейшей однообразной работы.

В принципе, Access позволяет вообще обходиться без полей на отчете. Просто в соответствующих событиях при печати или предварительном просмотре можно ВЕСЬ отчет нарисовать "ручками", как душе будет угодно :)
Баловался я этим хохмы ради, но реально использовал только частичное "дорисовывание" в некоторых отчетах - там где рисуемый элемент должен был по размеру располагаться на нескольких секциях данных сразу, в этом случае только "ручное" рисование и помогает.

2 ЛОХ

да, забыл
Синтаксис в студию

me.RepDetail.SourceObject="View.View1" ' или "StoredProcedure.StoredProcedure1"
with me.RepDetail.Form
...
end with

2 ЛОХ
Блин, случай упорного взаимного непонимания (сквозь все топики).

ЛОХ: Вопрос был (для тупых процитирую)
"Как задать размер колонок в таблице, через VBA?"

Самый первый мой ответ:

Попроще. У открытой таблицы есть свойство - Form.

Короче. Создаешь форму для печати (именно форму) И готовишь макет так, как если бы готовил отчет.

В ней - встроенную форму, у которой в рантайме Form_Load ставишь SourceObject ="Table.Table1"

Далее, у этого подчиненного объекта есть свойство Form. Через него дотягиваешься до столбцов и ставишь ширину. Заодно можно и цвета поменять и еще все что хошь у таблицы поменять.
Тут же переводишь эту же форму в режим предварительного просмотра.
Все.

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

Далее:

ЛОХ: ну один раз предложили ему печатать отчет, он отказался (случаи разные бывают). Так зачем ему форму предлагать? Ниче не понимаю

Когда открываешь отчет с подчиненной таблицей, то уже нет возможности "играть" колонками этой подчиненной таблицы, поэтому предложил форму (и причину эту уже указывал).

Далее:

ЛОХ: (ColumnWidth и всех делов-то). Но специально для этого формы плодить - увольте

А если он захочет потом перевести базу на ADP?
Прикол в том, что такая форма может быть только одна, и можно создавать по new ее экземпляры под какое угодно количество тейблов. Т.е. она (эта единственная форма) служит именно для целей "Как задать размер колонок в таблице, через VBA?", типа способ такой, типа хелпер.


Я ж те грю - я здесь чел новый, как ИМЕННО надо отвечать - не знаю, поэтому отвечаю в том духе, в котором спрашивают. Спросил бы автор топика сказал "напишите мне код" - написал бы код, спросил в духе "а как?", я ответил в духе "А вот примерно так!".

А че ты к последнему моему посту прицепился - ваще загадка. Народ стал делиться как и что он делает по этой теме, ну и я поделился. Кому-то это может оказаться полезным, многие мои знакомые используют похожие приемы.

И ваще, у меня к личности ЛОХ разгорается нездоровый интерес, надыть пересечься как-нить или водки попить или морды побить, в целях устранения взаимонепонимания. :)

Дабы навести последний блеск в выяснении отношений:

hummer

Ага, далее из текста вытекает, что свойство Form есть у StoredProcedure, у View:) Вот такие вот чудеса на виражах:)
Это свойство принадлежит именно ПУСТОМУ ПОДЧИНЁННОМУ ОБЪЕКТУ, то есть контейнеру, которому ты присваиваешь SourseObject, то есть источник, но это свойство никак не источника. Вот, собственно и всё, что хотел сказать.

Ну, мое стремление к лаконичности в первом посте сослужило мне плохую службу :)

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

Теперь корректно? :)