Checkbox field behaving strangely

[Kent Searight]

Hi all,

I have a solution that uses a checkbox field that worked just fine until...for no apparent reason the checkbox field is behaving erratically. Here's the situation:

I have a checkbox field on a layout that appears in a "popup" new window when the user wants to add keywords, or searchwords, to a record. The look and feel is much like MS Outlook when you assign a category to a record. Anyway, everything was functioning properly until, for no apparent reason, the checkbox field has "gone nuts". I can check and uncheck the first 10 values as one would expect. When I try to do the same to values 11-20 nothing happens. Then when I try to check/uncheck values 21-23, those checkboxes remain in the same state but the checkboxes that are 9 values lower change state from checked or unchecked.

Aaargh!!! Needless to say, I'm pulling my hair out. I've tried file maintenance, restarting FMP, nothing seems to matter. I've searched the web for this problem and I come up with zilch.

Any help on this will be greatly appreciated.

[-Queue-]

Duplicate the field on the layout and format it as a normal edit box, making it deep enough to display a maximum number of selections. Select and deselect different values from the checkboxes and see what data is added/removed from the edit box. This may help you narrow down the issue.

[Kent Searight]

Good advice, -Queue-, but for once I was a step ahead of you - I'd already done that. Here's what I can tell you thus far:

The erratic behavior I mentioned would indeed show up in the normal edit box.

Then I found something even more intriguing...If I changed the font size or the field's physical dimensions I would get the same behavior but with different values. That led me to speculate that the field itself was problematic, so I deleted it and created a new field from scratch on the layout.

Lo and behold, the new field behaves as one would expect. I've gone over my layout with the proverbial fine-tooth comb and can't find anything hidden like a button or a field that may have been overlapping my original field. And before deleting the "problem" field I made absolutely sure that the field's properties were correct, i.e. no auto-enter calc that might return unexpected results. The only thing I can think of is that I probably created the original field by Control-Click dragging another field, (how I usually add fields to layouts) and the checkbox field "inherited" something from the field it was duplicated from. Is this known to happen???

I now have a functional checkbox field (again) but I'm understandably nervous about passing it on to the client when the project is due in a couple of weeks. I'll test it rigorously, of course, but not knowing a reason for the behavior

is a little unsettling.

[Kent Searight]

??? I went back and retraced my steps in creating the checkbox field on the layout and I replicated the problem. It was something inherited from the field I Control-Click dragged. That field is an auto-enter calc that concatenates the values checked in the checkbox field. But even in my replicated problem field, there's no sign of the auto-enter calc or anything else unusual. But obviously something from the auto-enter field carries over to the checkbox field.

Well, hopefully the mystery is solved and others can learn from this strange phenomenon. I know that in the future I'll be more selective about which fields on a layout I duplicate in order to add new fields to a layout.

[-Queue-]

That sounds very, very wrong to me. Do you still have the original file? If so, could you send me a clone to investigate?

[Kent Searight]

Hi -Queue-,

I'm happy to hear that you want to get to the bottom of this. I'm still not satisfied with what I've found so maybe you'll have better luck.

I've created 2 files, 1 Working, 1 NotWorking. "Working" behaves as one would expect, "NotWorking" has the strange behavior. Please notice that many of the last values don't even react to a click, but the last value, "Vase" actually sets the value "Negative Ions". Also, play around with the font size and the field size of the checkbox...it actually affects HOW it behaves strangely, i.e. changing what happens when you click on some of the last values.

Now, the one thing I couldn't replicate is duplicating the problem by making the checkbox field from the text calc field. So I copied and pasted the original field from my project into the popup window layout in "NotWorking. Let me know if this is good enough for you to experiment with.

Thanks again for taking a look at this...I hope you can figure something out ???

NotWorking.zip

Working.zip

[-Queue-]

I am looking at it right now. Just had a quick suggestion: concatTextCalc can be changed to a simple

Substitute( Checkbox; ¶; ", " )

:wink2:

[-Queue-]

Okay, that field instance is seriously tweaked. Did the file crash recently? It is not related to auto-enter options, just a field that refuses to allow more than 10 modifiable checkbox items in a column. You can get around it by resizing the field, but it is definitely better to use a new, non-corrupted instance instead.

[Kent Searight]

Actually, it did crash when I ran an import script...and that was right around the time the field started acting wierd. I never put 2+2 together because the fields in question have nothing to do with the import. Do you still think that the crash could be the culprit? Now I'm paranoid that other gremlins might be in the solution. Any suggestions, short of rewriting from scratch?

Also, thanks for pointing out a simpler way to do the text calc. For some reason I was convinced that a carriage return was put at the end of every value . Ay caramba!!!

[-Queue-]

Do you have any backup from before the crash? I would highly encourage using that and updating it with any recent changes.

A crash can effect any part of the file, layouts, scripts, field definitions, etc., even if they were not in specific use at the time. Anytime a file is closed incorrectly (regardless of the program being used), corruption is possible.

Carriage returns are only added to every item if you use LeftValues, MiddleValues, or RightValues to retrieve data. Value lists only insert returns when a value is added to the field and it contains existing data, which requires the separation.

[pjdodd]

I have got the ******* file to work!!

Go to the Keywords layout (the one with checkboxes)

Enter Layout Mode

Select the Checkbox

now Copy the checkbox

Delete the deletebox

Paste in a new one

Worked for me

[Kent Searight]

Good job, but...would you trust it? Not I. I've taken Queue's advice and started over with the last backup.

The last thing I want is to find out from a client that something is behaving strangely (maybe different, but equally strange behavior) and then know that I could have avoided this earlier by not using anything that's suspect of corruption. It's just not worth the risk, in my humble opinion. ;)

[pjdodd]

Yes I would trust it as there is a clear distinction between layout corruption (which is what I think this is) and structure corruption (which on the whole FM would warn you about and have the ability to recover).

The most drastic step I would take would be to delete the layout.

The risk of it happening again doesn't go down even if you revert to the last backup...if i had money id bet on it.

[Lee Smith]

Yes I would trust it as there is a clear distinction between layout corruption (which is what I think this is) and structure corruption (which on the whole FM would warn you about and have the ability to recover).

Wrong.

The risk of it happening again doesn't go down even if you revert to the last backup...if i had money id bet on it.

Wrong again. And you are betting on it. The cost will a lost of all or part of the data in the file.

If this is your own personal database, just be aware that It isn't a matter of "If" the file fail, it is a matter of "when" it will fail. You are playing Russian Roulette with the data.

If on the other hand, this file is for a someone else, then Listen to -Queue- and revert back to a clean backup copy of it. To do otherwise is a gross dereliction of your developer responsibility.

Lee