• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1458
  • Last Modified:

How to populate unbound controls on a continuous form in Access 2007

I have a continuous form bound to a non-updatable recordset.  Let's assume for a moment that there's a really good reason for that and there's no easy way to either make the recordset updatable or to bind the form to a temp table.

I want to make two of the textbox controls on this form unbound, but assign them a value from the underlying form record source as they are displayed.  Since they are unbound I'll be able to edit values in these textboxes and use textbox events to execute some SQL to update the real values in the underlying tables.

I've been trying to make this assignment in the OnPaint event of the detail section of my form and this does in fact work, but generates huge flicker because I'm guessing the assignments are causing other paint events to get fired.  Anyone have experience trying to do what I'm trying to do and have any suggestions?  I tried setting a module level variable with the record key and only letting the OnPaint event update the values once per record but this seems to have no effect (see the code section for my OnPaint event.
Private Sub Detail_Paint()
    'On Error Resume Next
    
    If mlngSplitID <> Me.SplitID Then
        Me.tbSplitAmount = Me.SplitAmount.Value
        Me.tbOfficeCode = Me.OfficeCode.Value
        mlngSplitID = Me.SplitID
    
        If Me.SplitError = -1 Then
            Me.tbSplitAmount.BackColor = vbRed
        Else
            Me.tbSplitAmount.BackColor = vbWhite
        End If
    End If
End Sub

Open in new window

0
kmslogic
Asked:
kmslogic
  • 5
  • 2
  • 2
1 Solution
 
peter57rCommented:
If you use unbound controls on a continuous form, then every record will display the same values in these controls  - so you cannot show different values in different records.
Is that going to be OK?
0
 
kmslogicAuthor Commented:
Well no that's not ok, and like I said if you set the values of the unbound controls in the OnPaint event of the detail section of the form then you can get different values on each row.  The problem is that it causes the whole form to continuously flicker.

I use the same technique to set the background color of certain cells red when the values are in error and that works great without flicker, so it's the actual setting of a value that for some reason does it.


0
 
kmslogicAuthor Commented:
I've created a sample Access 2007 database that shows what I'm talking about.  Just a little table and a form with just the OnPaint event and two lines of code...  Ok nice experts_exchange can't handle the accdb extension... Well done.  Ok uploading it in 2003 format...



OnPaintExample.mdb
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
peter57rCommented:
That's quite interesting, although it's obviously based on an optical illusion (I suppose you could justifiably respond by saying all perception of screen content is based on an optical illusion(:-) ).

I don't know if MS expected this new event to be used in this way and unless thay did, I guess they would say that the feature is 'working as intended'.

I can't think of anything you could change to remove the flicker (short of running the app on the most powerful hardware around, and seeing if that improved the refresh rate)
0
 
kmslogicAuthor Commented:
what's interesting to me is that if you just change the background color of cells this works entirely without flicker (and is quite useful).  Somehow putting text in the control is causing some sort of unintended event loop.
0
 
jjeldridgeCommented:
KMSLogic,  Did you ever can an answer or workaround on this question?  I am experiencing the same problem
0
 
kmslogicAuthor Commented:
Sorry it just looks like this approach isn't doable.  I'm assigning the points to peter for pointing out the undoableness of using the onpaint event for this purpose.
0
 
jjeldridgeCommented:
I agree that the onpaint will not work.  What is actually happened is an infinited painting loop as you fill in the unbound control (in triggers on the paint event...which triggers the code to fill the control...which triggers on the onpain event and so on.)

My particular problem, in which I was using an unbound control, was trying to pop a value based on my underlying table into an unbound control on the multiform page.  I was trying to use code initially (and thus the onpaint event) but then it occurred to use a view instead of a table as the datasource for the form.  I had thought, in doing this, I wouldn't be able to edit the data; but you can as long as you formulate the view correctly.  So with the view, I bring my table's data and then I join in the value I wanted to place in the unbound control.  Everything works fairly well.

There is a small issue with how updates work that is a little ugly because of this architecture; but I think, even that, can be smoothed out.

I'm not looking for points...just wanted to offer what my workaround was.
0
 
kmslogicAuthor Commented:
Well my situation was one where the recordset I was using wasn't updatable.  In your case it sounds like you came up with one that was which is great.  There are many situations in Access where a view/query will be non updatable even if you include the key fields from all the underlying tables in it (what I assume you mean by 'the right way')
0

Featured Post

Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

  • 5
  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now