Invisible Controls in Form

**thelonelyghost** · Aug 10 '10, 08:42 PM

To be more accurate, I'm only asking for help to find the area of code that's causing the errors. I'll do my best to figure out how to fix it. Really any help would be appreciated.

EDIT: I should also mention that I've looked into the .Visible property of controls and everything already has the .Visible property set to true, yet the problem persists.

**munkee** · Aug 11 '10, 07:01 AM

I've taken a quick look over, have you tried compiling your vba code? When I compile there are atleast 2 areas which are causing errors.

One of which you havent put a dim on blBefore and blAfter in the EvaluateDiffere nce() function.

There are also a lot of comments about code being broken which to be fair I would comment out if its not working and you are trying to get the form running properly.

There is also an error in function SELECTQuery on the line FieldCount(0) = LBound(MyRS.Fie lds). Expected array error.

As far as your controls not appearing if you check the form properties you have "Allow Additions" set to no. Turn this on to yes and your controls will appear. The form is in data entry mode so ofcourse without additions being available you can't do anything.

The add record button is yet to be coded too just incase you have been trying to click that.

Finally I assume this is all to allow users to either add a record or to add/edit information on an existing record and that is why you are doing a before and after snapshot to show the changes? If so I think your form being on data entry needs to be changed else they won't be able to select a record to edit, only add new ones.

**thelonelyghost** · Aug 11 '10, 02:10 PM

Originally posted by munkee

munkee: As far as your controls not appearing if you check the form properties you have "Allow Additions" set to no. Turn this on to yes and your controls will appear. The form is in data entry mode so ofcourse without additions being available you can't do anything.

Thanks, that really helps out a lot! I did know Data Entry was on but I wasn't positive as to what that meant. I originally thought Data Entry = Yes was equivalent to Additions = Yes, Deletions = Yes, and Edits = Yes. I understand is that it actually equals Additions = Yes, Deletions = No, and Edits = No.

If Allow Additions = No and Data Entry = Yes, I would think Access would throw an error in the body of the one bound control (CTSLogNumber). In reality, the entire form malfunctions and does not load completely. In the form header, the unbound selector (combo box) that jumps to another CTSLogNumber is also limited to one number. Ah well, it's probably set up this way because I'm using a ten-year old program...

Originally posted by munkee

munkee: One of which you havent put a dim on blBefore and blAfter in the EvaluateDiffere nce() function.

There are also a lot of comments about code being broken which to be fair I would comment out if its not working and you are trying to get the form running properly.

There is also an error in function SELECTQuery on the line FieldCount(0) = LBound(MyRS.Fie lds). Expected array error.

I'm well aware of the fact that many of the functions don't work. Granted, I forgot to remove all but the pertinent information from the database, but it is a copy of the version that I'm working so inevitably there will be bits of code (no pun intended) that are unfinished/broken.

WRT compiling, my previous method to debug the code is to open the form and spot-check the various form functions. Once upon a time I used the function to compile the database, but it was far from common practice since I can't focus on one project consecutively for very long. I cope by jumping around in the database, adding functions that act as tools for further programming, etc.

Since reading your post I decided to try the compiler again and... First, I commented-out the functions that are in-progress for another project. I then ran the compiler and fixed a LOT of bugs. This method of debugging is definitely much better than trying the form and checking all possible points of entry to various functions.

Once again, thanks for your help and I can't believe it was as simple as Data Entry = Yes paired with Allow Additions = No.

**munkee** · Aug 11 '10, 03:14 PM

I noticed a lot of the bugs are likely down to not adding a dimension to your declarations. At the top of each form module and seperate code/class modules add Option Explicit

Then before you go to run your form whilst in the VBA editor select to compile the code thsic an be found on the debug menu first option.

With option explicit set in place you will catch any typos and non dim'd declarations straight away. This saves you having to go back to the editor from the form when your code is goosed.

My final comment would be if you want to manage your upgrades better just make a test copy of the original form using the save as or copy/paste. Then delete out everything you know is broken and just start coding it fresh. I think in the long run you will spend far less time just butchering and remaking the code yourself than trying to track down the x amount of bugs/errors someone before you has left. I am a firm believer of understanding how something should run as it is intended, and I think the only way you will truly know how it should run is if you chop it all back and make it run as you wish for it to run. This way you will know all of its strengths and weaknesses.

Glad to be of help anyway sorry for the waffling on a fresh pair of eyes always seem to be the best way to solve issues in access =]

**thelonelyghost** · Aug 11 '10, 04:53 PM

The waffling is no problem at all. Actually I did gut the form (like you were suggesting) in the version I originally gave you. The process of starting and stopping work on it probably contributed to the lack of elegance in the code.

I have since implemented Option Explicit--which I thought, given the initial word, was optional. I also got to like the compiler you were explaining to me how to use.

munkee: I noticed a lot of the bugs are likely down to not adding a dimension to your declarations. At the top of each form module and seperate code/class modules add Option Explicit

If you're talking about all of the Public/Private variable declarations at the top rather than using Dim somewhere in a Function or Sub, that's only so that I can make the variable accessible across the functions. I'm not familiar (yet) with the code/class modules you're referring to.

**munkee** · Aug 11 '10, 06:34 PM

Option explicit and compiling will make a huge difference to your code. Especially the speed at which it executes. IF you do not compile your code before running a form it will have to compile itself automatically, which ofcourse means that it will be taking up processing time compiling before it actually executes anything. With that being said when it does compile it might actually find an error so your user is just stuck with a slow form which eventually just errors out anyway.

If you look at the in built access performance analyzer and run the tool on all of your forms it will come up with a suggestion to add in Option Explicit as it is a pretty common thing to be doing. Further to this when you finally distribute your program you can actually convert the file to MDE this will ensure the code is compiled and remains compiled during usage. However ensure you keep a back up of your original mdb as no design changes can be made to a mde.

For other tips etc just google for ms access form performance and vba performance. It will come up with plenty of suggestions.

Invisible Controls in Form

Invisible Controls in Form

Comment

Comment

Comment

Comment

Comment

Comment