Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

This topic is 6775 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted (edited)

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. :wink2:

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

Edited by Guest
Posted

"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

Posted

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...).

Posted

So check the revision 5

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

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.

Posted

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):B

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

Part1.png

Part2.png

Posted

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.

Posted (edited)

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. :crazy2:

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 by Guest
Added clarification
Posted

...so Kent and I are unusual clickers.

Speak for yourself :jester:

Posted

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).

Posted (edited)

(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 by Guest
Posted

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.)

Posted

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?

Posted (edited)

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 by Guest
thought
Posted

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! :

Posted

Context is everything. LaRetta said that "a script appears to activate when the button is released not when depressed." To which I replied the above, namely that these are single clicks, and that ... let's just drop it, OK?

  • Newbies
Posted

Hi,

I only read the first few posts of this topic, so someone may have already suggested something similar...

it would seem to me, that the best way to do it, would be to make the container field a button that performs this script:

If [ ContainerField = "" or NewTextField = 1]

SUBSCRIPT

Set Field [NewTextField] , [""]

Exit Script

End If

If [ ContainerField and NewTextField ≠ 1 ]

Set Field [NewTextField] , [ 1 ]

End If

This topic is 6775 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.