Set "dialogue" mode after form opens with some code 1

[xhonzi]

Hi,
I have a generic form that I am opening and changing a bit in VBA code. That's all going well, but I would like to set the window to "dialogue" mode so that the rest of the code waits until the form is closed (the form is something of a msgbox).

Anyways, it looks like I can set .modal to yes in form view mode, but not .popup.

Another alternative is to modify the form before it opens, and then just open it with the acDialog option. But I get that "can't find form" error.

Any ideas?

 

[Eupher]

What changes are you making to your form in code that cannot be done when the form is opened in dialog mode?

Ken S.

 

[MajP]

You might be able to take advantage of the forms onopen event. That way you can call the form in dialog mode and halt code execution of the procedure that called the form to open. However, the on openevent of the form still executes.

Another way would be to call it in design view, modify it, save it, and then open in dialog. The issue there is that the modified form is saved. May be OK if everytime you open the dialog you reset the changed properties. Example

Public Sub modifyAndHalt()
  Dim str As String
  'open in design view hidden
  DoCmd.OpenForm "frmOne", acDesign, , , , acHidden
  'Modify the form
  With Forms("frmOne")
     .txtBx1.DefaultValue = """Modified value"""
     .txtBx1.FontBold = True
     .txtBx1.BackColor = vbBlue
     .Caption = "Modified Caption" & Now
  End With
  'save form
  DoCmd.Save acForm, "frmOne"
  DoCmd.Close acForm, "frmOne"
  'open in dialog and halt code execution
  DoCmd.OpenForm "frmOne", acNormal, , , , acDialog
  MsgBox "Form Close"
End Sub

 

[xhonzi]

Ken-
Nothing. It's just that once it's opened in dialogue mode, the code that opened it halts (which is what I want, sort of) until the new form is closed. So the code I have right after the "open form in dialogue mode" is the "modify opened form" code which can't execute as long as the form is open.

MajP-
I was barking up that tree (open in design, edit, and then goto form view) and then I gave up 'cause I couldn't get it to work just right. I was trying to go to form view from design (in code) as opposed to just saving, closing, and reopening. You've inspired me to try again. And yeah, I'll be making the changes everytime, so it's not a big deal.

-Xhonzi

 

[Eupher]

xhonzi,

I have used the design view (hidden) method proposed by MajP successfully in the past. As a general rule, though, I try to stay away from that unless absolutely necessary, mainly because design view is not available in an MDE file - so if I want to package my app as an MDE (highly desirable if you have users who are good at breaking things), I would have to come up with alternate strategies for anything that uses design tools.

What are the nature of the changes? Why not call them from some event on the popup form instead of the calling form?

Ken S.

 

[xhonzi]

Thanks for the warning Eupher, I just had everything working the way I wanted it.

The form is something like msgBox but I need more responses than yes, no, okay, cancel. So, the calling form is passing in the names of the buttons and then returning which one was pressed. Unless I passed a lot of junk in as opening arguments (which I could do), I thought (at first) that it seemed easier to make the modifications from the calling script (which is actually a module).

-Xhonzi

 

[MajP]

I agree with Eupher, as my original post suggested. If you do not like opening args this is the way I often do this.

In a module I use some global variables and a function to return the global.

Public Btn1Caption As String

Public Function getBtn1Caption()
  getBtn1Caption = Btn1Caption
End Function

in the calling form I set the value of the public variable Btn1Caption

In the pop forms on open I call the function

Private Sub Form_Open(Cancel As Integer)
  btn1.Caption = getBtn1Caption
End Sub

 

[MajP]

Also you might be interested in a little extension of that idea. Lets say you build a few different pop up forms:
"myFrmOKCancel", "myFrmYesNo", "myFrmYesNoCancel" and you want to be able to return a value from the form as a function

In a module you could build a function and some global variables

Public glblStrPrompt As String
Public glblMyMsgBoxReturn As Integer

Public Function myMsgBox(formName As String, strPrompt As String) As Variant
  glblStrPrompt = strPrompt
  DoCmd.OpenForm formName, , , , , acDialog
  myMsgBox = glblMyMsgBoxReturn
  'clean up if you want
  glblStrPrompt = ""
  glblMyMsgBoxReturn = 0
 
End Function

now my function lets me pick which type of my message box I want and I can provide it a prompt. The prompt gets assigned to a gobal variable.

Now in my pop up I use the on open event to set a text box to the glbPrompt

Private Sub Form_Open(Cancel As Integer)
  Me.txtBxPrompt = glblStrPrompt
End Sub

on the onclose event I set the glblMyMsgBoxReturn to some value

Private Sub Form_Close()
  if something then
    glblMyMsgBoxReturn = vbYes
  else
    glblMyMsgBoxReturn = vbNo
  end if
End Sub

now I can call my function like

x = myMsgBox("myFrmYesNo","Do you want to...")

The form opens with the prompt, code execution halts, and when it closes it returns a value based on a selection in the form.

As long as you use good coding practices and narrow your variable scope as much as possible, a few global variables are no problem. In this case they may things a lot easier, and a lot safer then opening up the form in design view.