Getting Button names

[Rob Halliday]

Hello...

So.... is there any way of picking up the 'name' of a button for subsequent use in fields or scripts?

I have a number of buttons; each needs to instigate an action that is related to the button name.

It would be nice to write one script that could take the name of the button that called it and use that to figure out what to do, rather than having to write one script per button.

Any ideas, anyone?

Waiting in hope....

Thanks,

Rob.

[Ender]

Sorry Rob, this isn't possible in FM5/6.

In FM7, you can assign script parameters to buttons that are then passed to scripts.

[sbg2]

Heres a small sample file of what Ender is talking about. Just think of it as you are naming the buttonas with the optional script parameter.

Button.zip

[stanley]

Rob:

What you can do is have a short script for each button which sets a global to the desired value, then calls your main script, where you can use that global value. This way you don't have to redo the whole script for each button.

-Stanley

[comment]

You can also use the script name in a similar fashion. For example, 3 identical scripts, named Script 1, Script 2 and Script 3. Then in the script you can have:

If [ Right ( Status (CurrentScriptName), 1 ) = "2" ]

Do something

or:

Set Field [ somefield, Right ( Status (CurrentScriptName), 1 ) ]

[Rob Halliday]

Thanks, all....

I'd already reached the point of using a short script to set a global that the main script then used to figure out what to do, but that still means a script-per-button and, for this application, that ends up being quite a lot of little scripts.

So, related question: is there any way of having a script triggered when a field is changed? That way I could just make a one-line button action to set the global field, then have that change trigger the main script that actually did the work - at least it would remove the need for lots of little two-line scripts.

Beyond that, this may be the straw that breaks the camel's back and makes me move up to FM7. Even though that would also mean moving up to OS X........

Rob.

[comment]

Only with a plug-in, I'm afraid - and that's true for v.7 as well (except that there are 3 free plug-ins to choose from).

There may be another workaround, that might work for you - or not, depending on what you're trying to do:

Suppose I am scripting the creation of a new record, which can be one of 3 types. I can have 3 buttons [New Type1], [New Type2] and [New Type3]. This would require me to have 3 separate scripts.

But if I had a button [New Record], which would take me to another layout with the aforementioned buttons, I could indeed have one script and 3 one-liners atached to the buttons.

Provided such detour can be made to look natural from the user's point of view.

[Søren Dyhr]

To your first question, could you also exploit this plugin to get the x,y coordinates the button is located at and reuse the same script with all buttons:

http://www.jazzmedia.com.au/jazzutils.html

The second question is more tricky, since you should provide a rollback if you will litter your layout with matters that can't be forgiven ...you're likely to break Apple user interface guidelines!!! They exists as plugins but I would encourage you to rethink if it's really what you want to expose your users to???

Beyond that, this may be the straw that breaks the camel's back and makes me move up to FM7. Even though that would also mean moving up to OS X........

You should be aware of this is a FAQ, which have been up since ver. 3.0 that didn't allow any plugins at all - back then in 1995 did David Kashel of http://www.codemastersworkshop.com/index.html toy with it and managed to make a looping applescript that sniffed an unstored calc containing Status(CurrentFieldName) and if this field changed into particular values, did the everrunning loop interact with filemaker scripts execution... I would guess that unless you change your mind with the matters you'll expose your users to, could write David and pick his brains on this for far less than the cost of an upgrade or buy a plugin solving these matters.

But you're scating on thin ice ....

http://www.fmforums.com/threads/showflat...true#Post153577

--sd

[Rob Halliday]

Hi Soren & all,

"breaking interface guidlines' is not really a problem since it's not really a full-on database: I'm making a 'virtual keyboard' for another application. That application (an old DOS application running under VirtualPC) requires the user to remember lots of obscure key comibinations that map to real functions.

I've made a layout in FM with a button per function. The database then contains the button's name and the corresponding set of key codes. These are then sent to VirtualPC (and so the old app) via Applescript.

Trouble is, there are quite a lot of buttons.

X/Y position grabbing might work but isn't ideal because a user might want to re-arrange the virtual buttons to taste.

Since each button is labelled with its function, and the database contains the function stored with the same name, that's why I was trying to use the button label to run a search based on its name.

But I guess I can't do it :-(

Oh, well. Off to write lots of scripts now.....

Rob.

[comment]

Why not put the buttons in portal/s, then?

[Rob Halliday]

Explain......?!

I think I can't do this because the buttons are arranged on-screen to resemble a 'real' control surface that also exists for this product.

I don't think I can do enough visual arranging with portals.... can I?

Rob.

[comment]

It depends on how they need to be arranged - see the demo.

buttons.fp3.zip

[comment]

Here's another cheap-to-implement option.

buttonsR.fp3.zip

[Rob Halliday]

Thanks all....

The last option is the best variation/improvement over what I was doing - picking up the script name and passing that to the 'do action' script so that at least the script for every button is the same.

Thankyou very much.

Rob.