FMX_SetToCurrentEnv during idle

[Jesse Barnum-2]

When I get the current expression environment during idle time, and  
call a calc that references fields in the database, it does not  
always work - sometimes I just get empty values for all of the  
fields. Calling Get() functions works 100% of the time.

I saw other people have had similar problems - here is a post from Jake:

> However, when I started using it, I found that it would work
> for "global" data like DatabaseNames and ScriptNames, but trying to  
> ask for
> "user" data like the contents of fields, it wouldn't always work.  And
> what's worse, instead of giving errors, it just returned nothing.

That's exactly what I'm running into. I couldn't really tell from  
that post if there was a solution for the problem or not. Has anybody  
else run into this? Since I am not handed an environment during idle,  
using FMX_SetToCurrentEnv seems like the only way to do it, but  
that's where I'm having problems. Here is a code snippet from my test  
idle handler:

        fError = FMX_SetToCurrentEnv(&(*fEnv)); //Is this right?
       
        if (fError != 0) {
                return;
        }
       
        fmx::TextAutoPtr text;
        fmx::DataAutoPtr result;
        text->Assign("\"First name: \" & Example::First name & \"Window  
name: \" & Get(WindowName)" );
        fEnv->Evaluate( *text, *result );
        char resultChar[100];
        result->GetAsText().GetBytes( resultChar, 100 );
        LOG("Idle calc result: %s\n", resultChar);

In my expression, the Get(WindowName) part always works, but the  
Example::First name part sometimes returns the correct value, and  
sometimes returns an empty string. Any solutions for this?

--Jesse Barnum, President, 360Works
http://www.360works.com 770-234-9293
FBA Platinum, FileMaker 8 Certified
== SuperContainer: A Better Container Field ==

[Jake Traynham]

Hi Jesse,

   At the moment, I don't remember posting about this before. Can you
tell me when that was from, or what the subject of the email was or a
link to the post on the web or anything so I can see if it'll jog my memory?

   As far as possible answers, are you doing this only during "safe"
idle?  Have you tried using ExecuteSQL instead of evaluating a calculation?

Jake

P.S. And yes, your FMX_SetToCurrentEnv() call is correct, at least it's
the way I use it.  I've also seen something like
FMX_SetToCurrentEnv(&fEnv->get()) or FMX_SetToCurrentEnv(fEnv->get()) ..
I'm not sure which is correct, but it's basically the same thing as what
you are already using.  It's just a matter of what looks nicer to you
probably.

Jesse Barnum wrote:

>
>
> When I get the current expression environment during idle time, and
> call a calc that references fields in the database, it does not
> always work - sometimes I just get empty values for all of the
> fields. Calling Get() functions works 100% of the time.
>
> I saw other people have had similar problems - here is a post from Jake:
>
>  > However, when I started using it, I found that it would work
>  > for "global" data like DatabaseNames and ScriptNames, but trying to
>  > ask for
>  > "user" data like the contents of fields, it wouldn't always work. And
>  > what's worse, instead of giving errors, it just returned nothing.
>
> That's exactly what I'm running into. I couldn't really tell from
> that post if there was a solution for the problem or not. Has anybody
> else run into this? Since I am not handed an environment during idle,
> using FMX_SetToCurrentEnv seems like the only way to do it, but
> that's where I'm having problems. Here is a code snippet from my test
> idle handler:
>
> fError = FMX_SetToCurrentEnv(&(*fEnv)); //Is this right?
>
> if (fError != 0) {
> return;
> }
>
> fmx::TextAutoPtr text;
> fmx::DataAutoPtr result;
> text->Assign("\"First name: \" & Example::First name & \"Window
> name: \" & Get(WindowName)" );
> fEnv->Evaluate( *text, *result );
> char resultChar[100];
> result->GetAsText().GetBytes( resultChar, 100 );
> LOG("Idle calc result: %s\n", resultChar);
>
> In my expression, the Get(WindowName) part always works, but the
> Example::First name part sometimes returns the correct value, and
> sometimes returns an empty string. Any solutions for this?
>
> --Jesse Barnum, President, 360Works
> http://www.360works.com <http://www.360works.com> 770-234-9293
> FBA Platinum, FileMaker 8 Certified
> == SuperContainer: A Better Container Field ==
>

--
Jake Traynham
Owner, CNS Plug-ins
http://www.cnsplug-ins.com/

[Jesse Barnum-2]

Hi Jake, thanks for responding!

The URL for the discussion I quoted is here:

http://www.nabble.com/Environment-Question-td898349.html#a901039

It's long, so search for "Well I don't really have anything that is  
still coded in this way"

I am pretty sure that I only doing this during 'safe' idle (I'll do  
some more testing to be 100% sure), and I have not tried ExecuteSQL  
because it won't do what I need (I need to get the binary data from a  
container field). I have a feeling that it probably would work OK for  
getting non-container data, because it is not related to the current  
user context.

--Jesse Barnum, President, 360Works
http://www.360works.com 770-234-9293
FBA Platinum, FileMaker 8 Certified
== SuperContainer: A Better Container Field ==

On May 22, 2008, at 10:47 AM, Jake Traynham wrote:

> Hi Jesse,
>
>    At the moment, I don't remember posting about this before. Can you
> tell me when that was from, or what the subject of the email was or a
> link to the post on the web or anything so I can see if it'll jog  
> my memory?
>
>    As far as possible answers, are you doing this only during "safe"
> idle?  Have you tried using ExecuteSQL instead of evaluating a  
> calculation?
>
> Jake
>
> P.S. And yes, your FMX_SetToCurrentEnv() call is correct, at least  
> it's
> the way I use it.  I've also seen something like
> FMX_SetToCurrentEnv(&fEnv->get()) or FMX_SetToCurrentEnv(fEnv->get
> ()) ..
> I'm not sure which is correct, but it's basically the same thing as  
> what
> you are already using.  It's just a matter of what looks nicer to you
> probably.

[Jesse Barnum-2]

I've verified for 100% sure that I am not calling the calc engine  
during an 'unsafe' call. Here is an example of some debugging  
statements that I stuck into the idle handler:

thread ID: -1610559488, cCurrentEnv: 1665976, ExprEnv: 672567216,  
Idle calc result: Window name: RemoteScripter simple demoGlobal: A  
global / First name: Bob
thread ID: -1610559488, cCurrentEnv: 1665976, ExprEnv: 672567216,  
Idle calc result: Window name: RemoteScripter simple demoGlobal: A  
global / First name: Bob
thread ID: -1610559488, cCurrentEnv: 1665976, ExprEnv: 672654448,  
Idle calc result: Window name: RemoteScripter simple demoGlobal: A  
global / First name: Bob
thread ID: -1610559488, cCurrentEnv: 1665976, ExprEnv: 672567216,  
Idle calc result: Window name: RemoteScripter simple demoGlobal: A  
global / First name: Bob
thread ID: -1610559488, cCurrentEnv: 1665976, ExprEnv: 672567216,  
Idle calc result: Window name: RemoteScripter simple demoGlobal:  /  
First name:
thread ID: -1610559488, cCurrentEnv: 1665976, ExprEnv: 672567216,  
Idle calc result: Window name: RemoteScripter simple demoGlobal:  /  
First name:
thread ID: -1610559488, cCurrentEnv: 1665976, ExprEnv: 672567216,  
Idle calc result: Window name: RemoteScripter simple demoGlobal:  /  
First name:
thread ID: -1610559488, cCurrentEnv: 1665976, ExprEnv: 672567216,  
Idle calc result: Window name: RemoteScripter simple demoGlobal:  /  
First name:
thread ID: -1610559488, cCurrentEnv: 1665976, ExprEnv: 672567216,  
Idle calc result: Window name: RemoteScripter simple demoGlobal:  /  
First name:
thread ID: -1610559488, cCurrentEnv: 1665976, ExprEnv: 672567216,  
Idle calc result: Window name: RemoteScripter simple demoGlobal:  /  
First name:
unsafe call; returning
thread ID: -1610559488, cCurrentEnv: 1665976, ExprEnv: 672567216,  
Idle calc result: Window name: RemoteScripter simple demoGlobal:  /  
First name:
thread ID: -1610559488, cCurrentEnv: 1665976, ExprEnv: 672567216,  
Idle calc result: Window name: RemoteScripter simple demoGlobal:  /  
First name:
thread ID: -1610559488, cCurrentEnv: 1665976, ExprEnv: 672567216,  
Idle calc result: Window name: RemoteScripter simple demoGlobal:  /  
First name:
thread ID: -1610559488, cCurrentEnv: 1665976, ExprEnv: 672567216,  
Idle calc result: Window name: RemoteScripter simple demoGlobal:  /  
First name:

You can see several things happening here - the first four idle  
handler calls return a global ("A global") and the first name field  
("Bob") successfully.
After that, it does 6 idle calls where the calc engine messes up and  
returns empty values, even for globals. Notice that the Get
(WindowName) function always works ("RemoteScripter simple demo"),  
even when normal FileMaker fields fail.
After that, I get an unsafe call, which I ignore and return. This is  
how I am sure that I am only calling the calc engine during safe calls.
I think get 4 more messed up calls.

This capture all happened in less than a second, with no user  
interaction - so it's not as if it stopped working when I clicked  
into a field or switched records or anything. It just simply works  
sometimes and doesn't work other times. You can see that everything  
is being called from the same thread, so I don't think it's a  
threading issue, the cCurrentEnv callback is always the same pointer,  
and the ExprEnv itself is almost always the same (in one case it was  
different).

--Jesse Barnum, President, 360Works
http://www.360works.com 770-234-9293
FBA Platinum, FileMaker 8 Certified
== SuperContainer: A Better Container Field ==

On May 22, 2008, at 11:10 AM, Jesse Barnum wrote:

> Hi Jake, thanks for responding!
>
> The URL for the discussion I quoted is here:
>
> http://www.nabble.com/Environment-Question-td898349.html#a901039
>
> It's long, so search for "Well I don't really have anything that is
> still coded in this way"
>
> I am pretty sure that I only doing this during 'safe' idle (I'll do
> some more testing to be 100% sure), and I have not tried ExecuteSQL
> because it won't do what I need (I need to get the binary data from a
> container field). I have a feeling that it probably would work OK for
> getting non-container data, because it is not related to the current
> user context.
>
> --Jesse Barnum, President, 360Works
> http://www.360works.com 770-234-9293
> FBA Platinum, FileMaker 8 Certified
> == SuperContainer: A Better Container Field ==
>
> On May 22, 2008, at 10:47 AM, Jake Traynham wrote:
>> Hi Jesse,
>>
>>    At the moment, I don't remember posting about this before. Can you
>> tell me when that was from, or what the subject of the email was or a
>> link to the post on the web or anything so I can see if it'll jog
>> my memory?
>>
>>    As far as possible answers, are you doing this only during "safe"
>> idle?  Have you tried using ExecuteSQL instead of evaluating a
>> calculation?
>>
>> Jake
>>
>> P.S. And yes, your FMX_SetToCurrentEnv() call is correct, at least
>> it's
>> the way I use it.  I've also seen something like
>> FMX_SetToCurrentEnv(&fEnv->get()) or FMX_SetToCurrentEnv(fEnv->get
>> ()) ..
>> I'm not sure which is correct, but it's basically the same thing as
>> what
>> you are already using.  It's just a matter of what looks nicer to you
>> probably.
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

[Jesse Barnum-2]

Sorry, that mangled the console output. I've attached a screenshot here:

http://demo.360works.com/idlecalcs.png

--Jesse Barnum, President, 360Works
http://www.360works.com 770-234-9293
FBA Platinum, FileMaker 8 Certified
== SuperContainer: A Better Container Field ==

[Jake Traynham]

Hello again,

   Wow, that post of mine was from 2005.  I don't remember writing it,
but everything in it is still valid.  The only time I'm getting data out
is when I'm using an expression environment that is passed to me via a
function call.  I don't think I have any plug-ins trying to access field
data on an idle call, but I do have plug-ins that are doing things like
creating tables on idle.  The environment must still be valid enough to
know what database file to create the tables in, but it could be a
situation where it just happens to be soon enough after a plug-in call
that it works (like your first 4 items here).

   The next thing I was going to suggest was testing to see what thread
you were in to see if that mattered, but you seem to already be doing
something like that.  I wonder though, where are you getting this thread
id.  Is this the thread you are currently running under, or are you
getting the id of the thread that called you (or is that even possible)?
  In your testing, has it ever started outputting the field values again
(as in, a few calls give you the values, then a whole bunch don't, then
a few more work, etc. etc.)?

   As far as getting the binary data out of a container field with SQL,
I sure wish you could.  Clay mentioned at one point that he thought
there was some way to get BLOB data in or out using a hexidecimal form,
but I have yet to figure it out.  I've done some testing with sql casts
and it acts like it wants to work, but maybe it just doesn't yet?  I
dunno.  ('select cast("image" as longvarbinary) from "data" where
rowid=1' gives an odd 5 "Command is invalid" error instead of the 1200
"Generic" error ...)  Maybe someone at FMI can chime in about that.

Jake

Jesse Barnum wrote:

>
>
> I've verified for 100% sure that I am not calling the calc engine during
> an 'unsafe' call. Here is an example of some debugging statements that I
> stuck into the idle handler:
>
>
> thread ID: -1610559488, cCurrentEnv: 1665976, ExprEnv: 672567216, Idle
> calc result: Window name: RemoteScripter simple demoGlobal: A global /
> First name: Bobthread ID: -1610559488, cCurrentEnv: 1665976, ExprEnv:
> 672567216, Idle calc result: Window name: RemoteScripter simple
> demoGlobal: A global / First name: Bobthread ID: -1610559488,
> cCurrentEnv: 1665976, ExprEnv: 672654448, Idle calc result: Window name:
> RemoteScripter simple demoGlobal: A global / First name: Bobthread ID:
> -1610559488, cCurrentEnv: 1665976, ExprEnv: 672567216, Idle calc result:
> Window name: RemoteScripter simple demoGlobal: A global / First name:
> Bobthread ID: -1610559488, cCurrentEnv: 1665976, ExprEnv: 672567216,
> Idle calc result: Window name: RemoteScripter simple demoGlobal:  /
> First name: thread ID: -1610559488, cCurrentEnv: 1665976, ExprEnv:
> 672567216, Idle calc result: Window name: RemoteScripter simple
> demoGlobal:  / First name: thread ID: -1610559488, cCurrentEnv: 1665976,
> ExprEnv: 672567216, Idle calc result: Window name: RemoteScripter simple
> demoGlobal:  / First name: thread ID: -1610559488, cCurrentEnv: 1665976,
> ExprEnv: 672567216, Idle calc result: Window name: RemoteScripter simple
> demoGlobal:  / First name: thread ID: -1610559488, cCurrentEnv: 1665976,
> ExprEnv: 672567216, Idle calc result: Window name: RemoteScripter simple
> demoGlobal:  / First name: thread ID: -1610559488, cCurrentEnv: 1665976,
> ExprEnv: 672567216, Idle calc result: Window name: RemoteScripter simple
> demoGlobal:  / First name: unsafe call; returningthread ID: -1610559488,
> cCurrentEnv: 1665976, ExprEnv: 672567216, Idle calc result: Window name:
> RemoteScripter simple demoGlobal:  / First name: thread ID: -1610559488,
> cCurrentEnv: 1665976, ExprEnv: 672567216, Idle calc result: Window name:
> RemoteScripter simple demoGlobal:  / First name: thread ID: -1610559488,
> cCurrentEnv: 1665976, ExprEnv: 672567216, Idle calc result: Window name:
> RemoteScripter simple demoGlobal:  / First name: thread ID: -1610559488,
> cCurrentEnv: 1665976, ExprEnv: 672567216, Idle calc result: Window name:
> RemoteScripter simple demoGlobal:  / First name:
> You can see several things happening here - the first four idle handler
> calls return a global ("A global") and the first name field ("Bob")
> successfully.After that, it does 6 idle calls where the calc engine
> messes up and returns empty values, even for globals. Notice that the
> Get(WindowName) function always works ("RemoteScripter simple demo"),
> even when normal FileMaker fields fail. After that, I get an unsafe
> call, which I ignore and return. This is how I am sure that I am only
> calling the calc engine during safe calls.I think get 4 more messed up
> calls.
> This capture all happened in less than a second, with no user
> interaction - so it's not as if it stopped working when I clicked into a
> field or switched records or anything. It just simply works sometimes
> and doesn't work other times. You can see that everything is being
> called from the same thread, so I don't think it's a threading issue,
> the cCurrentEnv callback is always the same pointer, and the ExprEnv
> itself is almost always the same (in one case it was different).
> --Jesse Barnum, President, 360Works
> http://www.360works.com <http://www.360works.com> 770-234-9293
> FBA Platinum, FileMaker 8 Certified
> == SuperContainer: A Better Container Field ==
>
> On May 22, 2008, at 11:10 AM, Jesse Barnum wrote:
>> Hi Jake, thanks for responding!
>>
>> The URL for the discussion I quoted is here:
>>
>> http://www.nabble.com/Environment-Question-td898349.html#a901039 
>> <http://www.nabble.com/Environment-Question-td898349.html#a901039>
>>
>> It's long, so search for "Well I don't really have anything that is  
>> still coded in this way"
>>
>> I am pretty sure that I only doing this during 'safe' idle (I'll do  
>> some more testing to be 100% sure), and I have not tried ExecuteSQL  
>> because it won't do what I need (I need to get the binary data from a  
>> container field). I have a feeling that it probably would work OK for  
>> getting non-container data, because it is not related to the current  
>> user context.
>>
>> --Jesse Barnum, President, 360Works
>> http://www.360works.com <http://www.360works.com> 770-234-9293
>> FBA Platinum, FileMaker 8 Certified
>> == SuperContainer: A Better Container Field ==
>>
>> On May 22, 2008, at 10:47 AM, Jake Traynham wrote:
>>> Hi Jesse,
>>>
>>>    At the moment, I don't remember posting about this before. Can you
>>> tell me when that was from, or what the subject of the email was or a
>>> link to the post on the web or anything so I can see if it'll jog  
>>> my memory?
>>>
>>>    As far as possible answers, are you doing this only during "safe"
>>> idle?  Have you tried using ExecuteSQL instead of evaluating a  
>>> calculation?
>>>
>>> Jake
>>>
>>> P.S. And yes, your FMX_SetToCurrentEnv() call is correct, at least  
>>> it's
>>> the way I use it.  I've also seen something like
>>> FMX_SetToCurrentEnv(&fEnv->get()) or FMX_SetToCurrentEnv(fEnv->get
>>> ()) ..
>>> I'm not sure which is correct, but it's basically the same thing as  
>>> what
>>> you are already using.  It's just a matter of what looks nicer to you
>>> probably.
>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>     (Yahoo! ID required)
>>
>>     mailto:[hidden email]
>> <mailto:[hidden email]>
>>
>>
>
>

--
Jake Traynham
Owner, CNS Plug-ins
http://www.cnsplug-ins.com/

[Jesse Barnum-2]

Hey Jake - thanks again for all your help. I've opened a case with  
FileMaker tech support, will try to get it escalated along 'proper  
channels' and see how that goes.

I don't think that it's related to proximity to regular plugin calls,  
because if I just sit there and watch it, it will flip back and forth  
between working and non-working all by itself in the idle handler,  
without ever touching the mouse or calling any functions, so 'yes' to  
your question about that.

The thread id is coming from pthread_self() on OS X. I'm not starting  
any new threads in my idle handler test, so the thread I'm running on  
is the same as the thread that called me.

I'm curious about how the Web Publishing Engine gets its data from  
the FM Server - is it using Corba, like the FM client, or is there  
some other (hackable?) data channel that it follows?

--Jesse Barnum, President, 360Works
http://www.360works.com 770-234-9293
FBA Platinum, FileMaker 8 Certified
== SuperContainer: A Better Container Field ==

On May 22, 2008, at 3:57 PM, Jake Traynham wrote:

> Hello again,
>
>    Wow, that post of mine was from 2005.  I don't remember writing it,
> but everything in it is still valid.  The only time I'm getting  
> data out
> is when I'm using an expression environment that is passed to me via a
> function call.  I don't think I have any plug-ins trying to access  
> field
> data on an idle call, but I do have plug-ins that are doing things  
> like
> creating tables on idle.  The environment must still be valid  
> enough to
> know what database file to create the tables in, but it could be a
> situation where it just happens to be soon enough after a plug-in call
> that it works (like your first 4 items here).
>
>    The next thing I was going to suggest was testing to see what  
> thread
> you were in to see if that mattered, but you seem to already be doing
> something like that.  I wonder though, where are you getting this  
> thread
> id.  Is this the thread you are currently running under, or are you
> getting the id of the thread that called you (or is that even  
> possible)?
>   In your testing, has it ever started outputting the field values  
> again
> (as in, a few calls give you the values, then a whole bunch don't,  
> then
> a few more work, etc. etc.)?
>
>    As far as getting the binary data out of a container field with  
> SQL,
> I sure wish you could.  Clay mentioned at one point that he thought
> there was some way to get BLOB data in or out using a hexidecimal  
> form,
> but I have yet to figure it out.  I've done some testing with sql  
> casts
> and it acts like it wants to work, but maybe it just doesn't yet?  I
> dunno.  ('select cast("image" as longvarbinary) from "data" where
> rowid=1' gives an odd 5 "Command is invalid" error instead of the 1200
> "Generic" error ...)  Maybe someone at FMI can chime in about that.
>
> Jake
>
> Jesse Barnum wrote:
>>
>>
>> I've verified for 100% sure that I am not calling the calc engine  
>> during
>> an 'unsafe' call. Here is an example of some debugging statements  
>> that I
>> stuck into the idle handler:
>>
>>
>> thread ID: -1610559488, cCurrentEnv: 1665976, ExprEnv: 672567216,  
>> Idle
>> calc result: Window name: RemoteScripter simple demoGlobal: A  
>> global /
>> First name: Bobthread ID: -1610559488, cCurrentEnv: 1665976, ExprEnv:
>> 672567216, Idle calc result: Window name: RemoteScripter simple
>> demoGlobal: A global / First name: Bobthread ID: -1610559488,
>> cCurrentEnv: 1665976, ExprEnv: 672654448, Idle calc result: Window  
>> name:
>> RemoteScripter simple demoGlobal: A global / First name: Bobthread  
>> ID:
>> -1610559488, cCurrentEnv: 1665976, ExprEnv: 672567216, Idle calc  
>> result:
>> Window name: RemoteScripter simple demoGlobal: A global / First name:
>> Bobthread ID: -1610559488, cCurrentEnv: 1665976, ExprEnv: 672567216,
>> Idle calc result: Window name: RemoteScripter simple demoGlobal:  /
>> First name: thread ID: -1610559488, cCurrentEnv: 1665976, ExprEnv:
>> 672567216, Idle calc result: Window name: RemoteScripter simple
>> demoGlobal:  / First name: thread ID: -1610559488, cCurrentEnv:  
>> 1665976,
>> ExprEnv: 672567216, Idle calc result: Window name: RemoteScripter  
>> simple
>> demoGlobal:  / First name: thread ID: -1610559488, cCurrentEnv:  
>> 1665976,
>> ExprEnv: 672567216, Idle calc result: Window name: RemoteScripter  
>> simple
>> demoGlobal:  / First name: thread ID: -1610559488, cCurrentEnv:  
>> 1665976,
>> ExprEnv: 672567216, Idle calc result: Window name: RemoteScripter  
>> simple
>> demoGlobal:  / First name: thread ID: -1610559488, cCurrentEnv:  
>> 1665976,
>> ExprEnv: 672567216, Idle calc result: Window name: RemoteScripter  
>> simple
>> demoGlobal:  / First name: unsafe call; returningthread ID:  
>> -1610559488,
>> cCurrentEnv: 1665976, ExprEnv: 672567216, Idle calc result: Window  
>> name:
>> RemoteScripter simple demoGlobal:  / First name: thread ID:  
>> -1610559488,
>> cCurrentEnv: 1665976, ExprEnv: 672567216, Idle calc result: Window  
>> name:
>> RemoteScripter simple demoGlobal:  / First name: thread ID:  
>> -1610559488,
>> cCurrentEnv: 1665976, ExprEnv: 672567216, Idle calc result: Window  
>> name:
>> RemoteScripter simple demoGlobal:  / First name: thread ID:  
>> -1610559488,
>> cCurrentEnv: 1665976, ExprEnv: 672567216, Idle calc result: Window  
>> name:
>> RemoteScripter simple demoGlobal:  / First name:
>> You can see several things happening here - the first four idle  
>> handler
>> calls return a global ("A global") and the first name field ("Bob")
>> successfully.After that, it does 6 idle calls where the calc engine
>> messes up and returns empty values, even for globals. Notice that the
>> Get(WindowName) function always works ("RemoteScripter simple demo"),
>> even when normal FileMaker fields fail. After that, I get an unsafe
>> call, which I ignore and return. This is how I am sure that I am only
>> calling the calc engine during safe calls.I think get 4 more  
>> messed up
>> calls.
>> This capture all happened in less than a second, with no user
>> interaction - so it's not as if it stopped working when I clicked  
>> into a
>> field or switched records or anything. It just simply works sometimes
>> and doesn't work other times. You can see that everything is being
>> called from the same thread, so I don't think it's a threading issue,
>> the cCurrentEnv callback is always the same pointer, and the ExprEnv
>> itself is almost always the same (in one case it was different).
>> --Jesse Barnum, President, 360Works
>> http://www.360works.com <http://www.360works.com> 770-234-9293
>> FBA Platinum, FileMaker 8 Certified
>> == SuperContainer: A Better Container Field ==
>>
>> On May 22, 2008, at 11:10 AM, Jesse Barnum wrote:
>>> Hi Jake, thanks for responding!
>>>
>>> The URL for the discussion I quoted is here:
>>>
>>> http://www.nabble.com/Environment-Question-td898349.html#a901039
>>> <http://www.nabble.com/Environment-Question-td898349.html#a901039>
>>>
>>> It's long, so search for "Well I don't really have anything that is
>>> still coded in this way"
>>>
>>> I am pretty sure that I only doing this during 'safe' idle (I'll do
>>> some more testing to be 100% sure), and I have not tried ExecuteSQL
>>> because it won't do what I need (I need to get the binary data  
>>> from a
>>> container field). I have a feeling that it probably would work OK  
>>> for
>>> getting non-container data, because it is not related to the current
>>> user context.
>>>
>>> --Jesse Barnum, President, 360Works
>>> http://www.360works.com <http://www.360works.com> 770-234-9293
>>> FBA Platinum, FileMaker 8 Certified
>>> == SuperContainer: A Better Container Field ==
>>>
>>> On May 22, 2008, at 10:47 AM, Jake Traynham wrote:
>>>> Hi Jesse,
>>>>
>>>>    At the moment, I don't remember posting about this before.  
>>>> Can you
>>>> tell me when that was from, or what the subject of the email was  
>>>> or a
>>>> link to the post on the web or anything so I can see if it'll jog
>>>> my memory?
>>>>
>>>>    As far as possible answers, are you doing this only during  
>>>> "safe"
>>>> idle?  Have you tried using ExecuteSQL instead of evaluating a
>>>> calculation?
>>>>
>>>> Jake
>>>>
>>>> P.S. And yes, your FMX_SetToCurrentEnv() call is correct, at least
>>>> it's
>>>> the way I use it.  I've also seen something like
>>>> FMX_SetToCurrentEnv(&fEnv->get()) or FMX_SetToCurrentEnv(fEnv->get
>>>> ()) ..
>>>> I'm not sure which is correct, but it's basically the same thing as
>>>> what
>>>> you are already using.  It's just a matter of what looks nicer  
>>>> to you
>>>> probably.
>>>
>>>
>>> ------------------------------------
>>>
>>> Yahoo! Groups Links
>>>
>>>
>>>     (Yahoo! ID required)
>>>
>>>     mailto:[hidden email]
>>> <mailto:[hidden email]>
>>>
>>>
>>
>>
>
> --
> Jake Traynham
> Owner, CNS Plug-ins
> http://www.cnsplug-ins.com/
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

[Jake Traynham]

Hello again,

   I put this through the debugger to see if maybe the callstack was
changing, but it's even constant:

PluginIdle
FMExternCallProc
Draco::DBPlugIn::IdleAll
Draco::FMSession::OnIdle
CFMProApp::Idle
CFMProApp::DispatchNullEvent
CMacEventPump::PumpEvent
CMacEventPump::Run
CMacApp::Main
main

No matter if it gets the value out of the field or not, the callstack is
always the same.  Weird.

   Another thing I noticed is that it's more likely to get the value if
the database window is active.  If you switch to a different app or
maybe even a different window within FileMaker (like the ScriptMaker
window), it's less likely to get the value.  So it seems it has to do
with the state of the filemaker session or something?

   Anyway, let us know if fmi tech can help at all.  This has been an
issue since the first version of FileMaker 7, so it'd be good to know if
it can be worked around or not.

Jake

P.S. As far as how the WPE gets its data, I would imagine it uses the
full internal api like it always has.  When you've got the headers for
all your libraries, and you are compiling with the same compiler, you
can do whatever you want. :)  Tomas, formally of 24u, hacked the first
versions for the SimpleHelp plug-in, but said it was a major pain
because they had to use the same exact compiler and libraries and what
not to get it to work right without crashing.  So, while it may be
hackable to some degree, it's probably more pain than it's worth, and
would make more sense to just ask FMI to help out.

Jesse Barnum wrote:

>
>
> Hey Jake - thanks again for all your help. I've opened a case with
> FileMaker tech support, will try to get it escalated along 'proper
> channels' and see how that goes.
>
>
> I don't think that it's related to proximity to regular plugin calls,
> because if I just sit there and watch it, it will flip back and forth
> between working and non-working all by itself in the idle handler,
> without ever touching the mouse or calling any functions, so 'yes' to
> your question about that.
>
> The thread id is coming from pthread_self() on OS X. I'm not starting
> any new threads in my idle handler test, so the thread I'm running on is
> the same as the thread that called me.
>
> I'm curious about how the Web Publishing Engine gets its data from the
> FM Server - is it using Corba, like the FM client, or is there some
> other (hackable?) data channel that it follows?
>
> --Jesse Barnum, President, 360Works
> http://www.360works.com <http://www.360works.com> 770-234-9293
> FBA Platinum, FileMaker 8 Certified
> == SuperContainer: A Better Container Field ==
>

--
Jake Traynham
Owner, CNS Plug-ins
http://www.cnsplug-ins.com/

[Jesse Barnum-2]

Hey Jake - thanks for the detailed troubleshooting help. I think at  
this point all I can do is hope FMI comes up with a solution. I'll  
post the solution here if they can help me.

--Jesse Barnum, President, 360Works
http://www.360works.com 770-234-9293
FBA Platinum, FileMaker 8 Certified
== SuperContainer: A Better Container Field ==

On May 23, 2008, at 11:32 AM, Jake Traynham wrote:

> Hello again,
>
>    I put this through the debugger to see if maybe the callstack was
> changing, but it's even constant:
>
> PluginIdle
> FMExternCallProc
> Draco::DBPlugIn::IdleAll
> Draco::FMSession::OnIdle
> CFMProApp::Idle
> CFMProApp::DispatchNullEvent
> CMacEventPump::PumpEvent
> CMacEventPump::Run
> CMacApp::Main
> main
>
> No matter if it gets the value out of the field or not, the  
> callstack is
> always the same.  Weird.
>
>    Another thing I noticed is that it's more likely to get the  
> value if
> the database window is active.  If you switch to a different app or
> maybe even a different window within FileMaker (like the ScriptMaker
> window), it's less likely to get the value.  So it seems it has to do
> with the state of the filemaker session or something?
>
>    Anyway, let us know if fmi tech can help at all.  This has been an
> issue since the first version of FileMaker 7, so it'd be good to  
> know if
> it can be worked around or not.
>
> Jake
>
> P.S. As far as how the WPE gets its data, I would imagine it uses the
> full internal api like it always has.  When you've got the headers for
> all your libraries, and you are compiling with the same compiler, you
> can do whatever you want. :)  Tomas, formally of 24u, hacked the first
> versions for the SimpleHelp plug-in, but said it was a major pain
> because they had to use the same exact compiler and libraries and what
> not to get it to work right without crashing.  So, while it may be
> hackable to some degree, it's probably more pain than it's worth, and
> would make more sense to just ask FMI to help out.

[Doug McLean]

Does anyone know whether the plug-in registration db still exists? I
have searched filemaker.com and wasted 30 minutes on the phone
speaking with two pleasant nincompoops in my attempt to find it.

Thanks for any leads...

Doug

[Jake Traynham]

Plug-in Registration DB?  What's that? :)

Jake

Doug McLean wrote:

>
>
> Does anyone know whether the plug-in registration db still exists? I
> have searched filemaker.com and wasted 30 minutes on the phone
> speaking with two pleasant nincompoops in my attempt to find it.
>
> Thanks for any leads...
>
> Doug
>
>

--
Jake Traynham
Owner, CNS Plug-ins
http://www.cnsplug-ins.com/

[Corn Walker]

On May 23, 2008, at 5:16 PM, Doug McLean wrote:

> Does anyone know whether the plug-in registration db still exists? I
> have searched filemaker.com and wasted 30 minutes on the phone
> speaking with two pleasant nincompoops in my attempt to find it.

I get a 404 page when trying to follow the old link <http://
www.filemaker.com/plugins/index.html>. I'd suggest dropping a line to  
Jeff Benjamin to see if it's still around or you can fill out the  
form <http://filemaker.com/company/website_feedback.html> to tell  
them the page is missing.


Corn Walker
The Proof Group
http://proofgroup.com/