User-customisable buttons (with script attached)

[db_tragic]

I have a FM Go solution whereby the bulk of the data entry on the iPad is via buttons, which have an attached script that inserts pre-defined text into a text field "Notes". The inserted text from buttons appearing on a particular tab, is appended to any text already there.

 

The majority (>90%) of the buttons are 'standard' and their label, and 'insert text script" can be pre-set by me.

 

What I am trying to figure out is if there is a creative way I can do something like the following, so that some additional buttons can be customised by the user;

1. Say have something like a 4x3 grid, each square being about 10x10mm

2. The user is able to enter the content of each grid square (in text form) (either on the current layout{unlikely}, or when an "edit" button is tapped, they are redirected to another layout where the content of that cell {or all of them} can be modified.

3. Each cell, which when then tapped (assuming the user has assigned a value) would then automatically insert text based on what has been assigned to that cell, into the Notes field.

 

I did think about just using a pop-up or drop-down list that the user can modify, and attached a script 'OnObjectModify' etc, however, I really want them to be able to setup their own custom buttons, whereby the 'label' that displays for that button (cell) is what is inserted in the Notes field. The label and inserted text will not need to be more than 7-8 characters.

 

So before I start experimenting, I thought I'd canvass the group for ideas. Some thoughts I had included ideas revolving around the use of a portal, or even having the value in each cell corresponding to a single field in 12 different tables (user editable values, with pre-assigned script to look up value).

 

Any thoughts would be appreciated,

 

TIA

 

 

 

 

[db_tragic]

Just figured out how to do it! I'll post with details on how I did it shortly.

[LaRetta]

Well if you are open to ideas, here is another approach (see attached).

 

Added - you can even colorize the selected text in the selection field (not included but easy to do in the script) as items are selected - it gives you a visual of what has already been used. 

select.fmp12.zip

Edited July 5, 2013 by LaRetta

[db_tragic]

HI Laretta,

 

Thank you for the post - far more compact (in the background especially) compared to what I've done, though the context is a little different (especially wrt to button use). Hopefully what I've done isn't too clunky in the background - will have to test it out - but am curious if there's a more efficient way of doing what I've done below (i.e. 64 buttons, 64 merge field labels, 64 (small) scripts!). I don't understand the implications of what database design features (as opposed to data volume) contribute to slowing things down on an iPad, so I may end up regretting going down this road! So far, so good tho. 

 

(Edit: modified response to Laretta - realised it perhaps came across as a little blunt/abrupt - not intended at all, Sorry! Thanks again Laretta).

Here's what I ended up doing.

 

The objective - to have buttons on an iPad layout, that when tapped, would automatically insert(append) text into (in this case) a "Treatment Notes" field. The challenge - to have buttons that were customisable by the user, on the iPad.

 

1. Setup a bunch of buttons (just graphics) on the particular iPad layout I needed them.

 

 

2. Setup a table, with global fields, and character number limits (so the value fits on the button), where each field corresponds with a button. In this case I used a spreadsheet-style nomenclature (R1C1, R1C2 etc)

 

3. Setup a layout based on the above table, that mirrors the button layout, with the 'fields' in their relevant position. This layout is what the 'edit' script will call up (in a new window) when the edit button is tapped, and the user can change the field content. (Pic below doesn't have the theme tidied up yet). There is a "Close" button on this layout with a "close window" script attached. I've entered, as values in the fields, the fields grid location description here, simply to be able to check that they've been located correctly in the next step.

 

 

4. Back on the original layout with the buttons - Over each button, insert a 'Merge Field' (as a label for the button) corresponding to the field in the same location on the grid. ie. the first button on the upper left, corresponds to field R1C1 (Row 1, Column 1), and so that button has the merge field value of field R1C1 form the table in step 2 above. Matching button sizes and merge field 'styles' (font size etc) can require a bit of fiddling. With the text entered in the fields as in step 3 on the 'edit' layout, below is how the buttons look with the merge fields now displaying as labels for the buttons;

 

 

5. The next step is to write and attach a script to each button (script must be unique for each cell in the grid), that looks up the value in the corresponding field, and in this case, inserts(appends) that value as text in the 'Treatment Notes' field.

 

(The Go To Object line is simply there to prevent the keypad from becoming active).

 

6. Lastly, I setup a script that is attached to the "Edit" button (red arrow in "4" above), which opens the layout in "3" above in a new window. Here the user can enter the values for the fields (and hence button names), then tap a "close" button on that page to close the window, and they will be back at their main working page with the updated button labels.

 

Because the script associated with each button, is simply setup to reference the content of a field, if the filed is blank (i.e. user hasn't assigned a value to that button) then the button simply has no label on it, and the assigned script has nothing to insert (one could add a step whereby if the user taps an empty button a dialogue could remind them it has no value, and could ask them if they want to create/enter one).

 

 

Hope someone finds this useful.

Cheers

 

 

 

Well if you are open to ideas, here is another approach (see attached).

 

Added - you can even colorize the selected text in the selection field (not included but easy to do in the script) as items are selected - it gives you a visual of what has already been used. 

[db_tragic]

An additional comment on this -

 

I realised soon afterwards, that the above, whilst in itself works fine for my purposes, an extra step could be added whereby the text inserted could be a much longer string, from another field, and where the above process would be used for simply setting up the button labelling - the 'Insert" script would instead reference a different field value (with the longer string).