how to demystify hidden objects on forms

[kattatonic1]

Howdy,

This database has been upgraded by 3 unrelated people over the last 5 years. I'm #4. I'm looking for ideas or clues to figure out what is junk, what is useful.

The following are in Design View but hidden somehow from Form View. They are of different sorts. Ideas, anyone?

1. txtHidden

• looks like a blank button without pic or text
• no Events associated with it
• Data Enabled = Yes
• Visible = Yes but it was shrunk down so small that invisible in Form View
• first in Tab Order so I'm wondering is that a focus trick?

2. Cluster Name

• this is the terminology used around here to mean business units
• looks like a combo box but
• Visible = No and formatted bright yellow to stand out in Design View
• no Control Source
• Row Source= SELECT [Input Cluster].[Cluster Identifier], [Input Cluster].Reference & " - " & [Input Cluster].Name AS name FROM [Input Cluster];
• no events associated
• there is also a regular user-used field named Cluster Name on this form.
  Its Control Source = Cluster Name
  Row Source = SELECT [Input Cluster].Reference & " - " & [Input Cluster].Name AS name, [Input Cluster].Reference FROM [Input Cluster] ORDER BY [Input Cluster].Reference;

3. ITS_id_string_calc

• Visible = No and formatted bright yellow to stand out in Design View
• Control Source = =[Project Code] & "-" & [Document Type] & "P" & [SOW-PRO-PCR number]
• no events associated

There are several like #2 and #3 on several forms so this is obviously a convention(s) to do a calculation on the form. Difference is one has a Row Source and one has a Control Source. Can I tell by looking at these what their purposes are?

4. tbProperSave and tbHidden

• they look like textboxes
• is tb for textbox? I don't use that convention
• says "Unbound" inside
• Visible = Yes but formatted so that they are invisible in Form View, same colour as form etc.
• no data or events associated

5. isdirty

• I'm familiar with the term but have never seen this. I know a changed but unsaved form is said to be "dirty".
• Visible = No but formatted bright red to stand out in Design View
• no data source and no events associated

Any comments on how to read these wins you the Internet this week.

Kay
from Toronto
learning slowly but surely

[ItsMe]

...3 unrelated people over the last 5 years...

I would take anything and everything within that ?DB with a grain of salt.

Change all Named Saved Macros to VBA
Look for names of Objects/Controls in VBA
Look at Object Dependencies using Database Tools

Focus on the task at hand and the workflow. Implement the task.

Disregard existing forms and rebuild forms according to the task at hand and the workflow. I would probably go as far as isolating the task at hand in its own app.

[June7]

I agree with ItsMe. Convert macros, if any, to VBA.

1. looks like a button but sounds like a textbox, could be a set focus trick as you conjectured

2. something tested then not fully implemented and not deleted or is there some code that makes it visible under certain conditions

3. maybe referenced somewhere in code but developer did not want it visible

4. tb for textbox makes sense, maybe referenced in code

5. maybe referenced in code

[kattatonic1]

Thank you, ItsMe and June7!

I will heed the advice. The forms are horribly jam packed and I'm to only make certain changes. Yes, focus on tasks at hand. I feel irresponsible not cleaning it up, even though I wasn't specifically asked to do that. I feel like I'm wading through landmines too. I guess I shouldn't move any of what I perceive as crap or risk creating more work for myself. Rebuilding the forms would seem to invite work too because I fear I'll be dropping functionality from some of these mysterious objects. Also, did I say jam packed ugly ugly forms? They do not want them redesigned. Okay, I just printed a focus icon and pinned it to my board.

Happy Monday,

Kay

[ItsMe]

...Rebuilding the forms would seem to invite work too because I fear I'll be dropping functionality from some of these mysterious objects...

Use the Dependencies tool for Objects and search the modules for names of variables, controls, and forms/reports/queries.

Even if you do not rebuild a form, you will need to understand the workflow and the business rules as the business rules are defined within the DB. So, if you have a proper understanding, rebuilding a form should not be that big of a deal. Maybe a better description would be to copy controls over to a new form as you determine their necessity.

Perhaps the necessity is determined more by the "task at hand" than how jumbled the form looks. Staying focused on the task at hand may necessitate copying over some of the junk.