Page 1 of 2 12 LastLast
Results 1 to 15 of 23
  1. #1
    Join Date
    Jan 2004
    Posts
    77

    Unanswered: MsgBox with options

    I have QueryByForm with a command button that opens one of two application based on the values returned by the QBF. Currently I have a MsgBox vbYesNo code to open the proper application. However, rather than having the buttons read Yes/No Id wish them to read Option1/Option2. If I click Option1, the code branches accordingly. Rather than the vbYesNo, I tried having a separate form. But, when it opened the second form, it did not limit the data to the results of the QBF.

    Is it possible to have message box similar to Yes/No only where I could have the buttons read Option1/Option2?

    Thanks,
    SKK

  2. #2
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    theres nothing intrinsically different between a message box and an Access form...
    make sure the form is modal
    place what controls you need
    place your code as required

    and make sure you take backups before testing, and/or make sure you jave a proven form killer just in case your code bombs


    jobsagoodun
    I'd rather be riding on the Tiger 800 or the Norton

  3. #3
    Join Date
    Jan 2004
    Posts
    77
    Ahhh, the old modal trick. I think you got it. Let me try that and I'll let you know. I'm not much of a programer but I think I can do this.

    Thanks...

  4. #4
    Join Date
    Jan 2004
    Posts
    77
    Still having a problem. I've got the form created however, when it opens it does not limit the data to the result of the QBF (all records are available). How do I limit the second form to just those records selected via the QBF?

    Thanks,
    SKK

  5. #5
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    Make sure its record source is set to some SQL with criteria that refers to the QBF.

    theres nothing intrinsically different between a message box and an Access form
    Personally I would argue that there are some fundamental differences. The most glaring to me is that a custom form doesn't return a value, whereas a message box does.... easily.
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  6. #6
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    Quote Originally Posted by StarTrekker
    Make sure its record source is set to some SQL with criteria that refers to the QBF.


    Personally I would argue that there are some fundamental differences. The most glaring to me is that a custom form doesn't return a value, whereas a message box does.... easily.
    Ive never claimed they are identical
    however by delving into the code behind the form you return a value for use n the calling program. whetehr you do that in the forms close or on change events is up to you. effectively it acts like a message box, so in my boks its close enough for what the OP wants.

    semantically its not a message box, technically its not a message box, but in terms of system design and user interface its a message box in drag/camoflauge
    I'd rather be riding on the Tiger 800 or the Norton

  7. #7
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    Ive never claimed they are identical
    Yeah, I know, but words like "nothing intrinsically different" will be interpreted about 6973498723 ways by people out there, so I was just trying to elaborate a little
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  8. #8
    Join Date
    Oct 2003
    Posts
    103
    Is there any chance there is a sample (I haven't seen it in the code bank, but it may be there), of how to build/use this functionality? I had given up, but really want to use this. In effect, I want to be able to build my own inputbox if you will, or whatever.

    In some cases, I'd like to return a value if the form successfully completed a task on close, and other times, I might want to actually pass back data.
    I have a popcalendar function and form that I have no idea how it actually populates a field, but I might use the double-click event and say me.date=popcalendar. This will open the popcalendar form, and then return the date to the calling text box.

    Or similarly, and my immediate need that I don't know how to accomplish would be something like:
    pwchanged=false
    do
    pwchanged=frmPWCHANGE
    while pwchanged=false
    to force a user to change their password
    I don't know if my code is close, buy you'll get the idea.

    So, if there is a sample custom inputbox form or whatever, that would be very much appreciated.

    Thanks

  9. #9
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    you can push or pull values between forms and or reports
    so with a bit of careful design you can have a form which sets parameters, a form (say the switchboard which is always open which stores those paramters) and you can use those parameters in any form or report called from the switchboard

    the code that does the dirty deed is
    to "pull" values from an object
    thiscontrol.value = forms!mysourceobject!thatcontrol.value

    to "push" values to an object
    forms!mytargetobject!thiscontrol.value = thatcontrol.value

    by "pull" I mean the values exist on an object (almost certainly a form) and bring them into the current form
    by "push" I mean sendign values fromt he current form to another form or report

    you would use "push" to send new parameters to the switchboard/menu form
    yuou woudl use "pull" to retrieve those values in forms & reports.

    the advantage of having a parameter form is that you can insert common code, validate the parameters (so you know that the values on the switchboard/menu are valid)

    once the values are on say your switchboard you can use them in reports or forms or even queries


    for your example the problme is how you tell the popup which form has called it... so you know who to post the values back to. Have a look at the parameters you can set as part of the acopenform macro
    I'd rather be riding on the Tiger 800 or the Norton

  10. #10
    Join Date
    Oct 2003
    Posts
    103
    Quote Originally Posted by healdem
    you can push or pull values between forms and or reports
    so with a bit of careful design you can have a form which sets parameters, a form (say the switchboard which is always open which stores those paramters) and you can use those parameters in any form or report called from the switchboard

    the code that does the dirty deed is
    to "pull" values from an object
    thiscontrol.value = forms!mysourceobject!thatcontrol.value

    to "push" values to an object
    forms!mytargetobject!thiscontrol.value = thatcontrol.value

    by "pull" I mean the values exist on an object (almost certainly a form) and bring them into the current form
    by "push" I mean sendign values fromt he current form to another form or report

    you would use "push" to send new parameters to the switchboard/menu form
    yuou woudl use "pull" to retrieve those values in forms & reports.

    the advantage of having a parameter form is that you can insert common code, validate the parameters (so you know that the values on the switchboard/menu are valid)

    once the values are on say your switchboard you can use them in reports or forms or even queries


    for your example the problme is how you tell the popup which form has called it... so you know who to post the values back to. Have a look at the parameters you can set as part of the acopenform macro
    I have used objects on the switchboard in the past as a way to pass data back and forth, however I am trying to normalize my methods. And as you say, if I use one or two controls on the switchboard, how do I know which form has called it. I keep looking at the acopenform (docmd.open), openargs seems to be the only option available to me. If I am using creating multiple instances of forms, and I pass the calling form something like:
    stDocName = "Form4"
    DoCmd.OpenForm stDocName, , , stLinkCriteria, , , Me.hwnd

    Can I then do something like:
    me.openargs=me.text1 on an On-Close event?

    _______________________________
    Tried it, and that doesn't quite work, but I suspect you are hinting something along these lines, but I am just failing to pick up on it.

    If you can help the totally dense just a bit more, I'd appreciate it.

    Thanks
    Last edited by jdostie; 11-22-08 at 05:51.

  11. #11
    Join Date
    Oct 2003
    Posts
    103
    Still trying.

    On form 3 I have:
    Private Sub Command3_Click()
    On Error GoTo Err_Command3_Click
    MsgBox Me.hwnd

    Dim stDocName As String
    Dim stLinkCriteria As String

    stDocName = "Form4"
    DoCmd.OpenForm stDocName, , , stLinkCriteria, , , Me.hwnd

    Exit_Command3_Click:
    Exit Sub

    Err_Command3_Click:
    MsgBox Err.Description
    Resume Exit_Command3_Click

    End Sub

    On form 4 I have:
    Private Sub Command2_Click()
    'MsgBox OpenArgs
    Dim fm As Form_Form3
    fm.hwnd = OpenArgs
    fm.Text0 = Me.Text0
    End Sub

    I get object variable or with block variable not set.

    It seems like I have to be "this close."

    Can you please help?

    Thanks

  12. #12
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    I was thinking more of passing the form name, then posting the value back to that form.
    supply the calling form as the openargs
    parse that inside the called form to post back the value to the correct calling form. the downside is that you MUST change the form each and every time you add new modules
    the alternative is to consider creatign your own custom control in say VB and use that
    I'd rather be riding on the Tiger 800 or the Norton

  13. #13
    Join Date
    Oct 2003
    Posts
    103
    Quote Originally Posted by healdem
    the alternative is to consider creatign your own custom control in say VB and use that
    That's kind of what I had in mind. This because if we allow multiple instances of a form, using the form name (at least I don't think) will work. I'll have to try that I guess. But, the problem is I don't know how to create my own custom control to return the value . . . I though maybe using hwnd might be a good approach, but I can't figure that out either.

    For my immediate problem, I have found a work around, but I still keep coming up against this same question, and as Khan said "[it] tasks me."

  14. #14
    Join Date
    Oct 2003
    Posts
    103
    I think the lightbulb just finally went on. Although I have used a switchboard to pass data back and forth, I didn't think this would work because of the multiple instances of forms. BUT, having read a bit today, I think I get it.

    If we set modal to true, and popup to true on the calledform (let's call it frmCustomInput) then it will be the only form able to function until it is dealt with. So we could have:

    Private Sub frmCustomInput_Close() As Variant
    frmSwitchboard!PassValue=[value]
    End Sub

    And then on the calling form:
    private sub FillInTarget()
    docmd.open frmCustominput
    me.targetfield=frmSwitchboard!PassValue
    me.frmSwitchboard!PassValue=NULL
    End Sub

    Error Checking left out; strictly speaking, it may not be necessary to set frmSwitchBoard!PassValue back to NULL, but doing so consistently will allow said error-checking.

    Is this what you had in mind?

  15. #15
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    Regarding knowing what the form's name is that previously opened another form, perhaps this example with a CalPopUp form might help. It's one way of many but I found it works pretty well for me. When the CalPopUp form is opened via the "main" form, it passes the form name, subform name (if any), and the field name (to update) to text boxes on the CalPopUp form. When the "Save" button is clicked on the CalPopUp form, it then writes the calendar date into the calling form using the populated text boxes (ie. the text boxes named: FormName, SubFormName, and FieldName on the CalPopUp form) to know which form/field to update. Here's the example from the code bank:

    http://www.dbforums.com/showpost.php...8&postcount=28

    or

    http://www.dbforums.com/showpost.php...4&postcount=30
    Last edited by pkstormy; 11-23-08 at 00:01.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •