Check your fields for trailing spaces. You might use a watch expression such as Quote ( Members::gBtnMemOrCAN ) to make it easier to see such.
Also, make sure your two fields are of type text, not number.
No luck on this one. In the database, both gBtn fields are Global Text. I am still stumped.
Given the data, it should evaluate as true and the next step executed should be the Find [Restore] step. What exactly do you mean by "jumps right past the If"?
Which button in the debugger are you clicking to move through the script?
Since you are also pursuing this in another thread, I suggest limiting your responses ot that thread to limit potential confusion.
Thanks for the reply.
I am using the 2nd button from the left. It steps through other sections of the code without a problem.
I need to mention that gBtnMemOrCan and gBtnActiveOrInactive are both radio buttons that were set with
"P"&"Member"&"P" and "P"&"Active"&"P" (Where P is a Return character). I tried changing the IF and ElseIF
to use this syntax but without result. Debug still skips.
As for the other thread... I started that line before I realized that the crux of the problem was the IF ELSEIF not
being executed. I thought a thread focused on just that issue would be simpler and better come to a solution.
Please see my comments in your other thread. The use of "¶" & "Member" & "¶"
Needlessly complicates your solution. I strongly suggest you replace "¶" & "Member" & "¶" with just "member".
I'm not convinced that it's the If -- ElseIF steps.
Let me revisit a question I asked earlier:
What exactly is happening when you click that button (called "step into")?
Is this what happens?
First: Set Error Capture is highlighted, as you click the button repeatedly, each step highlights except the comment lines (start with #) are skipped.
Does the If step Highlight?
If so, what line highlights when you then click the "step into" button again at this point?
If the IF line never highlights and you do not see a new script appear in your debugger after commit record (check the call stack at the bottom for any changes), then something is seriously wrong with your file and you should run a recover on it.
If you find a new script is executed when the record is committed (Could be a new instance of the same script), then check layout setup for an OnRecordCommit script trigger. You may need to disable such a trigger--at least until you are through testing your script, to see iwhat is actually happening.
I think I got it to work. Here is what I learned:
When I click on the radiobutton (Active Inactive) I need to test for "Active" for example.
When I set the value of the same radio button with "P"&"Active"&"P" I need to test in the IF for "PActiveP". (Where "P" is the Return character)
Sometimes I would run a script which sets the radio buttons for "Active" and "Member" for example. OK. But, when I would click from Active
to Inactive what needed to be tested for was "Inactive" and "PMemberP". I needed to test for the 4 permutations of this combination. This
allows the user to click wherever he wants and the results will be tested correctly.
Phil, what *really* lead me to this solution was your idea of using Quote() function. With that in my debug variables window I could see
the inconsistencies that were developing and when they were caused. THANK YOU!!!!
Yes, but you seem to have missed a point that several posters have very clearly stated: You do not need those returns. You should only set the text and leave off the return characters before and after it.
My experience is that I can not, by script, SET the value of a radio button without the returns. Once 'programmed', the button state is really "PAcitveP" and should be tested as such.
When I mouse click the Active/Inactive button it produces "Active" and needs to be tested as such.
There are 2 sets of radio buttons: Active/Inactive and Member/Candidate.
Since I can set the value of a button by script, for example, to "Active" and "Member", it will hold the values of "PActiveP" and "PMemberP". And this combination shows in the debug window using quote(). But, if a user clicks the 'Candidate' button, these values are produced: "PActiveP" and "Candidate".
Because of this inconsistency, and the fact that a user can click aftere I set a radio button value by script, in the "Active Candidate" IF statement I needed to test for:
("PActiveP" and "PCandidateP") or ("PActiveP" and "Candidate") or ("Active" and "Candidate) or ("Active and "PCandidate")
This way it doesn't make any difference if the user clicks after I set a button value. Execution will always know the intent.
This is not the case. Set field sets data into the field just as though you typed it in--but without tripping any field based script triggers. The returns are completely unnecessary in this context.
The one case where you might use such an expression is if you have Checkbox Group and want to add a selected value without overwriting existing values selected in the field.
In which case, you'd need a slightly different expression in order to append the value such as:
Set Feld [table::Checkboxfield ; TableCheckboxField & ¶ & "valuetoAppendHEre"]
And this is not what you are doing here. Try taking out the returns and see what happens.
Or see how this demo file works: https://dl.dropbox.com/u/78737945/SetRadioButtonDemo.fmp12
Hmmm. I am confused. You say "This is not the case" , yet you can see in my .jpg above that gBtnMemOrCan has a value of "PMemberP" and gBtnActiveOrInactive has a value of "Inactive".
Are you saying that these values, with and without the return characters, 'really don't matter' to an If evaluation?
My experience is that when I drop the 'return' characters and get a generation as indicated in the above Debug, the IF will not evaluate properly. Or, is your position that even in the above Debug situation it *WILL* evaluate properly? If so, I will try it again.
Just because it works, does not mean that it's a necessity and it greatly complicates the data in the field forcing you to add all kinds of special handling that is not needed.
The returns DO matter to an evaluation in an If step or other calculation. That's why I strongly urge you not to include the extra returns. They are not needed.
Yes, they should evaluate correctly. Including the returns would appear to be what kept them from evaluating correctly rather than the opposite.
I've updated the demo file. Download it again and note the new button named "check".
Click the apple button and note that the "Apple" radio button is now selected.
Click the check button and note the message that pops up confirming that apple is selected.
It uses this if statement:
If [Table::RadiobuttonField = "Apple"]
Note that there are no returns ever present in this field.
If you create tests to evaluate If... and test for:
"¶" & "Active" & "¶"
"¶" & "Active"
"Active" & "¶"
you will see that Filemaker is precise and distinguishes between those field values, and returns the correct evaluation of the field value.
I ran the example from the link above. It works well and doe not have the 'return' characters when clicked or with setfield?
I am going to have to figure out why my app has the returns and yours does not?
Do you have any idea what can cause the attachment of the return characters when I click the radiobutton? Very mysterious.
Thanks for sending.
Between the two threads you've had open, I saw script steps that added the returns. I've assumed that's how they were added to your field.
I'd first create a brand new blank record and click one of the radio buttons, then use a copy of the same field on the same record and layout, but without the radio button format (change it back to edit box) click into the field and see if there is any return or just the radio button text. It looks from here like your scripts or other input methods than the radio button added the unwanted returns.