ACCESS FEED: [MS_AccessPros] Re: Sub-Formular becomes "Disabled" Access 2007

Hi Bill,

If you haven't tried EverythingAccess.com vbWatchdog you owe it to yourself to spend a little time with it. I am not associated with them and I would say there's a steep learning curve but it's not a very high one and it's been worth the (slight) effort for me. If you have tried it and had problems, try it again but with the variable inspector switched off for the end-user experience.

Global "how am I going to handle errors" constants, "if" statements on them, and commenting out "on error ..." statements are a thing of the past for me now with vbWatchdog.

Even the best seat belts and airbags won't stop you actually Crashing but they will keep you alive in many circumstances...

Oh, did I say 16 years? My, how time flies... Actually I've been working on the current productline for 16 Years, and I started working with Access when the unusable 1.0 Version came out around the end of '92 but work really started with 1.1 sometime around the middle of '93 ... *now* I feel old :o)

Andrew

--- In MS_Access_Professionals@yahoogroups.com, "Bill Mosca" <wrmosca@...> wrote:
>
> Andrew
>
> I use an error trap setup that is dependent on a global constant.
> If gbolErrorTrapOff = False Then On Error GoTo err_PROC
>
> My use of On Error Resume Next is *very* limited. And a simple find & replace within a form's code can change it to a comment.
>
> But as you mentioned, any Cancel parameter is not going to be stopped that way.
>
> 16 yrs! Wow! You started around the same time as I did. And I still pick up new Access stuff with almost every new project.
>
> Bill
>
> --- In MS_Access_Professionals@yahoogroups.com, "acravenrohm" <yahoo@> wrote:
> >
> > You are right of course Bill.
> >
> > In this case I was so sure that it was "new behaviour" that it never occured to me that a BeforeUpdate (especially as there *is* no explicit update) would be triggered, and that further, this routine has a line saying:
> >
> > Cancel = Not bAllowedToChange Or Not bDoingSave
> >
> > I now know better (and have replaced the line with a more specific check.)
> >
> > I am using EverythingAccess.com's vbWatchdog and my global error handler already warns me (in development mode) of errors occuring during "On Error Resume Next" so I (normally) know I don't have to mess around there anymore. If had suspected there might be a problem with ignored errors, I would have done what I used to do, set the VBIDE Option to stop on all errors, rather than trying to find and comment out any "On Error Resume Next" Lines.
> >
> > Yours, with sixteen years Access experience and still capable of being caught out :-) ,
> > Andrew
> >
> > --- In MS_Access_Professionals@yahoogroups.com, "Bill Mosca" <wrmosca@> wrote:
> > >
> > > Andrew
> > >
> > > When debugging code it is usually wise to comment out lines like On Error Resume Next -or- Cancel = -1
> > >
> > > That way you can let the thing break on the error or you can step through th ecode to see what is going on with each line.
> > >
> > > Regards,
> > > Bill Mosca, Founder - MS_Access_Professionals
> > > http://www.thatlldoit.com
> > > Microsoft Office Access MVP
> > > https://mvp.support.microsoft.com/profile/Bill.Mosca
> > >
> > >
> > >
> > > --- In MS_Access_Professionals@yahoogroups.com, "acravenrohm" <yahoo@> wrote:
> > > >
> > > > Hi Crystal, Thanks for your ideas,
> > > >
> > > > One thing I forgot to mention and the reason why I was a bit wooly about how I linked the Forms, is that I'm using the German Version of Access.
> > > >
> > > > Yes, I was using the LinkMaster and LinkChild Fields in the design but this is the Link I removed, to no effect. I'm now setting the Recordsource in the subform (code behind) using a "WHERE" clause with the ArticleID as a number and not as a parameter like Forms!...!... (for example WHERE ArticleID = 1234) so there's no artificial Dependancy here.
> > > >
> > > > There's nothing special/strange/difficult/clever in the Table design, there's not even a relational link between the two tables let alone one with referential integrity (a database designer would throw up his/her hands in horror.)
> > > >
> > > > The Form_BeforeUpdate Event sets ChangeDate and ChangePers Fields but stopping it do this doesn't change the behaviour.
> > > >
> > > > However... Your idea of stepping through the BeforeUpdate Event has brought the answer, thanks...
> > > >
> > > > The BeforeUpdate Event doesn't get fired of course until the record is to be saved. Attempting to set the focus to the SubForm fires the BeforeUpdate Event and this routine, for some reason, sets the Cancel to true and silently stops the focus changing... dooohhhhh!!!!!!
> > > >
> > > > So, just need to find out what the silent Cancel is *really* supposed to be preventing and, mystery solved. Thanks (again)
> > > >
> > > > So, that's Many Thanks :-)
> > > >
> > > > --- In MS_Access_Professionals@yahoogroups.com, Crystal <strive4peace2008@> wrote:
> > > > >
> > > > > Hi Andrew,
> > > > >
> > > > > Are you linking with the LinkMasterFields and LinkChildFields properties? Or are you embedding criteria in the subform RecordSource?
> > > > >
> > > > > Is there anything in the table design that would prevent the record in the main table from being saved? Like maybe Required is true, a ValidationRule, or a bad default value on a field that is the foreign key to a relationship with referencial integrity?
> > > > >
> > > > > Do you have a form BeforeUpdate event?
> > > > >
> > > > > My guess is that the answer lies in the code (and/or macros) ... post the code behind the form. If macros are called, trace them and make a Word document with screen shots you can post.
> > > > >
> > > > > Click on a control and look at the EVENTS tab in the Properties window. If anything is there, click on the property value, and then click the Builder Button [...] that appears to the right.
> > > > >
> > > > >
> > > > > Warm Regards,
> > > > > Crystal
> > > > >
> > > > > Access Basics by Crystal (Bill Mosca's site)
> > > > > http://thatlldoit.com
> > > > > Free 100-page book that covers essentials in Access
> > > > >
> > > > > *
> > > > > (: have an awesome day :)
> > > > > *
> > > > >
> > > > >
> > > > > --- On Sat, 8/27/11, acravenrohm wrote:
> > > > >
> > > > >
> > > > > > This seems to be something changed
> > > > > > recently but perhaps I just didn't notice it before.
> > > > > >
> > > > > > In short, data changes on a form make (some) subforms
> > > > > > "locked".
> > > > > >
> > > > > > I have a (non-continuous) form that is based on a Table
> > > > > > linked from an SQL Table. The Table has an IDENT, that is
> > > > > > not used, and an ArticleID Field. A (continuous) Subform is
> > > > > > based on another Table holding prices also linked in from
> > > > > > SQL Server. Originally the subform was populated using the
> > > > > > usual linkin of the form properties so that access
> > > > > > automatically showed the prices for each article as the user
> > > > > > chose an article. All well and good and normal.
> > > > > >
> > > > > > On the subform there's a combobox to select the
> > > > > > price-gourp, a text box to enter the price and a button to
> > > > > > add these unbound values into the table (per VBA but this is
> > > > > > irrelevant.)
> > > > > >
> > > > > > I'm fairly sure this has worked since as long as I can
> > > > > > remember but now, it doesn't. As soon as the main form gets
> > > > > > dirty (any change in the bound article data) the subform is
> > > > > > "kind of" disabled. "Kind of" means that the subform looks
> > > > > > completely normal, no field is grey, the button is not
> > > > > > greyed, and as the mouse cursor moves over the textfield it
> > > > > > turns into the caret.ï¿½ However, the combobox can't be
> > > > > > droppeddown, the textbox doesn't take the focus and the
> > > > > > button can't be pressed.
> > > > > >
> > > > > > Anyone know how to fix this?
> > > > > >
> > > > > > I thought, "OK, the problem is Access might think I'm
> > > > > > changing the key field and so stops anything bad happening
> > > > > > by deactivating the linked Subform." Unfortunately no.ï¿½
> > > > > > I removed the link between the two forms and used code to
> > > > > > ensure that the subform just shows the records from the
> > > > > > selected article and, no change.ï¿½ The slightest change
> > > > > > in the Article form blocks the pricetable subform.
> > > > > >
> > > > > > Any ideas or links to knowledge *why* this is and how to
> > > > > > fix it?
> > > > > >
> > > > > > Many thanks in advance,
> > > > > > Andrew
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>