Shamil Salakhetdinov
shamil at users.mns.ru
Fri Jan 13 14:11:54 CST 2006
> only on the underlying recordsource. OK. But ?TypeName(frm.fld) AccessField ?TypeName(frm!fld) AccessField ?typename(me.controls("fld")) AccessField and ?TypeName(rst!fld) <Data type of fld field> How AccessField gets transmitted/cohersed a value to its underlaying recordset's field from recordset's field value is a big question. So intended operation was: frm!fld.value = rst!fld.Value But it happened to be something else because implicit conversion wasn't well built during compilation/run-time.. And resulted in "delayed" GPFs... And it works that badly on modern WinXP and W2K with latest SPs only.... Andy, there is no still clear answer why it worked badly and why it can't be reproduced if trying to build this case from scratch. But to search for this clear answer now would be a waste of time when bug is fixed. (Try to inform/ask MS but I doubt they will answer something definitive). To make it 100% bullet-proof in such cases I also create explicit but invisible MS Access control, name this control using naming conventions i.e. using prefixes to make control name different from underlaying recorsource field. I bind corresponding field to this control and I use CONTROL not FIELD name to assign value. Reason is that Access.AccessField is a stange hidden in Object Browser "creature" - and Access.Control (Access.TextBox, Access.ComboBox,...) are friendly and predictable built-in MS Access objects.... Then it will never fail - this rule works well since MS Access 2.0 - one of the reasons why LRNC are so great invention.... Shamil ----- Original Message ----- From: "Andy Lacey" <andy at minstersystems.co.uk> To: "'Access Developers discussion and problem solving'" <accessd at databaseadvisors.com> Sent: Friday, January 13, 2006 9:31 PM Subject: Re: [AccessD] A Dot Bang nightmare (WAS Access97 on W2000 crashes) > Thanks Shamil. > > > Is that frm.fld a checkbox? > No, you'll see from my post that fld doesn't appear on the form at all, only > on the underlying recordsource. There is no control. > > -- Andy Lacey > http://www.minstersystems.co.uk > > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of > > Shamil Salakhetdinov > > Sent: 13 January 2006 17:42 > > To: Access Developers discussion and problem solving > > Subject: Re: [AccessD] A Dot Bang nightmare (WAS Access97 on > > W2000 crashes) > > > > > > Congratulations, Andy! > > > > > although even you might be taken aback by a seemingly > > > trivial coding error that 'works' itself but causes such collateral > > > damage elsewhere. > > No, I wouldn't :) > > I did fix many issues like that - didn'ty I say there is no > > miracles in software programming and that you will sleep well > > only when you find the real cause of your trouble? > > > > I have had similar error(s) in the past with legacy code > > coming from MS Access 2.0 where dot was allowed. But in your > > case I didn't expect your code has MS Access 2.0 roots. > > > > Of course I should have recommend you to check dot vs. bang > > first of all. Sorry I didn't do that. > > > > But I did say you to analize your code for your wizard when > > you wrote that you get wizard steps automated. And to take > > close attention on your using default properties. > > > > > this one was > > > frm.fld = rst!fld > > This is exactly the case of "default properties + dot vs. > > bang nightmare". And I do remember there was a KB article or > > something like that in the past on this subject. I did try to > > find it for you but failed Then I forgot to recommend to > > check you first of all dot vs. bang code because of other > > work. My fault... > > > > Is that frm.fld a checkbox? > > > > Have a nice weekend and a good night sleep at last! > > > > Shamil > >