Possible to hide an entire row in a grid and move the other rows up? (1 Viewer)

[gojets1721]

So I've got a a grid full of commands in a form. I was curious if its possible to hide an entire row of the grid based on the selection in a combo box.

If possible, I was also curious if it was possible for the other rows, which are showing, to 'move up' and take the place of any hidden ones. That way there isn't a big empty space where the hidden row is. I've attached a sample DB if it helps.

It's an odd question so let me know if more info is needed. Basically some commands don't apply to some of the selections in the combo box, so its best if they are just hidden.

 

[Ranman256]

you can filter out records in the query, it will look like its hidden.

 

[GPGeorge]

Okay, for the benefit of those who haven't opened the accdb, this is a just column of command buttons in a layout grid on a form. Not exactly what one usually thinks of when the word "grid" is used.

True, they are in a layout grid, which is a property that can be applied to forms to control the relative positions of objects within that layout, but again, probably not what most people think of as "a grid full of commands".

You could very easily hide one or more command buttons, depending on the selection in the combo box. You'd use the AfterUpdate event of the combo box to show or hide them. Moving them is also possible, but considerably more effort.

Rather than move or hide them, though, I would probably enable or disable them and otherwise leave them alone.

For example, the code might be something like this in the AfterUpdate event of the combo box. Change the names of the controls to realistic, meaningful names, of course.

Private Sub Combo54_AfterUpdate()
Dim strSelection As String
Dim ctl As Access.Control

For Each ctl In Me.Controls
If ctl.ControlType = 104 Then ctl.Enabled = False
Next ctl
strSelection = Me.Combo54
Select Case strSelection
Case "Cleaniness"
Me.Command18.Enabled = True
Me.Command21.Enabled = True

Case "Service"
Me.Command23.Enabled = True
Me.Command35.Enabled = True
Case "Timeliness"
Me.Command37.Enabled = True
Me.Command39.Enabled = True
End Select


End Sub

 

[The_Doc_Man]

There is a lot of overhead involved, but you can take your pile of command buttons and do two things:

First, set .Enable = False and .Visible = False for any buttons you don't want to see and set .Enable = True and .Visible = True for all that you DO want to see.

Second, for the buttons you WANT to see, you must keep track of "next available slot" because you can use <<button>>.Left and <<button>>.Top to move the buttons. Basically, you pick a spot as "first button goes here" and you set x & y coordinates for the top left corner of the button. Then you move the "next available slot" based on either or both of the <<button>>.Height and <<button>>.Width to find where the next .Top and .Left corners go. I have found that it is best if you separate the buttons by one twip, which is the units being loaded to the position and size coordinates. I.e. you get visual anomalies if the buttons are exactly flush with each other. So you would add <<button>>.Height + 1 and/or <<button>>.Width + 1 to set the next corner for the buttons. Don't forget that the form's coordinate system STARTS at 0,0 as the top & left of the form's display area and goes down and to the right as the coordinates increase.

You have to keep track of where you move the buttons because you cannot allow them overlap. Otherwise you lose the ability to use one of the two buttons that occupy the same space. I believe it is the .Tab order that decides which ones are "on top" but it might some other factor that drives the z-axis of the button. (It has been too long since I played with that.) The ones that are disabled and invisible cannot be selected so they aren't a problem. But if two enabled buttons exactly overlap, the functionality of one of them will be negated by being inaccessible.

 

[GPGeorge]

There is a lot of overhead involved, but you can take your pile of command buttons and do two things:

First, set .Enable = False and .Visible = False for any buttons you don't want to see and set .Enable = True and .Visible = True for all that you DO want to see.

Second, for the buttons you WANT to see, you must keep track of "next available slot" because you can use <<button>>.Left and <<button>>.Top to move the buttons. Basically, you pick a spot as "first button goes here" and you set x & y coordinates for the top left corner of the button. Then you move the "next available slot" based on either or both of the <<button>>.Height and <<button>>.Width to find where the next .Top and .Left corners go. I have found that it is best if you separate the buttons by one twip, which is the units being loaded to the position and size coordinates. I.e. you get visual anomalies if the buttons are exactly flush with each other. So you would add <<button>>.Height + 1 and/or <<button>>.Width + 1 to set the next corner for the buttons. Don't forget that the form's coordinate system STARTS at 0,0 as the top & left of the form's display area and goes down and to the right as the coordinates increase.

You have to keep track of where you move the buttons because you cannot allow them overlap. Otherwise you lose the ability to use one of the two buttons that occupy the same space. I believe it is the .Tab order that decides which ones are "on top" but it might some other factor that drives the z-axis of the button. (It has been too long since I played with that.) The ones that are disabled and invisible cannot be selected so they aren't a problem. But if two enabled buttons exactly overlap, the functionality of one of them will be negated by being inaccessible.

Going down memory lane a bit, one of the first -- if not the first -- Article on Access I ever published was on Dynamic Menus, back in the early 2000's. I spent a lot of time, a LOT of time, working out the placement of command buttons, as The_Doc_Man describes. In the end, it became clear to me, though, that I'd spent a lot of time solving a non-problem. It was fun to do and rewarding to figure it out, but not at all practical in real life.

By the way, there's a serious flaw in my approach, which I didn't know about until I started getting feedback from more experienced Access developers. It wouldn't impact your situation where all of the command buttons already exist and are only shuffled around on the form.

 

[Pat Hartman]

Here's a sample that might be helpful. It is based on the concept of the original Access Switchboard. There's two versions of the switchboard in the zip.

 

[arnelgp]

i made tables for your "service", "cleanliness", "timeliness" (category).
then i made a "list" of items for each category (note the CategoryID is same on the category table).