Me."".Visible not working correctly

[connerlowen]

HI,

I have a form that in the OnCurrent event I want to hide a lot of the fields in the form because they will be used on an as needed basis. This form is based directly off of a table. I have used the visible = false code. There are 75 fields I need to hide. All of the fields are either text boxes, combo boxes, or yes/no. The first 50 are hidden correctly, however the lables for the last 25 are still visible on the form. I used the same code and format for every item. Is there a way to fix this to make the labels hidden?

Thanks,

Conner

 

[vbaInet]

75 fields sounds like an awful lot connerlowen. I wonder if there's a table structure problem here?! Why are there so many?
It's possible to hide them but have you considered working on the layout, i.e. using a Tab control and disabling the pages that are not in use?

 

[connerlowen]

thanks for the reply,

There is a reason there are so many fields. This database is for generating quotations. Within each quotations there is a possibility for up to 15 metals (5 Precious, and 10 Base). Within each Metal, there are 5 Fields that need to be filled out. I am fairly New to Access, and the only way I know to have room for every metal possibility is to have 75 total fields. I want to hide them, and fill them out on an as needed basis. For example if there is a precious metal, the employee will select add precious metal, and the 5 fields for PM1 will become visible and able to be filled out. If you can suggest a better way to accomplish this I would greatly appreciate it.

Thanks,

Conner

 

[vbaInet]

This sounds suspect of a structural problem. You can post a new thread in the Tables forum on this site and we can advise how best to restructure/normalise your tables. But note that this is a vital part of your project.

For your immediate problem, have you looked into a Tab control as I previously mentioned? You can use that to section off controls and instead of hiding individual controls you can hide an entire page.

 

[connerlowen]

I do not think I want to create multiple Tabs because I want it to all depend on whether the employee needs to enter the information or not. I almost want buttons for the employee to either enter another metal, or move on to the next piece of information they need to enter.

 

[vbaInet]

Ok, how are you controls spaced out? So if you hide some of the controls, will the form still look alright?

Perhaps you can show me a screenshot and highlight those that you're looking to toggle visibility.

 

[connerlowen]

I have taken some screenshots.

Here are screenshots of my form in design view:



Here is a screenshot of my code to hide all of the fields:


Here are screenshots of the labels that are still visible:



Thanks,

Conner

 

[connerlowen]

Also I have posted a thread in the Tables Forum

 

[vbaInet]

Nice looking company logo

From what I can see in "screenshot middle" you unfortunately have a bigger problem. Remember what I mentioned about posting a new thread for help with your structure, I think now would be the best time to do it. With a properly structured db, you won't have this problem of hiding fields in the first place.

 

[vbaInet]

Also I have posted a thread in the Tables Forum

Alright, good job! I hope you explained your business model and posted your current table structure?

 

[connerlowen]

I explained the Model, However with 75 fields I don't know how to post the current table structure.

 

[connerlowen]

vbaInet,

As I am new to all of this, I have a question non-related to coding. In my screenshots, I did not necessarily intend on leaving the company logo. If you go look now, the screenshots are all gone. You saying "Nice looking company logo

" made me think it was not supposed to be there. Is it bad that the company logo was in the screenshots?

 

[vbaInet]

Nothing wrong with that, I was only saying it looks nice. However, if it's not your company then of course it shouldn't be there.

Just upload screenshots of each part and then upload your db with just the tables.

 

[connerlowen]

It is my company.

I uploaded a screenshot the design view of the table with the 75 fields in question. What more to I need to include. If you could go look at it, I would greatly appreciate it. Thread "Too many fields"

Thanks,

Conner

 

[vbaInet]

I've had a brief and there's most likely a data model for what you're trying to do. Have a look here and search for something close to your model and continue on that thread:

http://www.databaseanswers.org/data_models/index.htm

 

[connerlowen]

What should I be looking for? there is no "Quote" or "Quotation" on the list.

 

[The_Doc_Man]

I make command buttons appear and disappear all the time, and while it is a pain in the toches to do it the first time, you can write a subroutine for these manipulations and use it when you need it. After that, it is trivial.

What I do is pass in the name of the form and of the control so that the code can do Forms("formname").Controls("Controlname") as a starting point. If you define a Control variable in your subroutine and do a

SET cltvar = Forms("formname").Controls("Controlname")

then you can just use the control variable later in the code. You can also have a form variable assigned this way (obviously, to the form only) to look at the properties of the form as a whole, for example, FormVar.Width, FormVar.Height, etc.

Then the other subroutine input parameters are passed to determine visibility (Yes/No) and position if visible (you need a .Top and a .Left passed ByRef so that you can update the position if visibility is Yes). As it happens, I also pass in a code that tells the routine the color to use for ForeColor, BackColor, and BorderColor of the main control and of the associated label (see below for more.)

If the control's visibility is NO then you can move it to a "neutral" area on the form and make it invisible and disabled (so you can't accidentally click it when you weren't supposed to be able to see it.) There is also the option of moving the control to the bottom of a stack of such controls. You can determine the size of the control from its .Height and .Width properties to adjust the "new" .Top and .Left as appropriate if you moved the control to a point where it was visible.

You can also a test on CtlVar to see what type of control it is, because sadly, Access is not consistent in regards to whether something is .Visible or whether some other keyword is used. (Hint: Use the Object Browser to determine the correct keyword and do a SELECT CASE on control type to decide how to handle it.)

Now, here's the pay-off for this apparent walk through the woods. If you know the form name and the data control name (which you DO know because you passed them into this putative subroutine), you can write some code to step through the FormVar.Controls collection to find labels and their names - and their .Parent objects, which will be the text boxes, combo boxes, list boxes, etc. Just as you can move a text item, you can move a label because it ALSO has a .Top and .Left and .Height and .Width that you can use for the computation. And the parent's .Name property for the control to be moved will be the same as the control name you passed in. So if you had one more control variable in the subroutine to act as a Label pointer, you could move the label and control (or make them hidden) at the same time. Once you know the control name, the label name, and the correct settings, it is all downhill from there.

Of course, you don't HAVE to do it this way - but it is the way I do it on my forms that make control positions just one more dynamic thing to be computed and controlled. Write one subroutine with lots of smarts and just call it when you need to move stuff around.

 

[vbaInet]

The_Doc_Man, have a look at post #7, the screenshot titled "form screenshot middle". Conner has already made a follow up thread here.

Conner, have a look for something that would include quotations in that business model.

 

[spikepl]

@The Doc Man

I tend not to interfere with such things but there are instances and this is one of them: you are here dealing with a total beginner, and you are telling him, in answer to his question, the equivalent of how to dismantle the wall socket because his thick fingers otherwise do not fit in it.

I understand the pleasure of clarifying some issue to a less-knowledegable person, but there are times when that is neither nice nor productive. Please consider WHO you are advising when advising (or is it WHOM?)

 

[vbaInet]

I make command buttons appear and disappear all the time, ...

But it made The_Doc_Man sound like a magician.