Results 1 to 6 of 6
  1. #1
    Join Date
    Oct 2005
    Posts
    183

    Unanswered: afterupdate trigger

    Is there any way to get the afterupdate triggercode to be triggered when the inputbox is manipulated through code and not by user input?

    In my case I have 3 comboboxes, the options in the later two is dictated by the choice made in the first one.

    On some ocassions the form (FORMY) with these comboboxes is opened by another form FORMX, and the value for the first two comboboxes is set by code in FORMX.
    Yet the choices for the second combobox usually populated by the first combobox thrugh an afterupdate-trigger isn't populated. Apparently the afterupdate isn't trigger even though the first combox is actually updated.

    Code for FORMX button that opens FORMY
    Code:
        Dim valg As Integer
        
        valg = MsgBox("Test", vbYesNo)
        
        If valg = 6 Then
        
            DoCmd.OpenForm "md_frm_overfoersler", acNormal
            Forms![md_frm_overfoersler].box_teater = Prod_ny![txt_id].Value
            Forms![md_frm_overfoersler].box_forestilling = Prod_ny!Detalje!txt_id.Value
            
        Else
         
            DoCmd.OpenForm "md_frm_overfoersler", acNormal
            
        End If
    Combobox code in FORMY
    Code:
        Dim sql As String
        Dim kundeliste As String
        Dim knumre As QueryDef
        Dim krst As Recordset
        Dim curdb As Database
        
        Set curdb = CurrentDb()
        
        Set knumre = curdb.CreateQueryDef("")
        
        With knumre
           .sql = "SELECT kunde1, kunde2, kunde3, kunde4 FROM md_tbl_producent WHERE id = " & box_teater.Value
           Set krst = .OpenRecordset()
           krst.MoveFirst
        End With
        
        kundeliste = krst!kunde1 & ";" & krst!kunde2 & ";" & krst!kunde3 & ";" & krst!kunde4 & ";"
    
        box_forestilling.RowSourceType = "Table/Query"
        box_forestilling.RowSource = "SELECT Detaljeid, forestilling, fradato, tildato FROM md_vw_forestilling_detaljer WHERE producent = " & box_teater.Value
        box_forestilling.Requery
        box_forestilling.ColumnHeads = True
        box_forestilling.BoundColumn = 1
        box_forestilling.ColumnCount = 4
        box_forestilling.ColumnWidths = "0 cm;5 cm;2 cm;2 cm"
        
        box_kundenummer.RowSourceType = "Value list"
        box_kundenummer.RowSource = kundeliste
        box_kundenummer.Requery
        box_kundenummer.ColumnHeads = False
        box_kundenummer.BoundColumn = 1
        box_kundenummer.ColumnCount = 1
    Thanks for your time and suggestions...

    Flix
    IT squid: networks, servers, firewalls, routers and I dabble a little with SQL-server and Access as well....

  2. #2
    Join Date
    Dec 2002
    Location
    Préverenges, Switzerland
    Posts
    3,740
    form events are natively private
    (and i have never tried changing the event declaration to public - for the two seconds it takes, it might be a worthwhile experiment: pse let me know the result)

    most probable fix is to move all your _AfterUpdate() code out to a public sub in the same form and call the public sub from _AfterUpdate and from the other form.

    izy
    currently using SS 2008R2

  3. #3
    Join Date
    Sep 2003
    Location
    MI
    Posts
    3,713
    Quote Originally Posted by izyrider
    form events are natively private
    (and i have never tried changing the event declaration to public - for the two seconds it takes, it might be a worthwhile experiment: pse let me know the result)

    most probable fix is to move all your _AfterUpdate() code out to a public sub in the same form and call the public sub from _AfterUpdate and from the other form.

    izy
    You can Public them ... Works just fine. People have to know tho that with invoking the event proc that that event proc does it's dirty work on the form and control that it was written for NOT for the form and control they're currently on (unless they are one and the same) ...

    This does not apply to you Izy, you already know this ...
    Back to Access ... ADO is not the way to go for speed ...

  4. #4
    Join Date
    Apr 2004
    Location
    outside the rim
    Posts
    1,011
    You also don't need to make a Sub or Function Public to call it - you can call Private things explicitly (just make sure the Form is actually open). I would be warry of making things that are natively private (as izzy called it) become public - you start affecting scope and Access might get fouled up (more likely you or your future replacement will get fouled up).

    It's better to move the code to a public procedure and call it, but not required.

  5. #5
    Join Date
    Sep 2003
    Location
    MI
    Posts
    3,713
    Quote Originally Posted by tcace
    You also don't need to make a Sub or Function Public to call it - you can call Private things explicitly (just make sure the Form is actually open). I would be warry of making things that are natively private (as izzy called it) become public - you start affecting scope and Access might get fouled up (more likely you or your future replacement will get fouled up).

    It's better to move the code to a public procedure and call it, but not required.
    Not from another form Todd ... When private, ONLY functions and methods within the form may call/invoke other functions or methods within that same form.
    Back to Access ... ADO is not the way to go for speed ...

  6. #6
    Join Date
    Apr 2004
    Location
    outside the rim
    Posts
    1,011
    True enough - private means private.

Posting Permissions

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