 | |
Max number of controls on a form in A2010
comp.databases.ms-access comp.databases.ms-access
 |
| | Thread Tools | Display Modes |
#21
 
| |||
| |||
|
Re: Max number of controls on a form in A2010 -
05-05-2011
, 05:00 PM
|
The form will be a main form, not a subform, with its own navigation controls. I already made an analoguous system based on weeks (for renting gŒtes). All of this could be done with continuous subforms and judicious use of outer joins (to a table with records that represent the time slots). |
Yes sure, it could...
But this approach fits perfectly in my systematics of using meta data
on generalized forms.
Besides of that, I have far more control over the Controls than in a
continuous form (see previous post).
Imb.
#22
| |||
| |||
|
|
… unless the 100 repeating controls all run through the same routine for that event, with the control as parameter. And when you need 120 controls you have to change the code that walks through them, after adding the new controls. With the normalized data structure, there's no coding, no editing of forms. I cannot speak for JB, but in my approach: After initial design of the form, there is no editing of the form anymore. The data is normalized in the Job table. This form is a display form, where you have individual control over the Controls in terms of width, height, backgroundcolour, number of slots, number of columns, etc, but you have direct access to the Job table for creating new Jobs, edit them or delete them. |
140, then you have to edit the form. In a properly normalized
structure, your form displays 120 before the change, and 140 after,
with no design changes to the form at all.
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
#23
| |||
| |||
|
|
The form will be a main form, not a subform, with its own navigation controls. I already made an analoguous system based on weeks (for renting gŒtes). All of this could be done with continuous subforms and judicious use of outer joins (to a table with records that represent the time slots). Yes sure, it could... But this approach fits perfectly in my systematics of using meta data on generalized forms. Besides of that, I have far more control over the Controls than in a continuous form (see previous post). |
form, other than have different characteristics for the individual
instances of the controls? I thought we were talking about a form
where there were 120 repeating controls that were identical (or a
group of N controls that repeated, where N is some number that
evenly divides 120)?
Maybe we're talking past each other because we're not discussing the
same kind of form. I'm discussing the case introduced in this thread
(unless I completely overinterpreted the original description of
it).
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
#24
| |||
| |||
|
|
But if the number of fields in your table changes from, say, 120, to 140, then you have to edit the form. In a properly normalized structure, your form displays 120 before the change, and 140 after, with no design changes to the form at all. |
I have never that many fields in a table. The maximum is about 30, and
that was because it was based on an (existing) not completely
normalized table.
In this specific case – the form with the maximum number of controls –
the number of needed controls is not determined by the number of
fields in the table, but by the accuracy in which I want to see
certain details.
For instance, the record in the table stores begintime and endtime of
a job, and the form shows the graphical representation of this job in
relation to other jobs, on a time base per quarter of an hour, with 7
columns parallel for each day of the week.
In those cases I am interested in the distribution of the jobs over
time with respect to some caracteristics of the jobs, but also in the
distribution of the not yet occupied time periods.
There is no "record relation" between the controls, but only some time
or space relation, or som other kind of organizational relation.
Imb.
#25
| |||
| |||
|
|
Maybe we're talking past each other because we're not discussing the same kind of form. I'm discussing the case introduced in this thread (unless I completely overinterpreted the original description of it). |
So the original question could have still another meaning.
Imb.
#26
| |||
| |||
|
|
But if the number of fields in your table changes from, say, 120, to 140, then you have to edit the form. In a properly normalized structure, your form displays 120 before the change, and 140 after, with no design changes to the form at all. I have never that many fields in a table. The maximum is about 30, and that was because it was based on an (existing) not completely normalized table. |
about a form that had 120 controls, each corresponding to a field (I
think -- dunno for sure). The design contemplated was one that would
require a change to the form if fields were added, and that's why
I'm arguing for a normalized data structure, along with a completely
normalized user interface.
[]
Quote:
|
There is no "record relation" between the controls, but only some time or space relation, or som other kind of organizational relation. |
that you have records displayed that represent data that hasn't yet
been entered. Here's a form with ugly colors, but it shows the idea:
http://dfenton.com/DFA/examples/NKF/Meds.jpg
There are NO RECORDS for medications recorded for the patient in
question. But there are fields ready to accept data (all using outer
joins with the table of possible medications to create a single row
for each medication). So, there are 28 medications, and 28 rows.
When the users need to add medications, they just add them to the
table of medications, and this form will then have 29 or 30 or 40 or
100 rows.
That's the principle I'm describing. I don't know if it relates to
what you're doing or not, which seems to me to be tangential to my
understanding of what was being discussed in this thread.
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
#27
| |||
| |||
|
|
imb <im... (AT) onsmail (DOT) nl> wrote innews:ea00504e-a253-4207-81eb-07011c39cb42 (AT) z19g2000yqz (DOT) googlegroups.co m: But if the number of fields in your table changes from, say, 120, to 140, then you have to edit the form. In a properly normalized structure, your form displays 120 before the change, and 140 after, with no design changes to the form at all. I have never that many fields in a table. The maximum is about 30, and that was because it was based on an (existing) not completely normalized table. Well, that may very well be, but the discussion IN THIS THREAD was about a form that had 120 controls, each corresponding to a field (I think -- dunno for sure). The design contemplated was one that would require a change to the form if fields were added, and that's why I'm arguing for a normalized data structure, along with a completely normalized user interface. [] There is no "record relation" between the controls, but only some time or space relation, or som other kind of organizational relation. This can still be done on a form using tables that map metadata, so that you have records displayed that represent data that hasn't yet been entered. Here's a form with ugly colors, but it shows the idea: *http://dfenton.com/DFA/examples/NKF/Meds.jpg There are NO RECORDS for medications recorded for the patient in question. But there are fields ready to accept data (all using outer joins with the table of possible medications to create a single row for each medication). So, there are 28 medications, and 28 rows. When the users need to add medications, they just add them to the table of medications, and this form will then have 29 or 30 or 40 or 100 rows. That's the principle I'm describing. I don't know if it relates to what you're doing or not, which seems to me to be tangential to my understanding of what was being discussed in this thread. -- David W. Fenton * * * * * * * * *http://www.dfenton.com/ contact via website only * *http://www.dfenton.com/DFA/ |
No, the controls on the form are *all* unbound. The (relevant) fields
in the table(s) are JobNumber, Engineer, ActionDate, ActionDuration
(hrs - but in 15 minute chunks so 1.25 = 1hr 15mins),
ActionDescription and a new field ActionStartTime. The last field is
the only new field in the existing data. There is other stuff, of
course, but these are the relevant fields.
I devised a naming system so that the control name enabled me to
establish the ActionDate and the time slot which means that reading/
writing to the tables is easy in VBA.
In the form there are 7 columns (for the days) each with 72 rows of 2
controls - JobNumber (a dropdown) and ActionDescription. John Spencer
gave the suggestion to place each column in a separate subform - works
great.
What the client wants is to be able to view and enter Engineer's work
in a kind of time sheet (displaying from 06:00 to 24:00 for all 7 days
in a selected week) in 15 minute time slots. This means having 144
controls per day x 7 for the week (plus a few more to select the week
and engineer and some bits and pieces). The 144 controls *could* each
hold distinct data (where an Action has a duration of 15 mins) but in
practice the first control in a vertical block holds the
ActionDescription and the rest of that block hold 'ditto' characters
(I used ###). So there might be a vertical block of 10 controls all
referring to the same Action where the Duration is 2hr 30min.
I wrote a function to fill the time sheet once a week has been
selected, with the JobNumber and ActionDescription in the first
control and dittos underneath where the Action has a duration >
15mins.
When a User enters a new ActionDescription they have a pop-up to
gather the Duration and the data is written to the relevant table and
the ditto characters are written to the unbound controls.
There are some 3 or 4 functions which do all the work (such as
checking the duration will 'fit' before writing anything) so modifying
is quite straightforward.
I quite agree that hundreds of bound controls (implying hundreds of
underlying fields) would probably indicate a dreadful table structure!
Had I started from 'scratch' I may well have thought along the lines
of sub-tables to hold the data but I dunno. I'm not willing to spend
very long on a 'what if' situation but it seems to me that storing the
ActionStart and the Duration is the most efficient way. Certainly I
would not store 10 rows just because the Action took 2hr 30mins. In
that case, to display a time sheet with 15 minute time slots, sort of
drives you into unbound controls to display the 'dittos'.
Anyway, it seems to work well - but I'm one of the world's worst
testers (too impatient). It goes to the Client for a trial next
week ...
JB
#28
| |||
| |||
|
|
No, the controls on the form are *all* unbound. The (relevant) fields in the table(s) are JobNumber, Engineer, ActionDate, ActionDuration (hrs - but in 15 minute chunks so 1.25 = 1hr 15mins), ActionDescription and a new field ActionStartTime. The last field is the only new field in the existing data. There is other stuff, of course, but these are the relevant fields. |
a way that presents all the controls for the users to fill out and
having none of them unbound, and with no need to deal with naming
conventions or anything else of the sort.
Basically, it's done with outer joins to tables (or SQL statements)
where you have one record for each group of controls that would be
in the unbound form.
It's a much more flexible setup, as adding items means you don't
have to do anything but edit the table that lists the possibilities
(as in the medications example I posted elsewhere).
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.