Error Handling in Run time

[Minty]

I'll try and step in ...



Why would you call Both functions ajbFileList & ajbFindAsUType on form load?

They are designed to be called in the onchange event handler of a search combo / text control aren't they ?

[Homegrownandy]

Minty. I have no idea.

I did it as instructed by Allen Brown.

When I use the module ajbFindAsUType on my forms I don't need to call it. I've tested it several times in new applications.

In the downloaded version from Allen Brown I do need to call it on form load (I've also tried moving the form into my existing application to test.)

I'm still looking into why.. clearly its something I've done.

as for ajbFileList it populates a list box to select a template. The selected template is copied and manipulated. So in this case it probably does need to be on form load.

Edit: I do have an idea... (possibly wrong) ajbFindAsUType requires a combo box listing the fields that are in the forms record set. so again that's probably why its on form load.

[Homegrownandy]

Update.

The reason it works on mine without the on form load event:

I have this in the after update event of the two textboxes:

=FindAsUTypeChange([Form])

This isn't in Allen Browns, so clearly its something I've done. This was around two years ago so I'm still investigating why I did this.

it doesn't seem like I would come up with that alone. But i also cant see it on my forum history.

[Minty]

If I'm reading the code supplied by AB correctly there are two (three?) distinctly different functions involved here.

FindAsUTypeLoad(Me) - This should be loaded at form load.

It automatically sets up the events for two unbound controls that you MUST have on your form as follows;
cboFindAsUTypeField (the combo where we will the list of controls that can be filtered), and txtFindAsUTypeValue (the text box where the user enters the value to find.)

Before we go any further does your form conform to the requirements above?

[Homegrownandy]

Okay the code does this:

   If HasUnboundControls(frm, "cboFindAsUTypeField", "txtFindAsUTypeValue") And (frm.RecordSource <> vbNullString) Then
        'Set the event handers for the 2 contorls
        frm!cboFindAsUTypeField.AfterUpdate = "=FindAsUTypeChange([Form])"
        frm.txtFindAsUTypeValue.OnChange = "=FindAsUTypeChange([Form])"
        'Calculate the number of pages on the tab control if there is one.
        lngMaxParentNumber = MaxParentNumber(frm)

[Homegrownandy]

Minty, at the moment I have seven test forms all set up slightly differently.

the first form in question is set up exactly as described. The update to events on form control as shown in the previous post is persistent and put me off course for a bit there.

Back on track now... Ish.

I tested the example download and that works on all machines with no issue. So the on load event will work as intended in that example.

[Homegrownandy]

tested the listbox on a new DB and all works perfectly on the runtime machine.

Back to the main reason for posting... Obviously it would have been nice if someone spotted why this wasn't working. But the reason I made the post was to improve how I trouble shoot these issues myself.

Error handling preferably but any pointers would be great.

I'll get to the bottom of it by starting again and testing at every step it's just very time consuming.

Appreciate all the responses.

Andy.

[Minty]

As a rule I disable all error handling in my development environment. I want to see all the errors and what causes them.
This is one reason Set warnings = False is a bit dangerous, and should be avoided. It hides any errors in your code.

There are various ways of switching on and off error handling during development.
I'm old school and don't add it in until I've finished the bit I'm working in, but there are some cute methods out there.

[Homegrownandy]

I believe its a referencing issue. Even when the references are not being used, a form load event (possibly anything requiring some VBA) will close the database.

so... In my test the form is literally just the listbox nothing else.. no other VBA. But because the VBA is running I guess it fists checks all references and closes if one inst available.

I am aware of issues surrounding references in VBA i just didn't think it would matter when they were not in use.

Edit. it's not all VBA because the find as you type would work when not on the form load event.

[Homegrownandy]

I've changed all code to late binding and deleted referencing. Why it auto updates every time and wont revert I don't know. But its no longer an issue.

[Minty]

References are automatically loaded / brought up to date whenever a database is loaded.

On a runtime they will update to the runtime versions appropriate libraries.

[Homegrownandy]

The version of office on the other machine is corrupt. At least I know what the problems are now. Thanks for the help.

References are automatically loaded / brought up to date whenever a database is loaded.

This only happened when there was a form load event. (or at least it was only a problem then).