In a script, how do I remember a field and later put the cursor into
that field and make it the active field? I've experimented with Go To
Object and Set Field by Name (in this case setting it to its saved
initial contents). In spite of what the online documentation seems to
say, neither of these leaves the cursor in the field/object, instead
putting it into the next field in tab order.
Am I misreading? Am I doing something else wrong?
FMP 16.
In a script, how do I remember a field and later put the cursor into
that field and make it the active field? I've experimented with Go To
Object and Set Field by Name (in this case setting it to its saved
initial contents). In spite of what the online documentation seems to
say, neither of these leaves the cursor in the field/object, instead
putting it into the next field in tab order.
Am I misreading? Am I doing something else wrong?
FMP 16.
Charlie
On 2018-10-21 21:20:36 +0000, Charles H. Sampson said:
In a script, how do I remember a field and later put the cursor into
that field and make it the active field? I've experimented with Go To Object and Set Field by Name (in this case setting it to its saved
initial contents). In spite of what the online documentation seems to
say, neither of these leaves the cursor in the field/object, instead putting it into the next field in tab order.
Am I misreading? Am I doing something else wrong?
FMP 16.
Each new re-worked version of FileMaker Pro just gets messier and
messier. Even the Script "Workspace" (the stupid name for the Script
Editor) is unnecessarily over-complicated. :o(
This function used to be very easy, but now it seems to be somewhat
more complicated. I managed to get it to work using this technique ...
1. In Layout Mode, click in each Field on the Layout one at a time
and give each a unique Object Name in the silly Inspector palette
(for the sake of ease of use and understanding, it's probably best
to simply use an Object Name which is the as the Field's name in
the Define Fields window).
2. Create a new Global Text Field called g_ActiveField which the Scripts
can use to store the currently active Field's Object Name (you can
probably use a Variable if you prefer).
3. Now you can use two commands in your Scripts:
- to store the Object Name of the currently active field use
Set Field [g_ActiveField; Get(ActiveLayoutObjectName)]
- to go to the Field stored in g_ActiveField
Go To Object [Object Name: g_ActiveField]
I tried using Get(ActiveFieldName) and Go To Field, but they didn't
seem to want to work in my quick tests.
If you want to set position the cursor within a Field's data (by
default it appears on the end of any existing data), you might be able
use the Set Selection command, but that may suffer the same possible
problems as Go To Field when not hard-coding which Specific Field you
want to be in.
On 10/21/2018 2:20 PM, Charles H. Sampson wrote:
In a script, how do I remember a field and later put the cursor into
that field and make it the active field? I've experimented with Go To Object and Set Field by Name (in this case setting it to its saved
initial contents). In spite of what the online documentation seems to
say, neither of these leaves the cursor in the field/object, instead putting it into the next field in tab order.
Am I misreading? Am I doing something else wrong?
FMP 16.
How about using get(activelayoutobjectname) to store it to a variable,
and then Go To Object to go to it later?
Helpful Harry <HelpfulHarry@BusyWorking.com> wrote:
On 2018-10-21 21:20:36 +0000, Charles H. Sampson said:
In a script, how do I remember a field and later put the cursor into
that field and make it the active field? I've experimented with Go To
Object and Set Field by Name (in this case setting it to its saved
initial contents). In spite of what the online documentation seems to
say, neither of these leaves the cursor in the field/object, instead
putting it into the next field in tab order.
Am I misreading? Am I doing something else wrong?
FMP 16.
Each new re-worked version of FileMaker Pro just gets messier and
messier. Even the Script "Workspace" (the stupid name for the Script
Editor) is unnecessarily over-complicated. :o(
This function used to be very easy, but now it seems to be somewhat
more complicated. I managed to get it to work using this technique ...
1. In Layout Mode, click in each Field on the Layout one at a time
and give each a unique Object Name in the silly Inspector palette
(for the sake of ease of use and understanding, it's probably best
to simply use an Object Name which is the as the Field's name in
the Define Fields window).
2. Create a new Global Text Field called g_ActiveField which the Scripts
can use to store the currently active Field's Object Name (you can
probably use a Variable if you prefer).
3. Now you can use two commands in your Scripts:
- to store the Object Name of the currently active field use
Set Field [g_ActiveField; Get(ActiveLayoutObjectName)]
- to go to the Field stored in g_ActiveField
Go To Object [Object Name: g_ActiveField]
I've tried this, using both the global field and the variable, and I
can't get it to work. Here's what I've discovered: My script is
triggered by exit the field (the field object). I hoped that this would activate as I tried to exit the field but before the field is actually
left. That seems to be the case. I begin by capturing three pieces of
data: the field's name, using both techniques, and the contents of the
field. Much later I use a custom dialog to display these data and they
are what they should be.
I exit the field in question by clicking in another field, including
another field of a different record. After the script executes the Go To Object or Set Field by Name step, that field is where the cursor is
placed.
I've tried all four combinations of Set Variable/Set Field and Go To Object/Set Field by Name.
And here's the latest word: I've just discovered that Set Field By Name
isn't working at all. Instead of setting the field to its previously
saved initial value, I tried to set it to a different value. The initial value is what showed up.
On 2018-10-23 00:23:14 +0000, Charles H. Sampson said:
Helpful Harry <HelpfulHarry@BusyWorking.com> wrote:
On 2018-10-21 21:20:36 +0000, Charles H. Sampson said:
In a script, how do I remember a field and later put the cursor into
that field and make it the active field? I've experimented with Go To
Object and Set Field by Name (in this case setting it to its saved
initial contents). In spite of what the online documentation seems to
say, neither of these leaves the cursor in the field/object, instead
putting it into the next field in tab order.
Am I misreading? Am I doing something else wrong?
FMP 16.
Each new re-worked version of FileMaker Pro just gets messier and
messier. Even the Script "Workspace" (the stupid name for the Script
Editor) is unnecessarily over-complicated. :o(
This function used to be very easy, but now it seems to be somewhat
more complicated. I managed to get it to work using this technique ...
1. In Layout Mode, click in each Field on the Layout one at a time
and give each a unique Object Name in the silly Inspector palette
(for the sake of ease of use and understanding, it's probably best
to simply use an Object Name which is the as the Field's name in
the Define Fields window).
2. Create a new Global Text Field called g_ActiveField which the Scripts >> can use to store the currently active Field's Object Name (you can
probably use a Variable if you prefer).
3. Now you can use two commands in your Scripts:
- to store the Object Name of the currently active field use
Set Field [g_ActiveField; Get(ActiveLayoutObjectName)]
- to go to the Field stored in g_ActiveField
Go To Object [Object Name: g_ActiveField]
I've tried this, using both the global field and the variable, and I
can't get it to work. Here's what I've discovered: My script is
triggered by exit the field (the field object). I hoped that this would activate as I tried to exit the field but before the field is actually left. That seems to be the case. I begin by capturing three pieces of
data: the field's name, using both techniques, and the contents of the field. Much later I use a custom dialog to display these data and they
are what they should be.
I exit the field in question by clicking in another field, including another field of a different record. After the script executes the Go To Object or Set Field by Name step, that field is where the cursor is
placed.
I've tried all four combinations of Set Variable/Set Field and Go To Object/Set Field by Name.
And here's the latest word: I've just discovered that Set Field By Name isn't working at all. Instead of setting the field to its previously
saved initial value, I tried to set it to a different value. The initial value is what showed up.
When you run the 'Go To' Script it causes the database to exit the
second field (even though it doesn't deactivate) causing the 'Exit'
Script to be run first, which of course changes the data for the Field
it will return to.
It's a clumsy approach, but what you can do is capture the Previous
Field's Object Name separately:
- Create another Global Text Field (or variable) called
g_PreviousActiveField
(You will also need another Field to similarly capture
the field data)
- Create a new Script with the command:
Set Field [g_PreviousActiveField; g_ActiveField]
- In Layout Mode, set all the necessary Fields to also
have an OnObjectEnter trigger using the above Script
- Change the 'Go To' Script to use the g_PreviousActiveField
Field:
Go To Object [Object Name: g_PreviousActiveField]
What now happens is:
- Exiting a Field triggers the Exit Script, so stores that Field's
Object Name in the g_ActiveField.
- If you have clicked in another Field, it will trigger the
Enter Script, which copies the current contents of g_ActiveField
to g_PreviousActiveField.
- When you run the 'Go To' Script, it goes to the correct field
because it's ignoring the change to g_ActiveField occuring due to
the 'Go To' Script first triggering the Exit Script from the
second Field.
All clear as mud?? :o)
This works in some quick tests, but there are three problems though.
1. If you exit the first Field by clicking anywhere that isn't another
Field (i.e. a blank space on the layout, a button, etc.), then the
Enter Script won't be run. You might be able to workaround this by
including a test in the 'Go To' Script, but it would depend on how
the second problem can be solved ...
2. You'll need some way to clear the data from both g_ActiveField and
g_PreviousActiveField.
3. If you're using a Layout in List View, then you will also need to
capture the Record Number when exiting the Field and alter the
'Go To' Script to go back to the original Record as well as the
original Field - otherwise when you click on another record to exit
the Field, the 'Go To' will go to the correct Field, but incorrectly
in the current Record.
Perhaps it would help if you explain why you're trying to achieve this.
There might be a better approach to doing what you want.
Perhaps it would help if you explain why you're trying to achieve this.
There might be a better approach to doing what you want.
Thanks again, Harry. It's going to take me a while to digest all this.
What I'm trying to do: I have a script that validates input that's
supposed to be money. It catches every error I could think of and
informs the user, using a custom dialog. At present, the custom dialog
has only an OK button. After clicking on this button, the user has to
click in the field again to fix the error(s). I'd like to modify this so
the custom dialog has Fix and Accept buttons, with clicking on the Fix
button resulting in the cursor being in the erroneous field.
One problem with my current script, which I consider better than
nothing, is that upon exiting the money field, which is just a number
field to FM, FM displays the erroneous data using its wildly lax interpretation of the input. The result is that no particular error is obvious, unless the user notices that the value in the field is not what
he wanted.
The reason for wanting an Accept button is another story.
Charlie
Perhaps it would help if you explain why you're trying to achieve this.
There might be a better approach to doing what you want.
Thanks again, Harry. It's going to take me a while to digest all this.
What I'm trying to do: I have a script that validates input that's
supposed to be money. It catches every error I could think of and
informs the user, using a custom dialog. At present, the custom dialog
has only an OK button. After clicking on this button, the user has to
click in the field again to fix the error(s). I'd like to modify this so
the custom dialog has Fix and Accept buttons, with clicking on the Fix
button resulting in the cursor being in the erroneous field.
One problem with my current script, which I consider better than
nothing, is that upon exiting the money field, which is just a number
field to FM, FM displays the erroneous data using its wildly lax
interpretation of the input. The result is that no particular error is
obvious, unless the user notices that the value in the field is not what
he wanted.
The reason for wanting an Accept button is another story.
Charlie
Have you tried the automatic field validation FMP offers? Make a number field. Goto field options. Choose the second tab (I don't know its
English name). On this tab set the checkmark on to 'Restrict......'
(again exact name unknown to me in English) Then from the dropdown
behind the checkmark choose numeric only.
OR if you want something more complec, choose 'Through calculation'.
Then set the last checkmark and create your custom warning.
No scripts, no triggers. Should work????
keep well, Erik
Helpful Harry <HelpfulHarry@BusyWorking.com> wrote:
On 2018-10-23 00:23:14 +0000, Charles H. Sampson said:
Helpful Harry <HelpfulHarry@BusyWorking.com> wrote:
On 2018-10-21 21:20:36 +0000, Charles H. Sampson said:
In a script, how do I remember a field and later put the cursor into >>>>> that field and make it the active field? I've experimented with Go To >>>>> Object and Set Field by Name (in this case setting it to its saved
initial contents). In spite of what the online documentation seems to >>>>> say, neither of these leaves the cursor in the field/object, instead >>>>> putting it into the next field in tab order.
Am I misreading? Am I doing something else wrong?
FMP 16.
Each new re-worked version of FileMaker Pro just gets messier and
messier. Even the Script "Workspace" (the stupid name for the Script
Editor) is unnecessarily over-complicated. :o(
This function used to be very easy, but now it seems to be somewhat
more complicated. I managed to get it to work using this technique ... >>>>
1. In Layout Mode, click in each Field on the Layout one at a time
and give each a unique Object Name in the silly Inspector palette
(for the sake of ease of use and understanding, it's probably best
to simply use an Object Name which is the as the Field's name in
the Define Fields window).
2. Create a new Global Text Field called g_ActiveField which the Scripts >>>> can use to store the currently active Field's Object Name (you can
probably use a Variable if you prefer).
3. Now you can use two commands in your Scripts:
- to store the Object Name of the currently active field use
Set Field [g_ActiveField; Get(ActiveLayoutObjectName)]
- to go to the Field stored in g_ActiveField
Go To Object [Object Name: g_ActiveField]
I've tried this, using both the global field and the variable, and I
can't get it to work. Here's what I've discovered: My script is
triggered by exit the field (the field object). I hoped that this would
activate as I tried to exit the field but before the field is actually
left. That seems to be the case. I begin by capturing three pieces of
data: the field's name, using both techniques, and the contents of the
field. Much later I use a custom dialog to display these data and they
are what they should be.
I exit the field in question by clicking in another field, including
another field of a different record. After the script executes the Go To >>> Object or Set Field by Name step, that field is where the cursor is
placed.
I've tried all four combinations of Set Variable/Set Field and Go To
Object/Set Field by Name.
And here's the latest word: I've just discovered that Set Field By Name
isn't working at all. Instead of setting the field to its previously
saved initial value, I tried to set it to a different value. The initial >>> value is what showed up.
When you run the 'Go To' Script it causes the database to exit the
second field (even though it doesn't deactivate) causing the 'Exit'
Script to be run first, which of course changes the data for the Field
it will return to.
It's a clumsy approach, but what you can do is capture the Previous
Field's Object Name separately:
- Create another Global Text Field (or variable) called
g_PreviousActiveField
(You will also need another Field to similarly capture
the field data)
- Create a new Script with the command:
Set Field [g_PreviousActiveField; g_ActiveField]
- In Layout Mode, set all the necessary Fields to also
have an OnObjectEnter trigger using the above Script
- Change the 'Go To' Script to use the g_PreviousActiveField
Field:
Go To Object [Object Name: g_PreviousActiveField]
What now happens is:
- Exiting a Field triggers the Exit Script, so stores that Field's
Object Name in the g_ActiveField.
- If you have clicked in another Field, it will trigger the
Enter Script, which copies the current contents of g_ActiveField
to g_PreviousActiveField.
- When you run the 'Go To' Script, it goes to the correct field
because it's ignoring the change to g_ActiveField occuring due to
the 'Go To' Script first triggering the Exit Script from the
second Field.
All clear as mud?? :o)
This works in some quick tests, but there are three problems though.
1. If you exit the first Field by clicking anywhere that isn't another
Field (i.e. a blank space on the layout, a button, etc.), then the
Enter Script won't be run. You might be able to workaround this by
including a test in the 'Go To' Script, but it would depend on how
the second problem can be solved ...
2. You'll need some way to clear the data from both g_ActiveField and
g_PreviousActiveField.
3. If you're using a Layout in List View, then you will also need to
capture the Record Number when exiting the Field and alter the
'Go To' Script to go back to the original Record as well as the
original Field - otherwise when you click on another record to exit
the Field, the 'Go To' will go to the correct Field, but incorrectly
in the current Record.
Perhaps it would help if you explain why you're trying to achieve this.
There might be a better approach to doing what you want.
Thanks again, Harry. It's going to take me a while to digest all this.
What I'm trying to do: I have a script that validates input that's
supposed to be money. It catches every error I could think of and
informs the user, using a custom dialog. At present, the custom dialog
has only an OK button. After clicking on this button, the user has to
click in the field again to fix the error(s). I'd like to modify this so
the custom dialog has Fix and Accept buttons, with clicking on the Fix
button resulting in the cursor being in the erroneous field.
One problem with my current script, which I consider better than
nothing, is that upon exiting the money field, which is just a number
field to FM, FM displays the erroneous data using its wildly lax interpretation of the input. The result is that no particular error is obvious, unless the user notices that the value in the field is not what
he wanted.
The reason for wanting an Accept button is another story.
Charlie
On 2018-10-27 02:02:11 +0000, Charles H. Sampson said:
Helpful Harry <HelpfulHarry@BusyWorking.com> wrote:
On 2018-10-23 00:23:14 +0000, Charles H. Sampson said:
Helpful Harry <HelpfulHarry@BusyWorking.com> wrote:
On 2018-10-21 21:20:36 +0000, Charles H. Sampson said:
In a script, how do I remember a field and later put the cursor into >>>>> that field and make it the active field? I've experimented with Go To >>>>> Object and Set Field by Name (in this case setting it to its saved >>>>> initial contents). In spite of what the online documentation seems to >>>>> say, neither of these leaves the cursor in the field/object, instead >>>>> putting it into the next field in tab order.
Am I misreading? Am I doing something else wrong?
FMP 16.
Each new re-worked version of FileMaker Pro just gets messier and
messier. Even the Script "Workspace" (the stupid name for the Script >>>> Editor) is unnecessarily over-complicated. :o(
This function used to be very easy, but now it seems to be somewhat
more complicated. I managed to get it to work using this technique ... >>>>
1. In Layout Mode, click in each Field on the Layout one at a time
and give each a unique Object Name in the silly Inspector palette
(for the sake of ease of use and understanding, it's probably best
to simply use an Object Name which is the as the Field's name in
the Define Fields window).
2. Create a new Global Text Field called g_ActiveField which the Scripts
can use to store the currently active Field's Object Name (you can
probably use a Variable if you prefer).
3. Now you can use two commands in your Scripts:
- to store the Object Name of the currently active field use
Set Field [g_ActiveField; Get(ActiveLayoutObjectName)]
- to go to the Field stored in g_ActiveField
Go To Object [Object Name: g_ActiveField]
I've tried this, using both the global field and the variable, and I
can't get it to work. Here's what I've discovered: My script is
triggered by exit the field (the field object). I hoped that this would >>> activate as I tried to exit the field but before the field is actually >>> left. That seems to be the case. I begin by capturing three pieces of
data: the field's name, using both techniques, and the contents of the >>> field. Much later I use a custom dialog to display these data and they >>> are what they should be.
I exit the field in question by clicking in another field, including
another field of a different record. After the script executes the Go To >>> Object or Set Field by Name step, that field is where the cursor is
placed.
I've tried all four combinations of Set Variable/Set Field and Go To
Object/Set Field by Name.
And here's the latest word: I've just discovered that Set Field By Name >>> isn't working at all. Instead of setting the field to its previously
saved initial value, I tried to set it to a different value. The initial >>> value is what showed up.
When you run the 'Go To' Script it causes the database to exit the
second field (even though it doesn't deactivate) causing the 'Exit'
Script to be run first, which of course changes the data for the Field
it will return to.
It's a clumsy approach, but what you can do is capture the Previous
Field's Object Name separately:
- Create another Global Text Field (or variable) called
g_PreviousActiveField
(You will also need another Field to similarly capture
the field data)
- Create a new Script with the command:
Set Field [g_PreviousActiveField; g_ActiveField]
- In Layout Mode, set all the necessary Fields to also
have an OnObjectEnter trigger using the above Script
- Change the 'Go To' Script to use the g_PreviousActiveField
Field:
Go To Object [Object Name: g_PreviousActiveField]
What now happens is:
- Exiting a Field triggers the Exit Script, so stores that Field's
Object Name in the g_ActiveField.
- If you have clicked in another Field, it will trigger the
Enter Script, which copies the current contents of g_ActiveField
to g_PreviousActiveField.
- When you run the 'Go To' Script, it goes to the correct field
because it's ignoring the change to g_ActiveField occuring due to
the 'Go To' Script first triggering the Exit Script from the
second Field.
All clear as mud?? :o)
This works in some quick tests, but there are three problems though.
1. If you exit the first Field by clicking anywhere that isn't another
Field (i.e. a blank space on the layout, a button, etc.), then the
Enter Script won't be run. You might be able to workaround this by
including a test in the 'Go To' Script, but it would depend on how
the second problem can be solved ...
2. You'll need some way to clear the data from both g_ActiveField and
g_PreviousActiveField.
3. If you're using a Layout in List View, then you will also need to
capture the Record Number when exiting the Field and alter the
'Go To' Script to go back to the original Record as well as the
original Field - otherwise when you click on another record to exit
the Field, the 'Go To' will go to the correct Field, but incorrectly
in the current Record.
Perhaps it would help if you explain why you're trying to achieve this.
There might be a better approach to doing what you want.
Thanks again, Harry. It's going to take me a while to digest all this.
What I'm trying to do: I have a script that validates input that's
supposed to be money. It catches every error I could think of and
informs the user, using a custom dialog. At present, the custom dialog
has only an OK button. After clicking on this button, the user has to
click in the field again to fix the error(s). I'd like to modify this so the custom dialog has Fix and Accept buttons, with clicking on the Fix button resulting in the cursor being in the erroneous field.
One problem with my current script, which I consider better than
nothing, is that upon exiting the money field, which is just a number
field to FM, FM displays the erroneous data using its wildly lax interpretation of the input. The result is that no particular error is obvious, unless the user notices that the value in the field is not what
he wanted.
The reason for wanting an Accept button is another story.
Charlie
You could highlight the field that has the error, by putting a
Calculation Container field behind it on the Layout which "lights up"
when there's an error in the main field's data.
Should be easier and more noticeable.
Perhaps it would help if you explain why you're trying to achieve this.
There might be a better approach to doing what you want.
Thanks again, Harry. It's going to take me a while to digest all this.
What I'm trying to do: I have a script that validates input that's
supposed to be money. It catches every error I could think of and
informs the user, using a custom dialog. At present, the custom dialog
has only an OK button. After clicking on this button, the user has to
click in the field again to fix the error(s). I'd like to modify this so the custom dialog has Fix and Accept buttons, with clicking on the Fix button resulting in the cursor being in the erroneous field.
One problem with my current script, which I consider better than
nothing, is that upon exiting the money field, which is just a number
field to FM, FM displays the erroneous data using its wildly lax interpretation of the input. The result is that no particular error is obvious, unless the user notices that the value in the field is not what
he wanted.
The reason for wanting an Accept button is another story.
Charlie
Have you tried the automatic field validation FMP offers? Make a number field. Goto field options. Choose the second tab (I don't know its
English name). On this tab set the checkmark on to 'Restrict......'
(again exact name unknown to me in English) Then from the dropdown
behind the checkmark choose numeric only.
OR if you want something more complec, choose 'Through calculation'.
Then set the last checkmark and create your custom warning.
No scripts, no triggers. Should work????
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 292 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 202:47:24 |
| Calls: | 6,617 |
| Calls today: | 1 |
| Files: | 12,168 |
| Messages: | 5,316,357 |