|
|
In my mainform I have 2 subforms linked by child/master field to the mainform
and control button wich toggles the Enabled property of the 2nd subform.
The 1st subform is datasheet, not updatable, shows records entered thru the
2nd subform.
The 2nd subform is single-view, shows by default the last entry recordset
and have NewRecord control button.
In order to enter new record to the 2nd subform, the user is required to
first press the btnEnableToggle in the mainform, then to press btnNewRecord
on the 2nd subform.
Although it is reminded by msgBox popping after pressing btnEnableToggle,
the users ofen skip on pressing the btnNewRecord and start overrighting the
appearing record (since many conrols on it are comboboxes it goes quite
naturally).
I've failed to code either of the 2 buttons so it will execute 2 actions at
once:
1) the 2nd subform btnNewRecord can not bear
change-Enabled-Property-of-My-Form, as it sits on the form itself
2) the mainform btnEnableToggle when having added to its code
Me![2ndSubform].Form!btnNewRecord.SetFocus
DoCmd.GoToRecord , , acNewRec
sends to the new record the whole structure (the mainform and both the
subforms.
I need to to code the btnEnableToggle so it would not directly execute
GoToRecord action, but activate the btnNewRecord instead. Now the code goes
like this:
Private Sub btnEnableToggle_Click()
If Me![2ndSubform].Enabled = False Then
Me![2ndSubform].Enabled = True
Else
Me![2ndSubform].Enabled = False
End If
End Sub
Any suggestions?
|
|
Hi Mishanya,
having 3 different forms open on the same screen can be can confusing.
The business with 2 separate buttons to click just to add a new record is
also tricky for users.
Could I make some suggestions.
You could instead have 1 button for edit and 1 button for add new record,
instead of the toggle button and the new button.
The edit button would enable the subform and allow editing.
The add new button would enable the subform, set focus to the subform and
set the subform to a new record.
It would be easier if the subform was enabled all the time, if that is
acceptable.
I get around this sort of thing by opening the continuous form as a separate
form.
At the end of the row for each record on the continuous form there is a
button called something like select or edit. When user clicks this a single
form opens which allows user to edit the record they selected.
If they want to add a new record, they click the New button which sits on
the footer of the continuous form. I find this system easier to code and
manage than making 3 forms visible at the same time and using 2 different
buttons to add a new record.
Jeanette Cunningham MS Access MVP -- Melbourne Victoria Australia
"Mishanya" <Mishanya[ at ]discussions.microsoft.com> wrote in message
news:B2A68C43-C467-4B48-B045-FD7BC4735D6D[ at ]microsoft.com...
[Quoted Text] > In my mainform I have 2 subforms linked by child/master field to the
> mainform
> and control button wich toggles the Enabled property of the 2nd subform.
> The 1st subform is datasheet, not updatable, shows records entered thru
> the
> 2nd subform.
> The 2nd subform is single-view, shows by default the last entry recordset
> and have NewRecord control button.
> In order to enter new record to the 2nd subform, the user is required to
> first press the btnEnableToggle in the mainform, then to press
> btnNewRecord
> on the 2nd subform.
> Although it is reminded by msgBox popping after pressing btnEnableToggle,
> the users ofen skip on pressing the btnNewRecord and start overrighting
> the
> appearing record (since many conrols on it are comboboxes it goes quite
> naturally).
>
> I've failed to code either of the 2 buttons so it will execute 2 actions
> at
> once:
> 1) the 2nd subform btnNewRecord can not bear
> change-Enabled-Property-of-My-Form, as it sits on the form itself
> 2) the mainform btnEnableToggle when having added to its code
> Me![2ndSubform].Form!btnNewRecord.SetFocus
> DoCmd.GoToRecord , , acNewRec
> sends to the new record the whole structure (the mainform and both the
> subforms.
>
> I need to to code the btnEnableToggle so it would not directly execute
> GoToRecord action, but activate the btnNewRecord instead. Now the code
> goes
> like this:
>
> Private Sub btnEnableToggle_Click()
>
> If Me![2ndSubform].Enabled = False Then
> Me![2ndSubform].Enabled = True
>
> Else
> Me![2ndSubform].Enabled = False
> End If
>
> End Sub
>
> Any suggestions?
|
|
Hi Jeanette!
Actually my project is much more sofiisticated. The mainform (The Client
Window) consists of multiple sub- and subsub- forms based on quite elaborate
queries and nested partly as tab controls, partly alone, and of groups of
controlbuttons to open other general forms and reports (with different link
criteria dependent on the respective subform topic) and even of one chart.
Basically all the client-related data is presented simultaniously and the
main cboClientID reloads the whole picture.
The idea was to build all-in-one workplace,something like StockExchange
monitor, where multiple subwindows are open simultaniously and allow to watch
all the information just-in-tme.
Initially I've tried to set the "transaction window" Entry property to Yes,
so it would be add-only form, but since it is sub-subform and its recordset
is reloaded from grandmother form click event, the Entry property is being
overritten. That's why I've set its Enable property to NO (so the user can
only see the last saved entry, but can not incidentally mess it up). In fact,
the user does not need to see any old record in this subwindow, but I can't
work it out.
The Enable+GoToNew button would be a nice solution, but I see that it is too
complicated.
Anyway, thank U very much for Your kind reply.
Happy New Year!
"Jeanette Cunningham" wrote:
[Quoted Text] > Hi Mishanya,
> having 3 different forms open on the same screen can be can confusing.
> The business with 2 separate buttons to click just to add a new record is
> also tricky for users.
>
> Could I make some suggestions.
> You could instead have 1 button for edit and 1 button for add new record,
> instead of the toggle button and the new button.
> The edit button would enable the subform and allow editing.
> The add new button would enable the subform, set focus to the subform and
> set the subform to a new record.
>
> It would be easier if the subform was enabled all the time, if that is
> acceptable.
>
>
> I get around this sort of thing by opening the continuous form as a separate
> form.
> At the end of the row for each record on the continuous form there is a
> button called something like select or edit. When user clicks this a single
> form opens which allows user to edit the record they selected.
>
> If they want to add a new record, they click the New button which sits on
> the footer of the continuous form. I find this system easier to code and
> manage than making 3 forms visible at the same time and using 2 different
> buttons to add a new record.
>
>
> Jeanette Cunningham MS Access MVP -- Melbourne Victoria Australia
>
>
> "Mishanya" <Mishanya[ at ]discussions.microsoft.com> wrote in message
> news:B2A68C43-C467-4B48-B045-FD7BC4735D6D[ at ]microsoft.com...
> > In my mainform I have 2 subforms linked by child/master field to the
> > mainform
> > and control button wich toggles the Enabled property of the 2nd subform.
> > The 1st subform is datasheet, not updatable, shows records entered thru
> > the
> > 2nd subform.
> > The 2nd subform is single-view, shows by default the last entry recordset
> > and have NewRecord control button.
> > In order to enter new record to the 2nd subform, the user is required to
> > first press the btnEnableToggle in the mainform, then to press
> > btnNewRecord
> > on the 2nd subform.
> > Although it is reminded by msgBox popping after pressing btnEnableToggle,
> > the users ofen skip on pressing the btnNewRecord and start overrighting
> > the
> > appearing record (since many conrols on it are comboboxes it goes quite
> > naturally).
> >
> > I've failed to code either of the 2 buttons so it will execute 2 actions
> > at
> > once:
> > 1) the 2nd subform btnNewRecord can not bear
> > change-Enabled-Property-of-My-Form, as it sits on the form itself
> > 2) the mainform btnEnableToggle when having added to its code
> > Me![2ndSubform].Form!btnNewRecord.SetFocus
> > DoCmd.GoToRecord , , acNewRec
> > sends to the new record the whole structure (the mainform and both the
> > subforms.
> >
> > I need to to code the btnEnableToggle so it would not directly execute
> > GoToRecord action, but activate the btnNewRecord instead. Now the code
> > goes
> > like this:
> >
> > Private Sub btnEnableToggle_Click()
> >
> > If Me![2ndSubform].Enabled = False Then
> > Me![2ndSubform].Enabled = True
> >
> > Else
> > Me![2ndSubform].Enabled = False
> > End If
> >
> > End Sub
> >
> > Any suggestions?
>
>
>
|
|
Mishanya wrote:
[Quoted Text] >Actually my project is much more sofiisticated. The mainform (The Client
>Window) consists of multiple sub- and subsub- forms based on quite elaborate
>queries and nested partly as tab controls, partly alone, and of groups of
>controlbuttons to open other general forms and reports (with different link
>criteria dependent on the respective subform topic) and even of one chart.
>Basically all the client-related data is presented simultaniously and the
>main cboClientID reloads the whole picture.
>The idea was to build all-in-one workplace,something like StockExchange
>monitor, where multiple subwindows are open simultaniously and allow to watch
>all the information just-in-tme.
>Initially I've tried to set the "transaction window" Entry property to Yes,
>so it would be add-only form, but since it is sub-subform and its recordset
>is reloaded from grandmother form click event, the Entry property is being
>overritten. That's why I've set its Enable property to NO (so the user can
>only see the last saved entry, but can not incidentally mess it up). In fact,
>the user does not need to see any old record in this subwindow, but I can't
>work it out.
>The Enable+GoToNew button would be a nice solution, but I see that it is too
>complicated.
If users do not need to see any pre-existing records in the
transactions subform, I think you can avoid all this messing
about with enabled/gotonew/whatever and just limit the
subform's record source query to return an empty recordset.
This is easy to do by setting its Where clause to a criteria
that is always false. For performance reasons, I suggest
that you use an indexed field compared to an impossible
value (e.g. WHERE ID=0) instead of just using WHERE False.
--
Marsh
MVP [MS Access]
|
|
Marsh!
You blow my nind!
I've been tempering with this issue for a couple of months now, trying all
kinds of elaborate tricks in order to "rape" the Access rules, but never got
close to solution.
And yet, as Hercule Poirot would say, the solution is so simple it makes it
genious!
Thank You very much indeed!!!
Happy New Year!
"Marshall Barton" wrote:
[Quoted Text] > Mishanya wrote:
> >Actually my project is much more sofiisticated. The mainform (The Client
> >Window) consists of multiple sub- and subsub- forms based on quite elaborate
> >queries and nested partly as tab controls, partly alone, and of groups of
> >controlbuttons to open other general forms and reports (with different link
> >criteria dependent on the respective subform topic) and even of one chart.
> >Basically all the client-related data is presented simultaniously and the
> >main cboClientID reloads the whole picture.
> >The idea was to build all-in-one workplace,something like StockExchange
> >monitor, where multiple subwindows are open simultaniously and allow to watch
> >all the information just-in-tme.
> >Initially I've tried to set the "transaction window" Entry property to Yes,
> >so it would be add-only form, but since it is sub-subform and its recordset
> >is reloaded from grandmother form click event, the Entry property is being
> >overritten. That's why I've set its Enable property to NO (so the user can
> >only see the last saved entry, but can not incidentally mess it up). In fact,
> >the user does not need to see any old record in this subwindow, but I can't
> >work it out.
> >The Enable+GoToNew button would be a nice solution, but I see that it is too
> >complicated.
>
>
> If users do not need to see any pre-existing records in the
> transactions subform, I think you can avoid all this messing
> about with enabled/gotonew/whatever and just limit the
> subform's record source query to return an empty recordset.
> This is easy to do by setting its Where clause to a criteria
> that is always false. For performance reasons, I suggest
> that you use an indexed field compared to an impossible
> value (e.g. WHERE ID=0) instead of just using WHERE False.
>
> --
> Marsh
> MVP [MS Access]
>
|
|
|