Добрый день.
Ситуация такая у меня, забыл все:
При работе в одной из форм, при выполнении из нее процедуры, необходимо из нее открыть другую пустую форму ввода
с тремя полями
Номер, Кассир, Окно.
Ввести в эти поля данные и при нажатии ОК
передать эти введенные данные в процедуру выполняемую в первой форме?
и присвоить эти данные трем переменным в этой процедуре varNum, varKassir, varOkno/
Буду очень признателен за помощь.
Спасибо!

1. делается форма
2. открывается в режиме Диалога
3. при нажатии на Ок форма делается "скрывается"
4. далее в коде проверяются и используются значения из полей
примерно так

DoCmd.OpenForm "frmFilters", acNormal, , , , acDialog         If IsFormLoaded("frmFilters") Then '-- если да, то построить строку параметров              Set f = Forms("frmFilters")         '    Set rs = Forms("frmFilters").RecordsetClone         '    pparam = ""         '    If Not rs.EOF Then         '        rs.MoveLast: rs.MoveFirst         '        Do While Not rs.EOF         '            If Nz(rs.Fields("invno").value, 0) > 0 Then pparam = pparam & "," & rs.Fields("invno").value         '            rs.MoveNext         '        Loop         '    End If         '    pparam = Mid(pparam, 2)             If DCount("[invno]", "_filter_invno") > 0 Then                 pparam = "select invno from [_filter_invno]"                 mw = IIf(mw <> "", mw & " and nz(invno,0) in (" & pparam & ")", "WHERE nz(invno,0) in (" & pparam & ")")                 Me.capInvno.ForeColor = 16711680             Else                 MsgBox "В форме 'Фильтр' не найдено ни одного инвентарного номера!"             End If             If f.isOk <> 0 Then DoCmd.Close acForm, f.Name         End If

где наворочено?
там комменты.... ну не убрал... главное идея

да нееее, просто это классический варьянт, а у тебя - правильный ;)
я в аксессе уже давно не пишу чего-то серьезного
использую как - быстро наваять очередную приблуду :)

Так выходит, что мое направление правильное было. Даже про модальную форму??

В модуле формы ввода:

Public Event Closed(Number As String, Cashier As String, Window As String) Private Sub Form_Unload(Cancel As Integer)     RaiseEvent Closed(Me.txtNumber & vbNullString, Me.txtCashier & vbNullString, Me.txtWindow & vbNullString) End Sub

В модуле вызывающей формы:

Private WithEvents frmIn As Form_frmInput Private strNumber As String Private strCashier As String Private strWindow As String Private Sub btn1_Click()     With New Form_frmInput         Set frmIn = .Form         .Modal = True 'по желанию         .Visible = True     End With End Sub Private Sub frmIn_Closed(Number As String, Cashier As String, Window As String)     strNumber = Number     strCashier = Cashier     strWindow = Window 'Debug.Print strNumber, strCashier, strWindow          Set frmIn = Nothing End Sub

Не прокатит в моем случае.
Про InputBox-ы я знаю, но они не устраивают по ряду ключевых моментов.
по тем вводимым параметрам в формее ввода придется выводить три ИмпутБокса.
Но, учитывая уровень пользования и образованности юзеров кои предположительно будут юзать данную девайсу, это будет полный пипец.
В форме ввода присутствуют: поле Номер (тупо поле ввод, куда просто вбиваются 1-2 цифры), второе - это Группа переключателей (2 переключателя), в зависимости от выбора переключателя, включаются-выключаются два комбобокса. Один комбобокс имеет ограниченный, заранее забитый список. Другой чуть хитрее, кстати, если кто поможет с запросами типа Юнион, завтра залабаю здесь вопрос, как его организовать, т.к. данные в комбобоксе втором, берутся из объединенного запроса (строится по двум-пяти полям другого запроса на выборку), SQL уж и так не знал дуже гарно, а с годами и вообще забыл.
так вот, эта форма ввода была сделана таким образом для того, чобы юзеры просто выбирали то, что есть в комбобоксах (как результат, в отличии от инпутбоксов, это минимум ошибок и очепяток, ну и, что наиболее главное, быстрота ввода, получил комбобокс фокус, список вывалился, оператор выбрала нужный пункт, без ошибок и поехала к следующему комбо). В общем, идея такая. Но, как вот вытянуть эти данные из этих полей и комбо, и передать в первую форму, примерно уж вспоминаю, но, до сих пор не до пойму, где чего не так делаю.

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

делаю так:
1. из основной формы по клику на кнопку открываю форму для ввода дополнительных данных
(если форма для ввода допданных используется для запуска нескольких процедур через OpenArgs передаю дополнительные идентификационные данные)
2. после ввода доп данных по нажатию кнопочки "Посчитать" запускается необходимая процедура (нужная в зависимости от значения OpenArgs) (тут же перед запуском процедуры можно устроить проверку на правильность заполнения нужных полей)
3. Пока форма открыта с нее считываются необходимые данные и присваиваются переменным, либо используются напрямую как значение контрола
4. далее по коду Форма ввода доп данных закрывается
(ни глобальных переменных, ни скрытых форм)

Привет, парни. Спасибо, что откликнулись.
Вот, собственно код процедуры из первой формы…
(просьбо слишком не смеяться, мне главное понять что делать и как, а там подчищу да «подкрашу»)

в общем, по клику на кнопке запускается процедура:

Private Sub Кнопка16_Click()
Dim db As DAO.Database
Dim rs As DAO.Recordset
Dim rs2 As DAO.Recordset
‘ВОТ ЭТИМ, НИЖЕ, переменным и хотелось бы присовить значения из формы ввода.
Dim varNum, varKassir, varOkno, varGrup, varValuta As Variant
Set db = CurrentDb
Set rs = db.OpenRecordset("tbl_Docs", dbOpenDynaset)
Set rs2 = db.OpenRecordset("tbl_Registr", dbOpenDynaset)

‘ВОТ ЗДЕСЬ, была попытка сделать по правильному и красивому, вызываю вторую ‘форму, т.е. форму ввода (приаттачу к сообщению)… собственно это то, что и ‘обсуждается сейчас нами.
'DoCmd.OpenForm frm_InpotDan, acNormal, , , acFormAdd, acDialog(varNum, varKassir, varOkno, varGrup)

‘А ВОТ ТАК, было изначально, но это так же было сделано, мол, щас пусть так, потом ‘сделаю красиво. Но, импутбоксы не устраивают абсолютно, т.к. во-первых есть уже ‘списки, в кои вводить не надо и кои присутствуют в форме ввода, во-вторых, юзеры ‘имеют свойство ошибатсья при вводе…
‘Собственно, сами переменные, и кривой способ присвоить им значения.
varNum = InputBox("Введите номер документа!", "Ввод номера документа")
varKassir = InputBox("Введите ФИО кассира!", "Ввод нового кассира")
varValuta = IIf(Me.RubUsd.Value = "Рубли", "Рублям", "Валюте")


‘ну, а далее поехали добавлять в таблицу….
With rs
.AddNew
![ID] = Me.ID_DOC.Value
![Name] = "Оттиск штампа для папки кассовых документов"
![OKVKU] = Me.KKO.Value
![DateResive] = Me.DateResive.Value
![RubUsd] = Me.RubUsd.Value
![Num] = varNum
![Kassir] = varKassir
![Status] = "Документ отсутствует"
![Messeg] = "Отсутствует оттиск штампа для папки кассовых документов за " & Me.DateDoc.Value & " по " & varValuta & ", по кассиру: " & varKassir
![Isp] = True
.Update
End With

rs.Close

With rs2
.FindFirst "[ID_DOC] = '" & Me![ID_DOC] & "'"
.Edit
![Status] = "В обработке"
.Update
End With

rs2.Close
Set db = Nothing

Me.frm_Docs.Requery
End Sub

Ага, Дядя Федор, спасибо, буду разбираться.
Отдельное спасибо за пример!

Круто.
Разобраться жизни не хватит.
А как форму на открытость проверить. Бывает надо очень. Ну типа
if Forms!Форма.open=true then
...
else
...
end if

Во бин. Функция.
Спасибо.

Вот этот цикл:
While Not flag
DoEvents
Wend
бессмысленный, потому как перед ним форма открывается в режиме диалога,
при этом выполнение кода останавливается до момента сокрытия/закрытия формы.
Его можно смело выкидывать.

... Вот если не диалог, тогда...

Тогда этот цикл загрузит оба процессора на 50 % и процессор будет работать как утюг,
исключительно на выделение тепла.

... varNum = Forms![frm_InputDan]![Поле0].Value varKassir = Forms![frm_InputDan]![ctl_Kassir].Value varGrup = Forms![frm_InputDan]![ctl_Grup].Value

автор: Lukas (10.08.2010 в 17:10) .... А здесь нет проверки на "открытость" формы: ... При многократном обращении к мемберам объекта, следует создавать ссылку на объект, для ускорения работы кода.

Опять по граблям?

Мы обсуждаем способы передачи значений переменным в форме

Да. Именно поэтому мы обсуждаем недостатки/достоинства вариантов.

Мне НЕ нравится:
1. Когда класс вызываемой формы "ДОЛЖЕН" куда-то что-то "навязывать" (возвращать).
а. Этого "Куда-то" уже может и не быть. (обязательна проверка)
б. Этому "куда-то" возвращаемые "что-то" уже могут быть не интересны. (фиг проверишь)
Альтернатива: Генерировать события, возвращающие значения. Какому объекту интересно, тот подписался и слушает их.
2. Когда в классе вызываемой формы "жестко" прописана вызывающая форма.
а. Я, например, должен вызывать Вызываемую форму из нескольких вызывающих форм.
Как в этом случае определить, "кому" сейчас возвращать значения? Перебирать которая из них
открыта? Так все могут быть открыты, да еще и по нескольку раз нестандартными экземплярами.
б. Вызывающая форма открыта нестандартным экземпляром, тогда ссылки через коллекцию Forms будут давать ошибки.
Альтернативы: 1. см .п.1
2. При открытии "цеплять" ссылку на активную форму/контрол. (Формы-календари, калькуляторы и т.п.)

И все же передача через Property кажется мне предпочтительнее

Ну, как известно, публичная переменная, объявленная на уровне модуля, является его свойством.
Другое дело, что в процедуре свойств можно описать дополнительные проверки и прочая, так что в этом плане, конечно, процедуры свойств предпочтительнее, хотя и "тормознутее" просто переменных.