The Set Field By Name [ ] script step allows you to conditionally specify the field to be altered. Specify the target field with a simple case statement along the lines of:Case (IsEmpty ( TableA::B1 ) ; GetFieldName ( TableA::B1 ) ;IsEmpty ( TableA::B2 ) ; GetFieldName ( TableA::B2 ) ;and so on...The first empty field will be the target field.Furthermore, if you'd like to use one simple script for every button of this type you may find yourself in need of multiple script parameters. There are many ways to do this, but I think this way is particularly simple:
You could use drag and drop to drag a value from Column A to Column B. You can use calculation fields to display the values in Column A so that you can enter the field for the drag and drop but still not be able to accidentally modify a value in Column A.
You can also set up the column A values as buttons (field can be buttons or you might choose just to use buttons) that use Insert Calculated Result or Insert Text to insert text into the current field. Then you can click or tab to put the cursor into a field in Column B and clicking a value in column A will insert that value into the field where you currently have the cursor.
Thanks Phil and Nihm for your guidance.
I oversimplified my needs just to illustrate the problem I was facing. In reality, there would potentially be dozens of fields for the user to select.
Thanks for suggesting alternative approaches. Having a few options is always better...you just have to identify and evaluate assumptions and implications of each approach.
At the moment, I'm inclined to pursue Nihm's approach...using simple button clicks that automatically find the next open field. This seems a bit easier on the user in the long-run (rather than dragging-and-dropping or forcing the user to continually place the cursor in a specific field)
I'm a half-step above novice so I might return to ask a few questions.
Ahhh, Nihm. It worked like a charm....Gracias!!!
Next question. With dozens of fields, I'm imagining some users might mistakenly click the same button twice which would not be desirable. I'd like to prevent my users from doing so. How could I get the same button to:
a) Prevent the user/program from entering the same text twice...in the multiple fields...is this even possible???
b Assuming the above is doable, I'd also like to include a pop-up saying. "This text has already been used"
In FileMaker 13, you can include a script step that sets a value in a variable or a field. Then the "Hide Object When" property can be set to hide the button when this value has been set. Then clicking a button enters the text and makes it disappear--keeping the user from clicking it again.
Thanks, Phil. The Hide feature works very nicely for the INSERT buttons.
With dozens of fields I can already imagine some users inadvertantly clicking on one of the buttons or changing their mind after inserting text.
So in addition to the INSERT buttons, I've created several REMOVE buttons. I've been able to use similar coding to get these buttons to show only when the appropriate text has been entered. When the text is manually deleted it disappears.
However, I'd like to set up REMOVE buttons to automatically find the text, select, and delete it. Obviously, I'd need something equivalent to the opposite of the "IsEmpty" function. I've tried researching this, but have run into several dead ends.
Could you please help.
Obviously, I'd need something equivalent to the opposite of the "IsEmpty" function.
Is the inserted text the only text in the field? If so,
Not Isempty ( field ) is the test that you need and set field can set the field to "" to clear it.
But if this layout design combines data from several clicked buttons in a single field:
Patterncount ( YourTable::Field ; "text searched for here" )
will detect when this text is present. And in this latter case, the substitute function can remove this text.
Thanks. I will implement your suggestions the first chance I get.
I intend for the inserted text in the field to be the only text. Having said that, it is possible right now for a user to type in the field...which of course would disrupt the functionality. Is there any way to prevent the user from entering text (other than what may be in the initial field)?
Just to avoid any confusion, I should've been more clear...is it possible to prevent the user from entering text in the target field.
a) stop using the "insert..." script steps for this. Replace them with set field in your scripts and/or button setups.
b) then use behavior settings in the inspector to deny Browse Mode access to the field.
Set field--which interacts with the field at the data level, not the layout level, can still modify data in the field even though the user cannot directly modify this data.
The Insert steps interact with the field object on the layout. This requires that the field be present with access permitted and results in leaving the cursor in the field--also undesirable for what you describe here. It will also trip any OnObjectEnter, OnObjectModify or OnObjectSave script triggers set on the field while Set Field will not.