Macros

[Janine]

Hi All,

Is there any way to see where macros are "attached" to.

I have a database that when I click on a command button it opens a report
(open via a macro). Which is fine. But it also opens the same report when I
click on another command button that opens a form. I have had a look at the
macro for opening the form and it doesn't point to the report macro. I have
also had a look ing the properties in the command button and still no clues
there.

Is there a way to see a list of where the macro is used.

Thanks
Janine

 

[storrboy]

Hi All,

Is there any way to see where macros are "attached" to.

I have a database that when I click on a command button it opens a report
(open via a macro). Which is fine. But it also opens the same report when I
click on another command button that opens a form. I have had a look at the
macro for opening the form and it doesn't point to the report macro. I have
also had a look ing the properties in the command button and still no clues
there.

Is there a way to see a list of where the macro is used.

Thanks
Janine

Not that I'm aware of, but there has to be something in the buttons
properties.
Are you saying that a form and a report open at the same time when you
click the second button?
If so, if there is no mention of the report macro in the button's
properties, it could be in on of the events of the form, OnLoad or
OnOpen perhaps.

 

[Tom Wickerath]

Hi Janine,

One of the best tools available for documenting Access applications is
called Total Access Analyzer, which is marketed by FMS, Inc.:

http://www.fmsinc.com/products/analyzer/index.html

You can use the build-in database documenter in Access, by clicking on Tools

Analyzer > Documenter. Select the form(s) and report(s) in question. Click

on the Options... button. Make sure to place a check in the option to include
Properties and Code under the section that reads "Include for Form" (or
"Include for "Report), and Names and Properties under the section that reads
"Include for Sections and Controls". Generate the documentation. This will
produce a fairly verbose report. Do not close the report yet. First, use File

Export. Choose Rich Text format (*.rtf) as the output format. Generate a

new .rtf document. You can open this document in Microsoft Word, and use the
search feature (F5) to search for the name of the macro in question. I call
this the "Poor Man's (or Woman's) Total Access Analyzer".


Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

 

[Vladimír Cvajniga]

Can Microsoft integrate a tool like this in Access? They should so!

 

[Larry Linson]

Can Microsoft integrate a tool like this in Access? They should so!

Would you be willing to pay the price that Office or Access now costs PLUS a
cost similar to the cost of FMS, Inc.'s Total Access Analyzer?

My guess is that Micosoft doubts that enough users would do so to make it
worthwhile. Software development does not come free, and its cost, plus a
markup for overhead and profit, has to be passed through to the purchasers
of the software.

Larry

 

[Vladimír Cvajniga]

No, it should be an integrated part of MS Access without any extra price.
There should be no bugs (or "issues") in Access's debugger & compiler. If
there are bugs there must be a free solution to help developer to avoid
problems.

It's my opinion.

Vlado

 

[Douglas J. Steele]

I suppose your applications have no bugs in them.

Your expectations strike me as being extremely unreasonable.

Remember, too, that Microsoft will be accused of being monopolistic if they
took away the opportunities for companies like FMS to produce 3rd party
tools.

 

[Vladimír Cvajniga]

MS could buy a license from FMS so that FMS will not be beaten in that way.
;-)
I don't think it's a monopolistic behaviour if they want to improve their
own product. Imagine yourself producing a buggy product... or GM cars that
must be improved by Volkswagen.

V.