Enabling and Disabling Buttons on a Form.

[Slurry Pumper]

Hey all,



I've been hacking my way through a design of a database that will help determine all repairable and OEM customization opportunities. Basically, the database will parse out from a master table all the items within a particular category that is above an entered value, and make individual list of these opportunities according to the item category. The form I have to control all of the various list is shown below, and I have remarkably made it this far with the help of the gurus floating around on this site. At this present time this database will filter the main table to remove all items that do not meet the dollar value threshold needed, then parse out all AC Drives and Inverters, and Brackets and Linkages for both repairs and OEM commercialization opportunities. Then remove some unwanted data that meets certain item description requirements, and finally let you view or print out a report in pdf format. So the question is:

1. If an operator fails to enter a value in the yellow box but selects the "Press to Filter" button on either the Repair or the OEM Commercialization, the program will go ahead and filter for a non value and return a table with nothing in it. Can I get the form to check that a value has indeed been entered before it goes through and performs the filtration queries?

2. Is there a way for the red buttons in either the "SELECT REPORT FOR REPAIRS" or "SELECT REPORT FOR OEM COMMERCIALIZATION" section to be disabled until the upper portion of the form is completed. So If setting a value for a repair filter, the entire "SELECT REPORT FOR REPAIRS" section of red buttons would be disabled and non-selectable until such a time as to have the upper portion where a filtered value amount and the "Press To Filter" button is selected?

Thanks for any help, or comments even the trolling rude ones, they are the best.

[RuralGuy]

Start the form with the "Filter" buttons disabled and enable them in the AfterUpdate event of the Yellow boxes.

[vicsaccess]

Personally i make it a habit to always validate the users input before an action. air example on the filter button-

Private Sub cmdfilter()
Dim strfilter As String
    If IsNull(txtrepair) Or (txtrepair) = "" Then
        '''Let the user know what is needed and set focus on the textbox
        MsgBox "Please enter a value", vbCritical
        Me.txtrepair.SetFocus
        Exit Sub
    Else
        '''Perform the filter
        strfilter = "([repair]= " & txtrepair & ")"
        Me.Filter = strfilter
        Me.FilterOn = True
    End If
    
End Sub

Its a little extra work but it gives me the chance to check the users input before performing an action and possibly returning an error that the user won't understand.

[Micron]

If I may, I would evaluate null or empty string in a function in a standard module. That way, you can call it from anywhere without having to re-write the same code umpteen times. There could be an issue with the enabling approach on AfterUpdate in that once enabled, they remain so if the control contents are deleted - unless you're going to test after every update and cycle them. To evaluate a control, I'd recommend something like this air code. I'm writing from memory:

Sub cmdRepairFilter_Click()

If IsNullEmpty (Me.myControl) Then
  msgbox "Please supply a repair filter value."
  Exit Sub
End If
'do repair filter stuff
End Sub

Public Function IsNullEmpty (ctl As Control)

IsNullEmpty = False
If IsNull(ctl) Or ctl = "" Then
  IsNullEmpty = True
End If

End Function

I think that with this approach, you don't have to worry about enabling/disabling buttons and the extra code that comes with that.
P.S. - could you explain what this means?
even the trolling rude ones, they are the best.
Thanks.

[Slurry Pumper]

Hi all,

Thanks for the suggestions. I mean no harm from the trolling rude ones comment. I'm comfortable with people not liking my views, thoughts, or questions and it actually fuels me to be a more complete person by learning what I don't know. So if you come on here and call me stupid that I don't know how to do something that would be considered basic and mundane, it will fuel me to learn more about it and become more competent. No safe spaces needed here. I thrive on negativity, I wake up every day and think about what can go wrong and how it can be avoided. It is part of my professional career to look at the bad things that can go wrong, and press the brakes on over enthusiastic non technical ideas that I know are not possible or practical.

Now I will dissect the comments to this thread, and produce a more complete AH proof database for my colleagues to use.

[Micron]

I think that I can speak for every other person who contributes here when I say that I would never make disparaging comments about someone just because they didn't know something. There was a time that I couldn't have written a line of code to even present a message box. I still don't know a lot of things about Access and vba, but what I do know I learned directly from others and many forums like this one, and no one treated me with anything but kindness and respect. I understand that sometimes written communication can be misinterpreted as to meaning and tone, and when that happens the response should seek clarification and not immediately become rude and disrespectful.
I only asked my question because I was curious as to the meaning.
As for my suggestion, I guessed that you'd know you'd have to use your own control names (not myControl) and would either know or seek to discover what a 'standard' module is.
Good luck with your project!

[vicsaccess]

Micron , as I agree with your description of misunderstood tone and comments, your humor always cracks me up. In my research for different methods I've found your expert advice on many forums dating back several years helping individuals, if you believe "I still don't know a lot of things about Access and VBA" then there may be no hope for the world

Slurry, as much of a pain that it is, always validate users input before action. it will save a lot of grief and error messages. As for Trolls, you generally won't find anyone here with bad intentions but occasionally they are very short and blunt with their answers which can be taken wrong. if you do run into this simply ask for clarification.

[Slurry Pumper]

Thanks for the enlightening comments. In both of the examples given, there are lines such as:

Me.txtrepair.SetFocus
Me.Filter = strfilter
Me.FilterOn = True
Me.myControl

From what I gather, those are not to be used verbatim but instead be substituted for the actual names that I have set up. So for instance Me.txtrepair.SetFocus, has the first part Me. which I need to change to something, then txtrepair, which I guess is the name of the entity than will contain my value. In my case txtrepair is actually named "Repair Value". Then Finally SetFocus is the actual command that will set the form up with the desired button ready for an entry. So if I have this right, I would just need the value of whatever Me is. What is this value? My initial guess is the name of the form itself.

Looking at the other examples of these occurrences with the Me designation tells me that I may have answered my own question, so I will try it and see how it goes.

[vicsaccess]

The "Me" keywork is part of intelesence, it helps VBA know that you are executing on the current form. As for the name of your control being "Repair Value", this is going to give you heartache for two reasons, first being the space in the middle, you'll have to wrap it with [] everytime you use it, second i learned the hard way that i give the control a name based on what it is, in this case its a text box so i would name it "txt"something. As for the setfocus, it moves the cursor to the text box that needs to be filled in to execute the action. sometimes i'll use the .setfocus along with changing the color of the text box to make it more visual but in your case you already have given it a color.
So in your case it would read-me.[Repair Value].setfocus

[Slurry Pumper]

Hey Thanks,

In review, I tried the one example you gave, and it does work. I will take the naming convention advisement for future reference. I substituted the form name for the Me and worked fine. At this point in my code writing life, I think it is Ok for me to type in all of the names of the forms with [] surrounding them. It helps me distinguish what is going on.

[Micron]

Obviously you can use the long form when referring to a form if you wish, but I think you will tire of that soon. When you're coding, the applicable form name is visible in the vbe window anyway, so you shouldn't need your code to tell you what you're working on. Just know that the Me keyword only applies to the active form, so in code on one form you cannot manipulate another form and use Me to refer to the second form. You have to use the long form of the reference (sorry for the interplay between 'form' words).

Me can also refer to a report in the same way.