On Wed, Sep 2, 2015 at 11:19 AM, Mark Wieder wrote:
> Dr. Hawkins writes:
>
> > Having solved it for my own, I'm not going to worry about this any
> further
> > if it can't bite people now . . .
>
> My guess, without having looked at your stack, is that there is a
> previously compiled script th
Dr. Hawkins writes:
> Having solved it for my own, I'm not going to worry about this any further
> if it can't bite people now . . .
My guess, without having looked at your stack, is that there is a
previously compiled script that uses the command syntax. If you
haven't recompiled it then it won
On Wed, Sep 2, 2015 at 8:01 AM, Mark Waddingham wrote:
> I suspect this is a lingering definition which was somewhere in the
> message path in the IDE.
>
> When the engine looks for what handler to call it checks each stage in the
> message path in order for the pair (handler type, handler name).
Therefore, if you are seeing this in the IDE then it is likely via
something IDE specific you are using *or* you have lingering
definitions in
a library stack or similar somewhere which you are loading into the
IDE
I'll create another test, then. It may have run the code in an older
version
On Wed, Sep 2, 2015 at 7:29 AM, Mark Waddingham wrote:
> When you say 'when executed in the IDE' in what context do you mean? A
> script? The message box?
>
I mean that when my stack and library stack run in the IDE, it doesn't
choke on that line, but calls the function from the line "somefunct
On 2015-09-02 16:13, Dr. Hawkins wrote:
After a couple of days of frustration, compiling standalone to get test
messages, I discovered:
function someFunct a, b
then a script that has
someFunct cat, dog
will execute someFunct in the IDE. In a standalone, it fails to find
the
handler.
I
