E
edward
OK, I know that grow/shrink only work for printing -- that one's been
asked a gazillion times here.
I've found a number of old threads on dealing with this issue. One in
particular, subject "Can grow. Can shrink problem" from March 2003 with
a great deal of technical detail provided by Dirk Goldgar, is pretty
close to what I need. The main difference is that thread dealt with a
body of text, with no columnar display needed. The code is easy to
follow; if I had a good idea on extending it to a columnar display, I'd
be in fat city. (I don't think that using a monospaced font is an
option, as I don't think I could fit the data on the screen monospaced.
But it remains a distant possibility if nothing else works.)
So here's what I want to do -- which grow/shrink would handle if they
worked on screen. I'm trying to phrase this as generally as possible --
functional spec, not design spec -- because I'm open to any reasonable
solution, including an entirely different format from what I'm showing
below. I'm writing the specs, and initially I will be the primary user.
(Don't you wish you always had the freedom that situation provides? ;-)
I could even consider another database -- may have to eventually
anyway, as this will outgrow the limits of Access unless I decide that
I can dispense with old data.
I need to display three levels of information:
First level (one occurrence)
Second level (multiple occurrences)
Third level (multiple occurrences for each second level)
All levels are single lines. Each has several fields. The first and
second levels are actually identical data, but the third level differs.
The multiple occurrences are variable in number. I can't place a hard
limit on the number, but I'd be willing to let it be less convenient
when there are more than, say, something in the range of 20 to 50. The
main thing is that it would be really inconvenient to allow for 20
lines under each second level, as that would make it difficult to see
an overview.
No updates will be done from this form. No data entry. All data in this
database comes from a batch process. As a result, nothing has to be in
bound controls, and if I could format it well enough, I could just
build a solid block of text in a single text control. Again, the
problem (combined with a strong preference for using proportional fonts
in the form) that has stopped me from working in this direction is the
need for columnar display.
Ideally I would hide all the third levels and unhide them individually
in response to a click on a control. However, if a good solution
appears which has all data visible, showing all data all the time could
work -- as long as it's shrunk to only the necessary height.
It needs to be easily legible, but not especially friendly from the
typical end-user POV, as it's a tool for developers.
I'm not scared of code -- I've probably written 200K LOC in my life,
using at least a dozen PLs, though only a few lines in VB. I'm pretty
new to Access, though, so I may have missed something terribly obvious.
Somewhat simplified, here are the tables I'm dealing with. (There's
actually some normalization, and the form will actually draw the items
from queries. But these are the items I'll display, except for the
autonumbers and FKs.)
TaskExecutions:
TaskExecution ID, autonumber
TaskName, text
BOTTime, Date/Time
EOTTime, Date/Time
JobNo, number
TaskNo, number
UserCode, text
CPUsecs, number
IOsecs, number
JobLink, number, FK to TaskExecutionID
(By way of explanation to the last item, a job is itself a task, and
all tasks are linked to the top parent job.)
FileConnections:
FileConnectionID, autonumber
FileName, text
TaskExecutionID, FK to TaskExecutions!TaskExecutionID
IntName, text
Flags, text
TxnCount, number
IOsecs, number
Level one will be the job. (In concept I might want a report with
multiple jobs, but I'm not concerned about that now. If it happened, it
would probably be a report rather than a form, with one job per page.)
Level two will be the tasks controlled by the job.
Level three will be the file connections (open/close) executed by the
task.
Thanks for reading this far ...
Edward Reid
asked a gazillion times here.
I've found a number of old threads on dealing with this issue. One in
particular, subject "Can grow. Can shrink problem" from March 2003 with
a great deal of technical detail provided by Dirk Goldgar, is pretty
close to what I need. The main difference is that thread dealt with a
body of text, with no columnar display needed. The code is easy to
follow; if I had a good idea on extending it to a columnar display, I'd
be in fat city. (I don't think that using a monospaced font is an
option, as I don't think I could fit the data on the screen monospaced.
But it remains a distant possibility if nothing else works.)
So here's what I want to do -- which grow/shrink would handle if they
worked on screen. I'm trying to phrase this as generally as possible --
functional spec, not design spec -- because I'm open to any reasonable
solution, including an entirely different format from what I'm showing
below. I'm writing the specs, and initially I will be the primary user.
(Don't you wish you always had the freedom that situation provides? ;-)
I could even consider another database -- may have to eventually
anyway, as this will outgrow the limits of Access unless I decide that
I can dispense with old data.
I need to display three levels of information:
First level (one occurrence)
Second level (multiple occurrences)
Third level (multiple occurrences for each second level)
All levels are single lines. Each has several fields. The first and
second levels are actually identical data, but the third level differs.
The multiple occurrences are variable in number. I can't place a hard
limit on the number, but I'd be willing to let it be less convenient
when there are more than, say, something in the range of 20 to 50. The
main thing is that it would be really inconvenient to allow for 20
lines under each second level, as that would make it difficult to see
an overview.
No updates will be done from this form. No data entry. All data in this
database comes from a batch process. As a result, nothing has to be in
bound controls, and if I could format it well enough, I could just
build a solid block of text in a single text control. Again, the
problem (combined with a strong preference for using proportional fonts
in the form) that has stopped me from working in this direction is the
need for columnar display.
Ideally I would hide all the third levels and unhide them individually
in response to a click on a control. However, if a good solution
appears which has all data visible, showing all data all the time could
work -- as long as it's shrunk to only the necessary height.
It needs to be easily legible, but not especially friendly from the
typical end-user POV, as it's a tool for developers.
I'm not scared of code -- I've probably written 200K LOC in my life,
using at least a dozen PLs, though only a few lines in VB. I'm pretty
new to Access, though, so I may have missed something terribly obvious.
Somewhat simplified, here are the tables I'm dealing with. (There's
actually some normalization, and the form will actually draw the items
from queries. But these are the items I'll display, except for the
autonumbers and FKs.)
TaskExecutions:
TaskExecution ID, autonumber
TaskName, text
BOTTime, Date/Time
EOTTime, Date/Time
JobNo, number
TaskNo, number
UserCode, text
CPUsecs, number
IOsecs, number
JobLink, number, FK to TaskExecutionID
(By way of explanation to the last item, a job is itself a task, and
all tasks are linked to the top parent job.)
FileConnections:
FileConnectionID, autonumber
FileName, text
TaskExecutionID, FK to TaskExecutions!TaskExecutionID
IntName, text
Flags, text
TxnCount, number
IOsecs, number
Level one will be the job. (In concept I might want a report with
multiple jobs, but I'm not concerned about that now. If it happened, it
would probably be a report rather than a form, with one job per page.)
Level two will be the tasks controlled by the job.
Level three will be the file connections (open/close) executed by the
task.
Thanks for reading this far ...
Edward Reid