> This isn't quite what my problem is. I am writing a non-visual activex dll
> that works somewhat like a VB Data Control. It needs to fire the equivalent
> of the VB Data Control's "REPOSITION" and "VALIDATE" events. However, I
> can't see a way for it to detect when the VB Recordset is changing the
> record position ( for example when a user executes the following code )
> If you do this with a "real" data control you get the Validate and
> Reposition events fired by the Data Control.
> There must be some way of doing this because the VB Data Control does it -
> unless the VB environment has some special code in the Recordset object
> which is not accessible to any control other than the VB Data Control.
> Thanks again
> >Hi Sandy,
> >You will have to code it yourself, like for the click event of a next
> >Private Sub cmdNext_click()
> > recordsetname.MoveNext
> > If recordsetname.EOF Then
> > recordsetname.MoveLast
> > End If
> >End Sub
> >For each event that can cause trouble you have to add code to check if an
> >error might occur and react on it.
> >Johan Savels
> >Trainer Data Bases & Visual Basic
> >Royal Technical School of the Belgian Air Force
You sure know how to hurt a guy! :)
I'm doing the same thing. I have a class that replaces the data control.
Everything works fine except the case you mention. The only way I know to
do this (at the moment) is to add a timer to your class that continually
checks the bookmark of the current record to that of the last move your
class processed directly. There will be a slight delay but if the
interval of the timer is short enough the user won't notice it.
My only concern with this methodology is that it adds unnecessary
overhead to the app. If VB supported true OOP I would derive a new
recordset class from the existing recordset class and add the
notification capability. To do this in VB you have to create a class that
contained a recordset and duplicate the recordset's interface. All
defined properties and methods would be passed directly to the underlying
recordset except the movement methods. These would be passed to the
underlying recordset and also raise an event. A developer would access
this pseudo-recordset through the Recordset property of your data control
The drawback? Whenever the recordset object is refined in a new release
of DAO you would have to immediately release an update of your data
control class to support it.
The alternative is to disallow direct changes to the underlying
recordset. I'll have to give this a lot of thought before making a final
If you want to discuss it further contact me via email.
The first Gumdrop has been posted. More on the way...
GUI Gumdrops - Tasty Morsels for Windows Developers
For information about the VB SIG of the Long Island PC Users'Group
visit the LIPCUG web site at:
To be placed on the mailing list, send an email with the subject
"VB SIG Mailing List" to:
See web site for directions.