Get current line number in module

[Kevin]

Folks,

Is there a way to return the line number of the current
line in a module? Not the currently-executing line, mind
you, but, in a module which is open for viewing/editing,
the line on which the cursor rests.

I know that the ProcOfLine property will return the name
of the property in which a given line number resides, but
how can I find the line number?

TIA for any help you can provide!

Kevin

 

[Glen Appleton]

Hi Kevin,

In the standard toolbar within the IDE, you should see the column and line
numbers displayed after the Help icon. They are shown like "Ln 50, Col 7".

Hope this helps,
- Glen

 

[Guest]

Glen,

I guess I should've mentioned that I'm running Access97...

I have no such column and line indicators on any of my
toolbars...

Is there perhaps an API that I could access...?

Kevin

 

[TC]

Using various win32 calls, you could get the position & size of the module
window, & the position of the cursor, & height of each line in the window
(given its typeface & pointsize). From all that stuff, you could possibly
work out the line # where the cursor is. But, that would be relative to the
top of the window ie. it would always start at 1). To get the line number
*in the file* would not be possible without a humungous amount of complex
api programming.

What are you actually trying to do?

TC

 

[Kevin]

Bummer...

Thanks, gentlemen!

-----Original Message-----
Don't think so. Access 97 has a different version of VBA, and a different
editor, and I don't believe anything like what you're looking for exists.

--
Doug Steele, Microsoft Access MVP






.

 

[Kevin]

I have an Access 97 application that consists of dozens of
tables, 150 forms, 130 reports, 210 queries, and a couple
dozen code modules. It is in continual development, with
multiple tasks in work at any given time.

I need to be able to be able to document for my clients
what I've done on a weekly basis, and I'm too busy (or too
scatter-brained) to keep a manual log of each
form/table/report/module/query that I've modified each day.

I've created a simple form named frmDevTracking. This form
uses a Timer event which enumerates the
Forms, Modules, and Reports collections, returning the
object type, name, mode (i.e., whether a module is a
standard module or a class module), and a timestamp for
each open member of the collection. These are written to a
table named tblDevTracking. I set the form's timer
interval to some suitable value such as 360000 (six
minutes, or one-tenth of an hour). This form basically
sits quietly and collects information on all forms,
modules, and reports that are open when the timer fires,
and stores the data for processing later.

A second form (frmDevActivityReport) reads the collected
information, calculates a rough value of how long each
object is open, saves the summarized information to
another table (tblDevActivitySummary), and prints a report
showing each object name, mode, time it was opened, and
how long it was opened, by date for a specified date
range. The results are obviously dependent on the timer
interval specified, and this method won't catch an object
that is opened and closed between consecutive firings of
the timer, but it will give me a rough idea of what I
spend my time on during the course of a day.

If I could somehow determine the cursor position in a
given module window at timer fire, I could record the name
of the procedure in which I was working at the time,
rather than just the name of the module. Obviously,
knowing which procedure had my attention at a the time
would be more useful in the desired end result.

I just have a hard time accepting the idea that there is
no way to grab the cursor position. I mean, the
interpreter has to track that stuff, right?

I guess I'm wasting too much time on it - but I'm so
danged close!

Kevin

 

[TC]

I think you'd find one of the following two methods easier!

(A) Write a procedure which:
1. uses the (undocumented) SaveAsText method to save a textfile
representation of each of your forms, reports & modules etc.
2. compares those textfiles to the ones from yesteray, then
3. updates another text file (or database table) with the list of what has
changed.

Then you would just run that procedure manually at the end of each day.

(B) My own practice is to have a maintenance log at the start of each code
module, & add an entry whenever I make a change. Then I have a simple add-in
which scans all form, reports & standard modules for entries on, before, or
after, a specified date (depending on user selection). That way I know
precisely what has changed.

Either of the above two methods will be waaaaaaaaaaaaaay easier than doing
what you are trying to do.

HTH,
TC

 

[Kevin]

BUT I'M SO CLOSE!!! :-(

The reason that I took the approach that I did is because
I'm too lazy - er, I mean "too busy" - to make manual
entries in the code each time I make a change. I guess
I'll just have to enforce some self-discipline, eh? ;-)

Thanks for your suggestions, TC. I prefer approach #2...

If the Access-Programming fairy visits me in the middle of
the night and imparts some wisdom that enables me to find
the Holy Grail of current line number, I'll be sure to
post it for everybody...

Kevin