A form display bug???

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have a very weird case, which I have no idea how anything I do could be
causing. So, I'd wonder if it seems like an Acccess bug and whether there is
a workaround.

I have a form, which is a continuous form with a number of unbound controls
(combo boxes and such) in the form header.

In "AfterUpdate" handler for combo boxes in the header I select a new Record
Source for that form. That works fine as long as the record source is
returning at least one record. However, if I select such Record Source that
it does not return any records, ... the combo box control I've just picked
gets cleared instead of having the new value I've just picked! Moreover, if
I just ... move the window with the form off-screen and back on-screen (so
that the combo box needs repaiting), the combo box now happily has the new
value.

Any ideas?

- Igor
 
Thanks for your reply!

So it does look like Access has a class of bugs when recordsource cannot
return any date.

In my case, the bug is demonstratable with Combo box having a bound column
of 0-width, as described on your page, as well as if it has a single text
column.

And it is only the ComboBox whose AfterUpdate event set the recordsource to
return no data that goes blank.

A check box, by the way, works fine.

I've Access 2003, the latest product, AFAIK. Any ideas if MS is working on
fixing this?

- Igor
 
I would expect MS to be working on the next version of Access, rather than a
fix for something that has been there for a long time.

Your issue relates to changing the combo's RowSource, which is only a
display problem. There was a fudge that sometimes helped. It involved adding
another control that partially overlapped the combo. Can't remember if it
had to be transparent or what, but it did seem to sometimes help force a
screen update, and so worked around the issue.
 
I would expect MS to be working on the next version of Access, rather than a
fix for something that has been there for a long time.
Click to expand...

This is very discouraging! If this has been known before in prior versions
of Access, and it is still present in my 2003 version, that means they did
not bother to fix it for 2003. Why would they bother to fix it for a later
verion, if 2003 did not deserve the fix?

I work for another large software company, and really hope we do not project
the same degree of indifference to known bugs (Access is just my hobby/side
gig).

Your issue relates to changing the combo's RowSource, which is only a
display problem.
Click to expand...

Actually, the combo's rowsource is not chaning. It's the form's
recordsource that is changing. The form is basically a large search form,
with the combos, checkboxes, etc. in the Header being like knobs selecting
filter-like predicates. When one changes, I catch it in AfterUpdate and
update the recordsource for the form, which updates the Detail section of the
countinuous form to reflect the newly-searched-for selected data.

Teh problem happens only the very first time the recordsource goes empty.
If I keep adding predicates via the combox (which changes the recordsource),
the other combo boxes are displayed just fine.

There was a fudge that sometimes helped. It involved adding
another control that partially overlapped the combo. Can't remember if it
had to be transparent or what, but it did seem to sometimes help force a
screen update, and so worked around the issue.
Click to expand...

Maybe there is an AIP somewhere that lets you force the screen repaint that
could be called... I mean, I could sure also notice in the code that the
form now has 0 records and call that API... I'll let you know if I find
something.

- Igor

P.S.
I've tried moving the recordsource update from afterupdate to
beforeupdate. The result was a very confusing error message during the
recordsource assignment.
 
Please feel free to talk directly to Microsoft about this bug or any other
that you strike. The chances of getting something fixed if they know it is
bothering lots of people. (While I agree with you, I don't like our chances
with this particluar one after more than 10 years.)

You can force a repaint of the form with:
Me.Repaint

In some cases, that works; in others there is a timing issue, e.g. if Access
fires it before loading the combo. It would be theoretically possible to use
the form's Timer event to introduce a delay before repaint, but that could
introduce other side effects.
 
Thanks fo rthe suggestion and the warning about the .repaint.

Talk to MS about their bugs? I've tried it once!

About a week ago, as I was starting out with Access, I found a bug:
MouseMove event would not fire for an unbound label ... if a mouse button was
pressed while the mouse is being moved over the label ... except if the mouse
button were pressed before the form with the label was opened. If the mouse
is moved with no ubttons pressed, there is no problem.

I tired calling MS with this bug report, but they ... asked me to pay them
to take the report! Or I had to send some snail mail to them with the report.

That's when I found this community and posted the report as a "Suggestion to
MS" in this very Forum. It went ununswered, of course. (Does MS even
monitor this Community?)

- Igor
 
As promised, here it my update on what I foudn to be the easiest workaround
in my case. (I've Access 2003).

' Workaround for screen bug
If Me.Recordset.RecordCount = 0 Then
Dim l As Integer
l = Me.WindowLeft
Me.Move -Me.WindowWidth
Me.Move l
End If


Me.Reapint does not work, since docs say that it only waits for pending
repaints. But Access is confused enough to beleive that it is done
repaitning, so it does nothing. I've also tried surrounding the Move trick
with Appilcation.Echo False and Appilcation.Echo True, but that did not work
-- Access (or was it underlaying Windows GDI?) was too smart to not attempt
repaints in that case! But even with the two moves, the tiniest flicker
seems perfectly acceptable to me.

- Igor
 
Actually, the screen bug is even more pervasive that I thought. It also
appears when the recordset transitions from 0 records to some records. So
here si the better version:

' Workaround for screen bug
Dim useBugWorkaround As Boolean

useBugWorkaround = (Me.Recordset.RecordCount = 0)

Me.RecordSource = stNewRecSet

If Me.Recordset.RecordCount = 0 Then useBugWorkaround = Not
useBugWorkaround

If useBugWorkaround Then
Dim l As Integer
l = Me.WindowLeft
Me.Move -Me.WindowWidth
Me.Move l
End If


- Igor
 
Back
Top