Continuous form - control behaviour

[mcalex]

Hi all,

I have a continuous form (not a subform) with a label, text box and two toggle buttons. When I click the toggle button for a record, that toggle button changes on ALL the records in the form. Web searches indicate that unbound controls on a continuous form are all the same instance of one control, but this button is bound to a field in the query.

How do i get only the toggle button that I press to change?


A2k3:WinXP

[missinglinq]

First to do would be to doublecheck that it actually bound as you think. What field is in the Control Source? What kind of field is it bound to? Needs to be a Yes/No field.

Welcome to Bytes!

Linq ;0)>

[NeoPa]

As Linq has already indicated (very diplomatically of course) it sounds like the control is not actually bound.

Please confirm what you find so that we know you're all ok now.

[mcalex]

G'day Linq, NeoPa

thanks for replies, i'm gmt+8, so i'll double check when I get in to work tomorrow, and report. In the interim ...

Yes, I'm pretty sure the control is bound. The field is IsElected (it's a council elections db) and is Yes/No. My surety here stems from the fact I've taken the control source out and put it back in - at least i think i put it back in, now i'm doubting myself :) - to check i didn't do anything stupid. Interestingly, it seems that only the record that I click the toggle button on is changed in the database, so it's a view rather than a model problem, but I digress.

One thing I think i've done wrong (i only thought of this on the train going home) is that i've changed the query (and the underlying table) in the misbehaving form, from the original that I was using and which is used by the form that calls the problem form. Both queries use the same ID field to retrieve their data, so this may(?) explain it behaving in this manner. That rationalisation _should_ let the hindbrain get some rest tonight :-)

As promised will report back in the am (um maybe your late pm linq, otherwise tomorrow for you and NeoPa) about the boundedness, and whether changing the calling form's query to match this has any effect.

cheers
mcalex

diplomacy: lol, i've seen some of the newb postings here and fully understand

[NeoPa]

Let's see what tomorrow brings. I can't think of another explanation for that behaviour, but we can focus more precisely when we know the full story.

[Deezel]

I am a newbie, but I also have a continous form with four check/toggle boxes. All are set to Yes/No in the table and I clicked on the Code view to see what I had and this is what was there:

Option Compare Database
 
Private Sub Form_Load()
 
End Sub
 
Private Sub Handicap_Retro_Click()
 
End Sub
 
Private Sub Other_Click()
 
End Sub
 
Private Sub ReRent_Click()
 
End Sub
 
Private Sub Start_Up_Click()
 
End Sub

Maybe you're just over thinking it or there's a glitch in your form and you need to redo it. Good Luck.

[Deezel]

Oh and None of the toggle boxes are required or indexed.

[mcalex]

OK:

Yes, the ToggleButton is bound to a Yes/No field. And I did need to fix the underlying query, but that wasn't the problem

However, Deezel has pointed me towards the reason. My toggle button has 'on' and 'off' pictures (basically a red or green rectangle with No or Yes text in the middle), and I would like the button to have the correct picture depending on its state. Therefore, I am responding to the _AfterUpdate() event with a simple if (tglElected) then .Picture = "c:\path\yes.bmp"

When i comment the code in the event, the buttons work on a per record basis. When the code is there - bam! clicking one button changes them all. So it works behind the scenes, but once the button is explicitly referenced the magic is broken?

I guess that means the question is now: How do I get a custom picture (or even switch the caption between 'Yes' and 'No') on a toggle button depending on its state in a continuous form

thanks everyone

[NeoPa]

The only thing stored in a bound control is the value. Any changes to anything else will be global as you are changing the control and not the data behind it (See Why Values in Unbound Form Controls do not Persist). For that reason a Caption cannot be used for this.

A TextBox may be required to hold this value as a CheckBox has no facility for displaying the data as other than a tick that I could find.

You would have to format the Boolean value as True;False;True and add the Click functionality to toggle the value in an event procedure.

[mcalex]

g'day again NeoPa

Thanks for the textbox solution. Worked it just like you said, except I'm not sure of the 'True' before the first semicolon in your format (mine starts with the semicolon) and I added [<Colour>] after the quotes in each format section. I now have a much more visual effect than the toggle button being depressed in a continuous form - which has been the main aim of this exercise. :-)

Now, for your next trick - how do I do that with a triple-state field?

It's virtually the same situation as the now-solved 'IsElected' issue, except nulls are allowed. It doesn't look like Yes/No formats include a third option even though there are three sections to the format code.

Apologies if this question warrants a separate thread. I can't intuitively tell if it's a simple change to your text box idea, or a hack requiring a conversion of the boolean to a numeric value greater than, less than or equal to zero - but it's looking like the latter :-}

[NeoPa]

@mcalex
The semi-colons separate the three possibilities :
Positive number; Zero; Negative number
As the value False resolves to zero and True to -1, these are the only two required when you can be sure you are only ever dealing with the two boolean values True & False. To be safe though, I always handle numeric values <>-1 as well. Any non-zero value is treated as True, although only -1 is actually =True. The colour is a bonus. Sounds like you have implemented this pretty well really :)
@mcalex
Nicely thought out - and no this can stay here as it's all relevant.

Null is not a numeric value at all. That is the long and the short of it. Null formatted as anything stays as a simple Null I'm afraid. That is to say it cannot be handled by formatting.

However, all is not lost. If you know how you would like the Null to be treated it is possible, using Nz(), to treat Null values as something else in your query. This can then trigger the relevant formatting.

EG. Say you wanted it treated as False, then you could make the source for the field Nz([tglElected],0). If you wanted it to stand out from the existing True/False values then you could set it to 1 (Nz([tglElected],1)) and format it as Null;False;True, as the positive position is not otherwise used for boolean values.