Linking Popup to continuous Subform

[Guest]

I have the usual form and continuous subform. In some cases there's extra
data to be entered on a line in the subform. Logically this should really go
on the subform row - but it won't fit nicely so the solution is a popup. I've
added the extra fields to the underlying table but I'm not sure how to get
the popup to access the same row. Also I seem to remember trying this before
and getting a "this record has already been updated by another user" in the
subform of the main form after I'd updated the data in the popup even though
I was in single user mode at the time!
Any ideas much appreciated.

 

[Albert D. Kallal]

I do this very often.....

Simply place a small button on the continues form. There is some screen
shots to give you some ideas....

http://www.members.shaw.ca/AlbertKallal/Articles/Grid.htm

The code behind the button will be


me.Refresh ' write data to disk
docmd.openform "frmEditDetails",,,"id = " & me!id

That is all you need...

The forcing of the disk write means that any pending edits for the record
are written to disk. This means that any changes made will be shown in the
form to edit the details (same record), and also eliminates the "this has
been edited" by someone else error...since we forced the record to
disk..then no pending writes are waiting..and thus no nag message about it
being editing by someone else...

Also, in place of a button..often people use a double click event. (but,
then you often have to put the code in for EACH control...so, I just use a
button with a set of glasses for the icon (as shown in the above screen
shots)).

 

[Guest]

Thanks for the reply: Really like the example forms. Oddly I'd been cursing
the fact I couldn't force a save (disk write) for other reasons and
accidently found refresh yesterday...

A couple of additional questions:

1. What's the difference between ! and . when refering to forms and fields
on them?

2. I'm adding to a Company Expense Claim application and the continuous form
is a line on the claim for business mileage, dinners etc. The popup is to
cover details on mileage (which won't apply to other types of expense on the
claim). Problem is that if I force refresh the line will still have a value
of zero and hence break the validation in the table. I am thinking of either
moving the validation to the VB code - I think before/afterupdate applies to
updates by the user so it won't be called then I use me.refresh? OR trapping
the error in the forms error section and ignoring it - ah can't do that can I
'cos the updates failed so I'll still get the 'someone else has updated'
message. The other thought I had was to make an unbound popup and pass the
values back to hidden fields on the continuous form? - Is there any way of
linking the fields easily or would I just have to write explicit code passing
the values back and forth?

I'm experimenting in my test database - but would really appreciate any
thoughts from someone who understands Access. Thanks again ! JP

 

[Francis]

Hello, this pst is very interesting because it actually reflects on a
question i have been asking for severall days, and still havent find
solution.


You know, Me.Refresh or DoCmd.Runcommand acSaveYes won't be able to
save your record if you have a required field hat the user hasn't yet
filled.

How do you open and populate the other form in this cases?

thanks advance
Francis

Albert D. Kallal escreveu:

 

[Guest]

Hi Francis - In the end I solved my particular problem by having hidden
fields on the continuous form and a popup which was unbound. I then simply
grabbed the values from the continuous form in the open_form part of the
popup and passed them back again in the close_form code. This sidestepped the
problem as all updates where actually being done in the continuous form
(which is bound to the table) not the popup.

The other thing I was thinking of doing was having another table (with the
same key) and having the popups fields in that table. If you needed all the
fields then you could just have a query query joining them together - I like
the way you can use queries like tables in Access. If you do try this out I'd
be interested if it works as it's just an idea and not something I've
actually done.

Hello, this pst is very interesting because it actually reflects on a
question i have been asking for severall days, and still havent find
solution.


You know, Me.Refresh or DoCmd.Runcommand acSaveYes won't be able to
save your record if you have a required field hat the user hasn't yet
filled.

How do you open and populate the other form in this cases?

thanks advance
Francis

Albert D. Kallal escreveu:

 

[Albert D. Kallal]

You know, Me.Refresh or DoCmd.Runcommand acSaveYes won't be able to

save your record if you have a required field hat the user hasn't yet
filled.

How do you open and populate the other form in this cases?

You open the other form in add mode then. Obviously, no editing will have
occurred in he sub-form if it is a new record, or if you need to add a new
record. So, simply just don't allow editing in the sub-form of that record
until you launch the new form to add that record. Case solved.... (you will
then have to code the setting of the child/link field in the form you
opened..but, that is just one line of code anyway).

If you must allow editing in the sub-form BEFORE you launch the other form,
then you have problem. The solution is to remove the required fields in the
table setting, and simply check for this in your before update event (then,
YOU CAN control this..and further you get to give your users some nice
English errors messages...and by pass the built in ones -- i would say that
I RARELY use the built in "required" setting for fields, since they often
get in the way, or produce nag messages when I don't want them to).

So, both of the above approaches are reasonable solutions to your problem...

If you look at the following screen shots (the last two), then can see that
in place of allowing users to add a new record in the sub-form, I placed a
large "+" button to add a new record, and this eliminates the problem of
required fields. Note that AFTER a record has been added, you can well see
in those screen shots that editing of the existing data in the continues
form is allowed.

http://www.kallal.ca/ridestutorialp/setdriver.htm

(take a look at the last two screens...you can see a + buttion in the
sub-forms).

 

[Albert D. Kallal]

1. What's the difference between ! and . when refering to forms and fields

on them?

Well, as a generally rule, "." refers to built in ms-access collections and
methods (functions).

User defined objects, you supposed to use ! In theory, this would mean that
since YOU add controls to a form, then we should use a ! to reference
controls on a form.

However, when you place a control on a form, then it becomes part of the
forms properties collection, so you can use "."

And, using dot is easy, since you get that pop-up list (inteli-sense).

I as rule use "." for when I reference a control on a forms. If you do NOT
expect the control to be on the form, the I
use ! (bang) to work with the data. I do this, since then you can set/grab a
value from the underling reocrdset, but NOT have to place a control on the
form. However, ms-access does confuse this, since both ".", and "!" will
work to get at the underlying reocrdset EVEN IF YOU DO NOT place a control
on the form. (however, this ONLY works if you do NOT change the forms
reocrdset at runtime).

This means that the "." is resolved at compile time, and the "!" is resolved
at runtime!. This means you if you plan to change/set the reocrdsouce of a
form in code (ie:runtime), then you HAVE TO use "!", or place a control on
the form that is bound to the reocrdset, and use ".". (if the form is
un-bound...but will *eventually* have its data source set, then you can't
use "." in your code. (try it..the code will not compile). However, you can
use "!".

So, dot always works for controls...but not for when you want the data..but
no control. This being the case, then I use "dot" when I have the control
on the screen and use ! when I just using the data on the form..and don't
necessary have a control with the same name on the form.

Many a developers actually as a rule DO NOT use the same name for controls
on a the screen as the underlying data files. This totally eliminates the
confusing. I just think it is too much extra work, but I don't fault
developers to who take this extra precaution. This extra precaution (using
different names for the controls then that of the field name in the table)
means that NO confusing can occur in code when you refer to the control on
the form, or the data that the control uses.

2. I'm adding to a Company Expense Claim application and the continuous
form
is a line on the claim for business mileage, dinners etc.

A "classic" problem. You have a amount, and must disperse that amount to
several accounts. I think every developer eventually has to do this!!! It
would certainly be one of the things I would cover if I teacher this stuff!!

Note in my screen shots, the VERY last screen does exactly just that! It is
a donations screen. Note how I don't pop up another form, but use two
sub-forms side by side. In that example, it is a amount on the left side
($50), and on the right side you see a green box with the total (if they
don't match..it is red). And, note how two entries $20, and $30 add up to
the total of $50. Further, that screen is actually designed to use keyboard
entry from START TO FINISH...you do NOT have to use the mouse!!! The data
entry person can just enter one after another...really fast....

The simply solution I used here was don't verity the amount during data
entry!!! it makes it SOOOO simple

Note very close on that example screen shot (the last one), there is posting
button on the bottom of the screen. You enter all of your data, (in my
example, donations for the day), and then when done, press the post button.
The posting routine checks for the totals to match..and you CAN NOT close
that posting until they match!. Further, users do NOT have the ability to
un-post!!! So, I don't check during data entry!!!...users MUST post/close
the entries when they are done.

This just solves everything, and actually allows the user to enter
UN-FINISHED data...users love this!!

Further, they can work real fast..and check the results AFTER they work...

Further, once posted, then I disable editing of data. If you look close at
the top of the screen, it shows the current batch has been posted..and the
post time. Editing of that data is thus disabled...

So, if you matching up to totals on the left side, and right side becomes
too difficult to verify, then simply don't check during data entry. Just
have a final "close" button that checks this for you. and, simply requite
that all staff must "post/close" there entries when done. when reports are
generated, simply show the posting status.

And, the posting routine does not actually post any data, but just runs some
code to check the totals. If the totals are all ok..then he posting simply
changes the post status to "yes", puts in the post time..and we are done....

 

[Francis]

Successfully managed to sort the database, and it's running smoothly
now.

Thanks for the contributions and suggestions you made.
Basically i'm using an unbound form linked to the subform, and i send
to this form all the information to be edited, from the subform. I pass
the arguments with a very simple to use function
http://community.netscape.com/n/pfx...yMessages&tsn=1&tid=24091&webtag=ws-msdevapps
which allows you to pass to another forms, in the OpenArgs property,
lists of arguments.

Basically i pass a lot of arguments only in one step which is very
handy.

thanks to all who contributed or gave ideas

Francis (Évora Portugal)