an irrelevant question - unexplained checkbox behaviour - hardcore thi

[gusset]

if nothing else, the shows that not counting beyond one really can be beyond one...

my database (ss7) has a field (fldRelevant) which is supposed to mark the relevance of something. it is a field which holds a boolean/bit value (1 for relevant or 0 for irrelevant).

my app could simply have a chkbox which is bound to that field (checked (1) for relevance or unchecked (0) for irrelevance) - but i have decided not to. i prefer to have a chkbox which is checked (1) if the field shows irrelevance or unchecked (0) if the field shows relevance; i.e. the chkbox shows the opposite status to the value in the db.

this is the code i have which updates the field when i mousedown on the chkbox to change its state. the purpose of this code is to put the opposite value into the field to which it is unbound (if you catch my meaning):

aside: bear in mind that vb shows true as -1 (rather than +1), so although the value of recordset!fldRelevant will be 0 when the db's value is 0, it will be -1 when the db's value is +1. to get around this, i multiply the recordset's value by -1 to reverse the sign of a 1 (of either type) before subtracting one to turn 1 into 0 or 0 into -1 for the recordset (ado deals with turning this -1 back into 1 for the db):

Private Sub chkIrrelevant_MouseDown(Button As Integer, Shift As Integer, X As Single, Y As Single)
'reverses the chkbox's status for the db
'           db     recordset     vb      chk
'True       1         -1         -1       1
'False      0          0          0       0
'to make it irrelevant, turn rs -1 into  0
'                            rs  0 into -1  - reverse sign and subtract one
Adodc1.Recordset!fldRelevant = Adodc1.Recordset!fldRelevant * (-1) - 1
Adodc1.Recordset.Update
FillOrUnfillChkIrrelevant
End Sub

when i navigate to a record, i want to do the reverse, that is make the chkbox checked (1) when the db's value is 0 and make the chkbox unchecked (0) when the db's value is 1. again, the value of recordset!fldRelevant will be -1 (true) when the db value is +1. this code adds 1 to the recordset's value, turning 0 into a 1 or -1 into a 0 to arrive at the chkbox's value:

(the event i use is mousedown rather than click because another click event would be raised when the value of the chkbox is changed)

Private Sub FillOrUnfillChkIrrelevant()
'reverses the db's value for the chkbox
'           db     recordset     vb      chk
'True       1         -1         -1       1
'False      0          0          0       0
chkIrrelevant.Value = Adodc1.Recordset!fldRelevant + 1
End Sub

the strange thing is that when i check/uncheck the chkbox for the first time having reached a record, the check appears/disappears as intended but instantly returns to its state before the mousedown - an effect opposite to that intended. however, subsequent checks/unchecks on the chkbox (whilst still on that record) operate as intended - the checked status of the box is reversed and the appropriate value goes into the db. this "first time" behaviour is the bit i can't work out.

to make matters worse, this strange behaviour exhibits itself only at run-time. it behaves as intended when i step through.

does anyone have a clue what is going on?

 

[WZUP]

jez...Why...??[rofL]

 

[gusset]

that's not helpful

 

[DrJavaJoe]

I might have missed something because I didn't have the patience to read your entire post but I believe this is what you are attempting to do.

Try doing something like this while populating the form.

select case Adodc1.Recordset!fldRelevant
case 1
chkIrrelevant.Value = vbchecked
case 0
chkIrrelevant.Value = vbunchecked
end select


and something like this in chkIrrelevant's click event.
select case chkIrrelevant.Value
case vbchecked
Adodc1.Recordset!fldRelevant = 0
case vbunchecked
Adodc1.Recordset!fldRelevant = 1
end select
Adodc1.Recordset.Update

 

[WZUP]

Sorry...it seems your doing a lot of code to change the inherent property of the checkbox

I'm lost... Good Luck

 

[MichaelRed]

gusset the 'exchenge' between yourself and WZUP should noy be taken dismissed so lightly. While his initial comment was somewhat cryptic, it appears to be to quite valid. As, perhaps, demonstrated in your own efforts and to a lesser extent by DrJavaJoe, you appear to making the proverbial mountain out of the proverbial molehill. Perhaps, htere is a really good and valid rationale for the long way around approaceh, but it is not evident to me. Partof the 'help' offered here may occassionally be to question the design (thought behind) the design. As [b[WZUP[/b] some what verbosely (for him) noted in the second post, seems like a lot od (whatever) to bury a different value in the db table than is used for the display. Most well designed database applications do not look directly at the values beign stored, so their format is not normally 'relevant'. If anyone who is knowledgeable in Ms. A. ever looks into your db / code, they will almost certainly wonder why you have invested so much effort in to the transmorgafication of a simple boolean.




MichaelRed
m.red@att.net

Searching for employment in all the wrong places

 

[vbSun]

Did u write anything in the checkboxs' click event? Check that. It could be because of cascading events..

 

[gusset]

MichaelRed -

i appreciate your comment and do understand the data/formatting point. the reason for the difference between display and data is this:

although all my other checkboxes display the exact content of the db, my bosses want a checkbox that has a check in it to mark irrelevance, which is a negative concept. the conceptual problem with this is that all my other boolean fields use a positive value for a positive attribute. those querying the db for a relevant document are going to expect to write "WHERE fldRelevant = 1", just as they will write "WHERE fldIsInternal = 1" and "WHERE fldExperience = 1" etc.

i did raise your point with my bosses before i started down this track. i proposed a solution which used option buttons, but was shouted down for my efforts.

as for the vb interface, i am bound (if you'll pardon the pun) by the fact that i can't change the behaviour of a checkbox.

regarding the mountain out of a molehill comment, my explanation and comments made the code seem more complex than it was. my solution of

chkIrrelevant.Value = Adodc1.Recordset!fldRelevant + 1

is one line, whereas a case statement is several. of course, the problem (if you accept that it ought to be designed in that way at all) is easily solvable by many routes but i was only searching for the most elegant one-liner to do the job.

i thought that the point about the boolean value +-1 being represented differently in db, vb, ado and checkbox was worth making explicitly, to help other programmers who might not have actively thought about it before (like me, in fact - and Dr JavaJoe got it wrong in the second line of his code too).

finally, i have now used Dr JavaJoe's solution (thank you, btw) and moved on.

and really finally, vbSun, your suggestion was helpful. i think that you were right, although the cascade must have started with another, unknown event. when i adopted Dr JavaJoe's solution, the problem disappeared.

if there is a better way to bind a checkbox to a field's opposite value, i'd like to hear it - perhaps using API to alter the messaging?

i'll leave that for another day.

thanks to everyone who participated in this thread.

 

[billchris]

I would try placing a second, unbound, checkbox on the form. Make the bound checkbox invisible. Then use the visible checkbox to display the opposite of the bound checkbox and to update the bound checkbox behind the scenes.

I might get hairy to keep track of the events, but then it might be simpler.

“I apologize for this long letter. I didn't have the time to make it any shorter” --Blaise Pascal

 

[gusset]

thanks, billchris - the whole point of the exercise in fact was to find an elegant substitution for my invisible second checkbox! i don't like invisible controls if there is a way to do it in code. i find the timer control and the adodc control inelegant for this reason.

g

 

[MichaelRed]

gusset,

Given the explination, it makes some sense, I do offer my suympathy is having to work thrtough micro (even nano?) management. I am, perhaps, a bit 'crustaeous' to go through all of that 'sttuuffff'. I have not had / accepted any work in the last few years where 'management' gave direction on design details at that level, and have not been required to work with users who would write their own queries -but did not have the capability of understanding the datbase schema in at least it's nominal presentation. Again, my sympathy. I know that in htese difficulat times any regular postions is worth at least SOME coddling of the (whatever term suits goes here]/i]).




MichaelRed
m.red@att.net

Searching for employment in all the wrong places