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

Hi Bill,

I second the good comments about vbWatchDog -- name inspired by Shady :) Wayne is brilliant. I have the enterprise edition. You can download a trial from his site and then email me if you like it -- I'll introduce you and you might be able to work something out ...

The learning curve is steep, that is true -- because it can do a lot ... but to use the basics, which is still great, all you have to do is add it in, and then call the sample EnableWatchdog code to launch the global handler. The instructions are here:

http://www.everythingaccess.com/vbwatchdog/installation.htm

easy squeezy !

Wayne goes into a great deal of detail ... there are only a couple steps to start using vbWatchDog ...

[ Andrew, thanks for the other German link <smile> ]

Warm Regards,
Crystal

*
(: have an awesome day :)
*

--- On Thu, 9/1/11, acravenrohm wrote:

> 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
>
> --- "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
> > > > > > >
> > > > > > >
> > > > > >
> > > > >