checkbox.value misbehaviour?

[CallMeAndy]

Hi,
Updating a single Yes/No field to show if the record should be visible.
Have a continuous form with a bound checkbox to supply the new value.

OnClick event for the displayed data innitiates an immediate table update.

Values were not updating.

The problem:
However stepping through the onclick procedure in debug window shows that irrispective of the state of the checkbox checked/unchecked the value is 0.

After trace the the state is always as it should be.

Any thoughts chaps?

 

[seth_belgium]

Consider using the OnUpdate()-event.

When you use OnClick, on the moment you click the checkbox, your code will be ran first instead of changing the checkbox's value.

Hope it works!

Seth

 

[CallMeAndy]

Thanks for the help Seth,
OnUpdate occurs when any change is made to a command bar, so I am guessing you meant AfterUpdate() or BeforeUpdate()

In fact the state is set first, and then the OnClick event is processed.
But your suggestion did make me look again and in fact when I took a second look I found the culprit.

OnClick()
...
Me.Dirty= False xxxxxxxx bad boy
...
report state of checkbox
end sub

the Me.Dirty assignment caused a reset of the state of the checkbox. I needed to move this to the end of the procedure

Job done!

Consider using the OnUpdate()-event.

When you use OnClick, on the moment you click the checkbox, your code will be ran first instead of changing the checkbox's value.

Hope it works!

Seth

 

[CallMeAndy]

Why are you setting the form's Dirty property to False? If you want to save the current record, use:
DoCmd.RunCommand acCmdSaveRecord

The control's AfterUpdate event would be the best place to put the save record.

A lack of familiarity with access realy. I was manually doing a recordset update.

Anyway I changed things around as you suggested and something new has developed. The DoCmd is causing a 2046 error "cant save at this time" and halting the procedure (ironically however the state of the the checkbox is persistently changed)

The point of the immediate update is that some records in the SAME table are children of the current record and the checkbox state, sets the visibility of a records children. (done like this in order to provide a infinite-level ancestor tree so opening and closing children with the visual table NOT dirty)

I commented out the DoCmd temporarily to see if anything else untoward occured further through the procedure. THere is a further error message which was not there before. 3173 could not open the table 'MSysAccounts'
in the workgroup information file. According to help Possible causes:

The SystemDB value of the \HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\9.0\Access\Jet\4.0\Engines\Jet key in the Microsoft® Windows® Registry points to a network drive that is not connected. Make sure the network drive is available, and then try the operation again.
The System.mdw file is corrupted. If you have a backup copy of System.mdw, copy it to the location specified in the SystemDB entry in the Registry.

Firstly there is no registry key from the access level and deeper, and on inspecting the table I find there is no MSysAccounts table.

Any insight on this development appreciated - currently wading through google similar's

Thanks

 

[CallMeAndy]

A lack of familiarity with access realy. I was manually doing a recordset update.

Anyway I changed things around as you suggested and something new has developed. The DoCmd is causing a 2046 error "cant save at this time" and halting the procedure (ironically however the state of the the checkbox is persistently changed)

The point of the immediate update is that some records in the SAME table are children of the current record and the checkbox state, sets the visibility of a records children. (done like this in order to provide a infinite-level ancestor tree so opening and closing children with the visual table NOT dirty)

I commented out the DoCmd temporarily to see if anything else untoward occured further through the procedure. THere is a further error message which was not there before. 3173 could not open the table 'MSysAccounts'
in the workgroup information file. According to help Possible causes:

The SystemDB value of the \HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\9.0\Access\Jet\4.0\Engines\Jet key in the Microsoft® Windows® Registry points to a network drive that is not connected. Make sure the network drive is available, and then try the operation again.
The System.mdw file is corrupted. If you have a backup copy of System.mdw, copy it to the location specified in the SystemDB entry in the Registry.

Firstly there is no registry key from the access level and deeper, and on inspecting the table I find there is no MSysAccounts table.

Any insight on this development appreciated - currently wading through google similar's

Thanks

Ok some mistakes in my trying to dedbug this thing! I didnt realise that system tables were invisible by default, the MSysAccounts table does exist, but still getting the 3173 error. Aslo the persistence of the checkbox state was a red-herring, the 3173 error is occuring further along the procedure post record update. Also it seems the 2046 error was a consequence of setting a breakpoint on the DoCmd.

Here is an outline of the route through the procedures, hope it does not confuse - cut down for simplicity

Two routes to the 3173 runtime error
Editing a field called Pos -
or a click event for the ChildrenOpen checkbox


ChildrenOpen_AfterUpdate
DoCmd.RunCommand
' innitiates a Form_beforeUpdate and then an Form_afterupdate
SetChildrenVisibility

Form_BeforeUpdate
If Dirty
Set indentation

Form_AfterUpdate
if WasDirty
RefreshForm
Set Focus back to this record
SetParentsChildren

SetParentsChildren
if PosValueChanged
SetChildrenFlag( OldParent )
SetChildrenFlag( newParent )
SetChildrenFlag( Me )

SetChildrenFlag
Set wrkJet = CreateWorkspace("", "admin", "", dbUseJet) --------------- A DAO command halting the procedure with error 3173.

SetChildrenVisibility
Set wrkJet = CreateWorkspace("", "admin", "", dbUseJet) --------------- A DAO command halting the procedure with error 3173.