Form Locks Some Controls

[OldBirdman]

I have a form=Options, which is Bound, Modal, PopUp. This form consists of many tabs, each with many, varied controls.

I have a Frame with 3 options, using radio buttons. Works fine. But if option 3 (3rd radio button) is chosen, I want to enable another control, say a textbox, to get more information. Logically, this belongs in the Frame, although really not part of the frame. So I place the textbox apparently in the frame, and use Format->Bring-to-Front. It looks good, but...
Sometimes it works. Sometimes it works once. Sometimes it doesn't work. Different results each trial run. Doesn't work means that the radio buttons inside the frame become locked. Can't change.
Removing the textbox fixes the problem. Changing the frame to a rectangle will solve the problem. Of course, changing a frame to rectangle looses the ability to store the status of the radio buttons and have Access (2000) handle them.

I would like to know how to keep my frames, if possible. If not, why not?

[ADezii]

@OldBirdman
Why is it imperative that the Text Box reside within the Frame, whose functionality is to basically provide mutually exclusive choices? IMHO, no other Controls belong in an Option Frame except other Radio Buttons in your case.

[OldBirdman]

Why is it imperative that the Text Box reside within the Frame

Because it pleases me esthetically.

If I'm allowed to put one control on another, why should Access lock that control if it is bound, or a frame, or whatever the problem is? I can, with effort, get around this. My question therefore is, why should I have to write complicated code when simple Access features should be available?

IMHO, no other Controls belong in an Option Frame except other Radio Buttons in your case

I have, on my options form, a tab page(name=Images) that has a frame with label caption "Picture Location". 3 radio buttons, 1=With Program; 2=In Sub-Directory of Program; 3=Drive:\PathName. Choices 2 and 3 need the path (or path fragment). So I put textboxes under the labels for those 2 radio buttons. When chosen, Access sets the value for the frame, and I, with code, .enable the correct textbox. To me, seems clear and obvious to users.

[ADezii]

How about:

1. Setting the Backstyle Property of the Frame to Transparent.
2. Place the Text Box immediately below, and outside of, the Frame.
3. Depending on the Option chosen, dynamically increase/reset the Height of the Frame while making the Text Box Visible/Invisible. The Text Box should now appear to be 'inside' the Frame.
4. The code would look something like this:
   

   Private Sub fraTest_AfterUpdate()
   Const conNORMAL_FRAME_HEIGHT As Single = XXXX
   Const con_EXPANDED_HEIGHT As Single = XXXX
    
   Select Case fraTest.Value
     Case 1
       Me![txtTest].Visible = True
         Me![fraTest].Height = con_EXPANDED_HEIGHT
     Case 2
       Me![txtTest].Visible = False
         Me![fraTest].Height = conNORMAL_FRAME_HEIGHT
     Case 3
       Me![txtTest].Visible = True
         Me![fraTest].Height = con_EXPANDED_HEIGHT
   End Select
   End Sub

5. This approach would be analogous to the Expanding Form concept.
6. I do realize that this is sort of Off-the-Wall, but it may be a viable solution. Only you can be the judge of that.

[missinglinq]

I understand your reasoning here, Bird, and can't say that I disagree with it, in this case, and also understand your frustration! I reproduced your scenario, based on the info you posted, and have played around with it for almost two hours now, and can't reproduce the problems you're encountering. This, along with the fact that you report that it's an on again, off again problem, makes me think that you've probably got a corrupted form.

First thing to do, I guess, would be the old 'create a blank db and import all the objects into it' routine.

Linq ;0)>

[OldBirdman]

Thank you for all the time and effort spent here. I really do appreciate it.

I have not managed to do the

the old 'create a blank db and import all the objects into it' routine.

effectively. I can 1) create a blank db, and 2) import all the objects. But it won't run. It fails with "Global dbsDataBase As Database" - Compile error: User-defined type not defined.

Now I'm stuck! From the VBA window, I should choose Tools->References... but References is grayed out (not enabled).

Will work on that, but can't today. Eventually I will get it working, usually by creating a blank db, creating a useless object, importing old db, deleting useless object, and then getting checks in References to match old db. I don't understand References at all, and can only match what exists from other projects.

I did manage to create a new db with only the form in question. It locks, and conveniently all the time, not intermittent. I'll play with it for awhile.

Thanks for the suggestions, ADezii. At the moment, I'm not going to try, as 1) changing the frame height will not get ALL the textboxes & other controls except radio buttons out of the frames, and 2) I'm going to try to fix, now that I have isolated the problem.

[NeoPa]

@missinglinq
This is a great solution for thoroughly b*ggered databases, but may it be possible that a simple Compact and Repair is all that's required in this case. It would certainly be my first thing to try.

I do suggest though, that you give any further helpful details about things to remember to do or avoid doing during the Create from Scratch method. This will certainly be useful information to find for others even if OB manages to get away without needing the full monty.

A couple of points I can think of for re-creating a db from scratch :

• Ensure all References are set as the original (VBA Editor / Tools / References...).
• Configure the Startup parameters in the same way (Tools / Startup...).

[OldBirdman]

Ensure all References are set as the original (VBA Editor / Tools / References...).

I would like to do this, but

Now I'm stuck! From the VBA window, I should choose Tools->References... but References is grayed out (not enabled).

[NeoPa]

This can occur in two scenarios that I'm aware of :

1. The relevant module has not been installed with the app (Access).
2. Some unsaved design changes are pending or a message box of some form (anything modal) is still active.

BTW Did you try with a simple Compact / Repair?

[OldBirdman]

Compact / Repair didn't work, but followed by Copy / Paste to make a copy of db, then another Compact / Repair solved the issue (of being able to get to Tools->References). At least for my test db, containing only the problem form.

This didn't fix the problem, however. Checkboxes, Textboxes, & Comboboxes still lock.

[OldBirdman]

I just can't let this go if it is solvable. About 1 year ago I had this problem. Different database. I had tried compact/repair, and rebuilding from a blank database, importing forms, tables, etc. Eventually I ended up starting with a blank database and copying controls one-by-one and repositioning them by hand. Then I copied the code, module-by-module, and had to re-establish all conditions one-by-one.

This program has been working fine since.

Now I have a different database that locks. Both my machines produce the same problem, even with different versions of Access, I had a very small version of the program run on another machine, and there were no problems, but they persist on my machines.

So, for my little test version, I rebuilt it as described above. It works. Controls do not lock. But... the Beep statement will not compile.

Private Sub cmdBeep1_Click()
    Beep
End Sub

"Compile error: Invalid use of property", and the word 'Beep' (Line 2) is highlighted. Running the code also gets the same message. Of course, I can replace with DoCmd.Beep.

As there is now a 2nd symptom, does anyone have any ideas what I can do to run this down?

[Stewart Ross]

As Beep is built in to VBA, do you have the Visual Basic for Applications library referenced? I know you have been resolving references issues anyway, but check that you have Visual Basic for Applications ticked when you select Tools, References from the VB Editor menu (as per screenshot), and that there are no error messages indicating missing libraries (which would also prevent code compilation, though not for VBA if it is selected OK).

Given the history of this one as per the earlier posts, I'm reckoning that the compact/repair/rebuild process you've undertaken has only been partially successful. There is no easy way to know what is going on in code underneath a form, which I reckon you'll need to rebuild from scratch in an otherwise fresh copy of your DB into which you've imported all known good objects.

-Stewart

[OldBirdman]

Thanks again for responding. My problems are symptoms of something going on that may be related to Access, or not. Treating one symptom doesn't fix the problem, although it may temporarily suppress it.

Yes, all checked as in your screenshot
"Beep" works on the Access 2002 (saved as 2000) machine but not on the Access 2000 machine. Otherwise all tests produce similar results on both machines.

I continue to test. I now have the problem further simplified.
1) There are no tables, all controls unbound
2) 2 forms, identical except that fOneTab has a tab control with one tab, and all controls are on that tab page. fNoTabs has no tab control. The same controls are there, with identical code, but not on a tab control.
3) Controls consist of 1 frame with 2 radio buttons, 1 textbox, and 2 command buttons.
4) Command Button cmdMoveTextBox sets the textbox top property so it is either completely within the borders of the frame, or completely outside the borders of the frame.
5) Command Button cmdChangeBackStyle changes the frame's backstyle property to either 'Normal' or 'Transparent'. It also Beeps.

Here is the IDENTICAL code for both forms:

Option Compare Database
Option Explicit
 
 
Private Sub cmdChangeBackStyle_Click()
    If fraTest.BackStyle = 1 Then
        fraTest.BackStyle = 0
    Else
        fraTest.BackStyle = 1
    End If
    Beep
End Sub
 
Private Sub cmdMoveTextBox_Click()
    If text.Top > 2880 Then
        text.Top = 1.5 * 1440
    Else
        text.Top = 2.1667 * 1440
    End If
End Sub

fNoTabs
a) All code works.
b) Frame does not lock

fOneTab
a) Beep statement does not work, and must be replaced with DoCmd.Beep
b) Frame locks after one click if any part of the textbox is within the frame, AND the backstyle is set to Normal.

.

. . . you'll need to rebuild from scratch in an otherwise fresh copy of your DB into which you've imported all known good objects.

I started from scratch. I created another database, and added the same controls to a blank form using the toolbox. I did not copy them from anywhere. I did copy the code, first to NotePad to remove anything that might be attached but not apparent. The results are:
a) All code works. Identical behavior as fNoTabs a) above.
b) Frame locks. Identical behavior as fOneTab b) above.

I've reached the point where I can't rebuild. If any part of a textbox is inside a frame with BackStyle=Normal, that frame will lock after one click of the frame. It locks whether I click a radio button, or just click on the frame or its background. Clicking in the frame locks it. Change a format item (backstyle), and it works fine. Move another control so that it doesn't overlap the frame, it works fine.

Tab controls have collections of controls. I have a feeling that frames do too, in a limited way. Somehow, the combination of these two controls is upsetting my versions of Access. The solution is to conform to a simple set of rules: If a foreign control is within a frame and on a Tab control, don't use BackStyle=Normal.

I'll just ignore the problems with 'Beep' and hope they don't get worse.