Hi all,

I'm trying to figure out a way to imitate the behavior of the "Contact Photo" field in MS Outlook (Windows). When the field doesn't contain an image, a single-click opens the dialog for selecting an image. When the field does contain an image, a double-click is required to bring up the same dialog.

I've been trying to figure this out for a while now by timing the script from beginning to end while having a pause somewhere between that's resumed by the second click...

Is this even possible? Any ideas?

Thanks in advance for any help offerred!

Hi Kent_S

I don't know if what you ask is possible...

but sure you can play with modifier keys !

MouseClick.zip

Hi Daniele,

I'm trying to avoid using anything in the interface that the end users aren't already familiar with. Use of a modifier key wouldn't offer the level of ease and intuitiveness that I'm trying to achieve. I'd probably put a labeled button next to the container before using a modifier key.

Now if my clients were all computer-savvy power users...hmmmm...:qwery:

Thanks anyway!

You might try this, the response time isn't as good as i had envisioned, but nevertheless.

dblclick.zip

Try swapping the field with a variable, it might speed it up a bit...

~Genx

I'm impressed

I'll tinker around with it a little to see if I can improve its performance, but I think that the time lag between 1st and 2nd clicks will be acceptable. I already swapped out a global variable for the field but I don't notice any difference.

Thanks a lot, Genx!

This is another way to react to a single or a double click...

IsEmpty(container) = one click opens dialog

Not IsEmpty(container) = one click does nothing, doubleClick opens dialog

MouseClick.zip

Hi Genx

I'm impressed too...

Before FMP8 it can't be made ! (so this file works only with 8)

This is a stripped version of your script ( only 5 steps) that can count any ( about ) number of cliks ! :

Contare_i_click.zip

Oh i do like it when people are impressed . Why can't your file work Pre 8, it doesn't seem to be using an features specific to it?

~Genx

It uses the new stack order of script execution...

the new script fired is executed while the first pauses (so that you had to use the "Halt Script" step)

pre 8: first IN first OUT

from 8: last IN first OUT

But wouldn't that work in 7? If not, then oops, i didnt even notice that fact, i didn't spend that much time with 7 so...

No, it do not work with 7 !

When the script is fired, only the first "click" is counted !

(That is the reason for which I'm impressed for this NEW technique !)

Lol, yay for me, i just figured it always worked like that hehe. Yay, something new ! Thanks for letting me know about the stack order execution.

~Genx

Halt !

I just tried another time with 7...

and now the file works !

( I wish that someone explains it to me !)

Hmmm, maybe it just lagged the first time?

Or maybe if your statement about script execution first in first out is true... While the script is paused, it doesn't count as being executed so you can execute another script?

~Genx

Edited May 7, 200619 yr by Guest
Thought

It's an interesting idea. I am not sure how the script stack order plays here, but in any case I thought it best to take it out of the equation altogether - see attached.

This also shortens the script, and makes it easier to understand what goes on, and why (see also the comments in the script). I've also added a field to adjust the pause, so you can actually see the action (in the 'global' version of the script).

The 'variable' version is the same, except it uses a variable instead of a global. The variable is passed to the next script via script parameter. This happens BEFORE the script is killed, so it's possible to use a local variable for this - and take the script down to 3 lines only (no reset is required).

The last version is only 2 lines, uses no globals or variables, and works in both 7 and 8.

CountClicks.fp7.zip

Nicely done comment, i especially like the use of the script parameter, didn't even realize that would work.

I've also never really had a reason to execute multiple scripts before so i never realized the point of the current script option when defining the button. This fact alone is sure to save me some pain in the future.

Cheers,

~Genx

Hi comment,

Nicely done, indeed!

Thanks to all for the help.

I've been following this thread with interest but there is still a piece I'm missing - way back on the original post.

Kent, I can't help but wonder:

When image is empty, single-click opens the dialog for selecting an image.

When the field does contain an image, a double-click is required to bring up the same dialog.

The logic is incomplete. What if the field contains an image and is single-clicked? I only ask because Users (particularly if Windows users) are continually confused on whether to single- or double-click. I keep reminding them that single-click will work but they many times double-click anyway. I might approach this differently ... let them single-click and use an If[] test in the script to determine what to do. But even that logic fails, something like:

If [ not container ]

... open Select Image dialog

Else

... what?

End If

I think, regardless, some Users will accidently double-click when they mean single and vice-versa. And even those who are used to a sigle-click opening the Select Image dialog might get confused when there is an image and they are THEN expected to double-click. You may have plans for that single-click if container is not empty. But if a dialog must pop up, it MIGHT be more consistent to keep the keystrokes consistent as well. Just an observation.

The demos are cool.

LaRetta

Hi LaRetta,

If the user single-clicks on it when it's occupied it goes to that field to activate it in case the user wants to export or copy that image or anything else that can be done with a right-click/control-click.

See attached example. The only minor glitch I see with it is if a user single-clicks on an occupied field and then decides to double-click on it (before clicking out of it first), the script doesn't work because the field is behaving as a field, not a button anymore... ...stupid field or button or whatever it is.

Kent, .sit is just a crazy mac format, couldn't you have zipped it? :B

Here's a zipped file.

FYI If you have trouble opening .sits in Windows, try Stuffit for Windows. Stuffit is the only utility I use for compression/decompression on either platform and it works great on all compressed file types that I run into (it even further compresses .jpgs).

InsertPhoto1or2ClickRev1.zip

... but it costs money . I hate things that cost money :. Nevertheless, i'll give it a go.

The only minor glitch I see with it is if a user single-clicks on an occupied field and then decides to double-click on it (before clicking out of it first), the script doesn't work because the field is behaving as a field, not a button anymore... ...stupid field or button or whatever it is.

Hi Kent

this solves your problem...a simple "Commit record/request"

A second problem comes on when user press CANCEL into the dialog...but a simple "Set error capture(on)" solves it too

InsertPhoto1or2ClickRev2.zip

Hi comment

the last example is a "genius" IDEA :waytogo:

...this solves your problem...a simple "Commit record/request"

Actually, it doesn't...If the record is commited the field only behaves as a button (with respect to mouse-clicking)

Actually, it doesn't...If the record is commited the field only behaves as a button (with respect to mouse-clicking)

And wasn't that what you ask for ?

EDIT: ok, i understand...there is a problem when the container is empty

Edited May 7, 200619 yr by Guest

so try this one.

InsertPhoto1or2ClickRev4.zip

Gee, thanks.

But there's one thing that still bothers me:

it uses the new stack order of script execution...

...

pre 8: first IN first OUT

from 8: last IN first OUT

I cannot find any reference to a change, and every test I tried seems to show it is LIFO in both versions (7.0v3 and 8.0v1, in my case). Can you please illuminate this point?

Hi Daniele,

Remember that I wrote in my response to LaRetta,

"If the user single-clicks on it when it's occupied it goes to that field to activate it in case the user wants to export or copy that image or anything else that can be done with a right-click/control-click."

This is the desired behavior of a single-click on the field when it's occupied, therefore the field needs to behave like a field in this instance, not as a button.

I don't think there's any way for me to have my cake and eat it too on this one. (of course, I'd be delighted to have someone prove me wrong on this)

Hi Kent, that was my concern ... they will click it once, remember it's supposed to be double ... I don't trust double-click/single click on stuff. That's just me however; I love this idea.

Michael, I'm getting inconsistent results on this process with 8.0v2. It appears that I can easily produce 1 click when double-clicking. Decreasing the duration doesn't appear to matter. A double-click on the first two breaks every 4-5 times (even without deselecting between attempts). Your third button is the most consistent but I even break it one out of every 6-7 attempts (if I deselect between attempts). The first button (global) breaks the most often.

Maybe I just double-click too fast - this is the speed I always double-click something. If I'm a fast double-clicker others might be as well. Just an observation. This is a great thread! :wink2:

?? Clicking faster than FM can compute? That's why I made the pause adjustable - so you can click slowly. Surely, it doesn't break when you click slowly?

FWIW, it works for me fine at about 0.7 sec - but I suspect this would vary from computer to computer, and certainly from user to user.

I see. Well I have duration on .1. No, it doesn't break when I click very slowly.

And maybe I have my system click-rate set high as well. Or maybe I drink too much coffee. :crazy2:

...that was my concern ... they will click it once' date=' remember it's supposed to be double ... I don't trust double-click/single click on stuff.[/quote']

Yeah, I've been putting more thought into the issue since you raised it and I'm beginning to wonder if a dialog box appearing on 1-click may be the "best" solution. I'll bring that up to my client. Ultimately though, the best solution is the one the client is the most happy with

My typical double-click speed is consistently interpreted as a single-click in every solution offered, so I've had to slow down just a hair to get a double-click to register. I don't see this as being much of a problem for the typical user, though.

But instead of feeling that I must be just very different than everyone else, I should clarify that the tests were the same no matter the duration setting. The consistency in break remained the same when I clicked at my normal speed.

I don't think the duration setting affects faster clicking once the user has a click rate that falls within the duration. The duration can only compensate for those clicking slower than the duration time.

I thought I was weird. Even during test phase, I was making myself slow down and was still beating it at .1 every 5-6 times. I feel better.

UPDATE: Yep, I realized that after I added it. That's why I took that part back off.

Edited May 7, 200619 yr by Guest

"If the user single-clicks on it when it's occupied it goes to that field to activate it in case the user wants to export or copy that image or anything else that can be done with a right-click/control-click."

So check the revision 5

InsertPhoto1or2ClickRev5.zip

I cannot find any reference to a change...

I'm searching for the documentation...

I agree with Kent. You should test this: set the pause to high, like 2 seconds. Then double-click, once, as fast as you can, and wait for the result. If you can get a response of 1 this way - you are simply clicking faster than the system can respond. (If not, I'll have to think about this further...).

So check the revision 5

You've just changed the flavor of the cake...I still can't eat it!

Seriously, this just reverts back to the behavior of Rev1, where the user has to click out of the occupied field after a single click before doing a double-click. I don't think FileMaker is capable of replicating this behavior of MS Outlook's photo field.

Hi, comment

here is something that explain that there is a difference from 7 and 8.

This is an article from Gaston Forgues (Softwares for humans)

Under FM8, the behavior with 'plug-in triggered scripts' is different. Depending on the situation, some triggered scripts will be placed at the top of the script execution stack, and some scripts will be placed at the bottom.

In the case you are using a script to trigger a sub-script (by using the 'set field' script step with EventScript in the source calculation) then the scripts triggered will be placed at the bottom of the script execution stack. Thus these 'plug-in scripts' will be executed after the currently running scripts. But actually, using EventScript from inside Scriptmaker doesn't happen so often. ("On the fly" script triggering is another subject...)

Usually, developers are using EventScript from within a table's field. This method allow the developer to trigger scripts upon predefined user actions (before update, after update). In this situation, the manual action made by a user on the field content WHILE another script was already executing will place the triggered script at the very top of the execution stack. This behavior is different because under FM7, the triggered scripts were always placed at the bottom of the execution stack no matter how the 'plug-in script' was triggered.

Here's some screenshots:

1. With the script debugger on (the phenomenon will be the same without the debugger), I'm using a button to trigger a script named : 'Check-out' :

image1

While this first script is running (or is running in pause mode), I place my cursor inside the small green field and I somehow change the content of this field. This field has an EventScript invocation so the script called 'TriggeredScript' is automatically triggered by the plug-in. This 'plug-in script' will then be placed at the top of the stack (highest execution priority). The screenshot below shows this interesting phenomenon :

image2

Well, that may be the case with 'plug-in triggered scripts'. All my attempts to find a difference between 7 and 8 without using a plug-in have failed.

Hi Michael,

Tests prove you both correct. Duration set at 2 seconds. Double-clicking as fast as I can produces 1 every time on all 3 so Kent and I are unusual clickers. I tried .0 as well. If you watch the Status Area Continue/Cancel, a script appears to activate when the button is released not when depressed. And if I finish my second click before Continue/Cancel activiates, I get 1 click. This is probably not new to anyone but me but I found it interesting. And it again supports your theory.

A final observation then I'll get off this thread. I ran a series of tests and the results of the tally are still interesting! Duration at .1, clicking as fast as I can ... I counted the successes (getting 2 clicks when I double-clicked) because there were few of them.

Button 1 fails 43% more often than buttons 2 or 3. I assume it's because of the Set Field[]? And there is one more difference (between 2 and 3) - when the file is first opened, double-click fails 26% more often on the first activation than on the second attempt. My test was limited (360 strokes per button) and (being human) key-click consistency can't be verified. I wish I could time key-clicks accurately. But I believe I was consistent enough that the 26% difference means something. It is subtle but I swear it to be true. Could it be cache?

What a wonderful way to spend a Sunday! Some people went fishing today; some went to movies but *I* double-clicked 1,000 times. I'm sick.

CLARIFICATION: Buttons 2 and 3 failed more often on first activation when file opened than compared to THEIR OWN success ratio (when it was the second or more activation) after file open. Button 3 had the highest success rate but it was only by 9.

Edited May 7, 200619 yr by Guest
Added clarification

...so Kent and I are unusual clickers.

Speak for yourself :jester:

Keep in mind that these are NOT really double-clicks - merely an inky-dinky attempt at a simulation thereof. A REAL double-click is recognized as such by the OS (where you have a panel to adjust the interval). Here the OS passes SINGLE clicks to Filemaker - at its leisure. A lot can happen on the way. (BTW, a standard mouse click is ALWAYS activated by button release).

(BTW, a standard mouse click is ALWAYS activated by button release).

Hi comment,

That may be true in Windows but it's not in Mac (OS X Tiger, at least), if I understand you correctly. The second click doesn't have to be released to activate an event in Safari. In the Bookmarks view if you double-click on a bookmark but don't let up after the second click it'll still go to that webpage.

Good points, though, about this technique not being a true double-click.

Edited May 8, 200619 yr by Guest

Brilliant, Comment!

For the record, genx, I did manage to beat you a couple of times - doubleclick counted as one. (I think so, anyway; it's impossible to be 100% certain.)

Hm. I thought I made it clear I was speaking about a SINGLE click. After all, there ARE no double-clicks in Filemaker for the developer - isn't that the very reason for this thread?

Beat me Re: What exactly?

As comment keeps saying, the whole thing works on single clicks not double. Once the system registers a single click the script is fired and then filemaker processes it. How long this takes is a combination between the OS and FM. But either way, it's two seperate single clicks.

Edited May 8, 200619 yr by Guest
thought

You had referred to clicks at the OS level so I thought you were speaking in general terms when you said, "a standard mouse click is ALWAYS activated by button release.

Hm, must've been the "ALWAYS" part of your statement that made me think you meant ALWAYS! :