Re: private command gotcha

2017-09-09 Thread Monte Goulding via use-livecode

> On 10 Sep 2017, at 1:16 pm, Mark Wieder via use-livecode 
>  wrote:
> 
>> FWIW I would dearly love send in time to remember the caller and if the 
>> target is the caller then allow private handlers.
> 
> That. Very that.
> Also private callbacks for socket messages.

Socket callbacks are basically send in 0 when from when the callback needs to 
be sent. As in they go via pending messages the same as send. So if it’s 
supported for send then it should work for sockets.

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: private command gotcha

2017-09-09 Thread Mark Wieder via use-livecode

On 09/07/2017 03:06 PM, Monte Goulding via use-livecode wrote:


FWIW I would dearly love send in time to remember the caller and if the target 
is the caller then allow private handlers.


That. Very that.
Also private callbacks for socket messages.

--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: private command gotcha

2017-09-08 Thread Bob Sneidar via use-livecode

> On Sep 8, 2017, at 08:04 , Bob Sneidar via use-livecode 
>  wrote:
> 
> Looks like others have answered your question in my stead. :-) I will give 
> you a good use case. 
 

I will add this too. It would be great if a behavior had access to the local 
script's constants as well. This is how I make the scripts generic and 
universal in scope. I have the header of the script look something like this:

constant cTableName = "service"
constant cDGName = "dgService"
constant cPriKey = "serviceid"
constant cFocusField = "fldServiceDate"
constant cAltTable1 = "customers"
constant cAltKey1 = "custid"
constant cAltTable2 = "sites"
constant cAltKey2 = "siteid"

If a behavior had access to these then a statement like the following would 
work:

put aAlt1Record [cAltKey1] into tPriKeyValue1
put "SELECT * FROM " & cTableName into tQuery
if tPriKeyValue1 is not empty then put "WHERE " & cAltKey1 & " = " & 
tPriKeyValue1 after tQuery

etc. 
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: private command gotcha

2017-09-08 Thread Bob Sneidar via use-livecode
Looks like others have answered your question in my stead. :-) I will give you 
a good use case. 

I have a series of buttons on various cards/substacks that all do almost the 
exact same thing: Query for data, populate the card, create delete edit data, 
etc. This makes them prime candidates for behaviors, especially now that I have 
15 different "forms" that use them. 

I say *almost* the exact same things because certain cards, like the site card 
for instance need to do a little more. I save the SMTP configuration data for a 
particular site including the password which I encrypt in transit and in 
storage. I call it customFormStuff. 

So a behavior could be written to "dispatch customFormStuff to me" and if there 
was no handler it would silently fail while the LC engine and the rest of the 
world went on in blissful ignorance. Now I could write the behavior to be form 
specific and check the name of the card and act accordingly, but that makes the 
behavior non-portable/non-scalable. 

Bob S


> On Sep 7, 2017, at 14:01 , Monte Goulding via use-livecode 
>  wrote:
> 
> 
>> On 8 Sep 2017, at 3:57 am, Bob Sneidar via use-livecode 
>>  wrote:
>> 
>> Here's a surprise! You cannot dispatch to a private command or function, 
>> EVEN THOUGH the private command or function is in the SAME SCRIPT!
> 
> Nor can you send in time… however why do you want to dispatch to the same 
> script?
> 
> Cheers
> 
> Monte
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: private command gotcha

2017-09-07 Thread Monte Goulding via use-livecode

> On 8 Sep 2017, at 8:49 am, Phil Davis via use-livecode 
>  wrote:
> 
> Clearly the complexity you're painfully aware of is nicely hidden from me by 
> LC script, where I tend to think all things are most likely possible. It's 
> good for bubble-dwellers like myself to occasionally be pulled back into 
> reality. I guess. ;-)

Ah… ok so I probably need to explain this a bit better.

When you set a behavior you don’t just include the behavior object in the 
message path. There is something more like an instance of the behavior object 
script attached to the object and this has its own set of script locals so that 
if the behavior is used multiple times the locals aren’t all mixed up by other 
users of the behavior. As a result if we wanted private handlers to be 
supported in the callers script in send and dispatch and we wanted that to also 
work in behaviors then we would need something interesting… perhaps we could 
deal with it by allowing dispatch to me from a behavior to flag that it was 
sent from a particular behavior use so that’s the script that would allow 
private handlers… anyway… Mark would know what to do ;-)

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: private command gotcha

2017-09-07 Thread Phil Davis via use-livecode
Clearly the complexity you're painfully aware of is nicely hidden from 
me by LC script, where I tend to think all things are most likely 
possible. It's good for bubble-dwellers like myself to occasionally be 
pulled back into reality. I guess. ;-)


Thanks -
Phil


On 9/7/17 3:06 PM, Monte Goulding via use-livecode wrote:

On 8 Sep 2017, at 7:19 am, Phil Davis via use-livecode 
 wrote:

You asked me a similar question on 11-Nov-2016 - here is the back-and-forth. 
Sometimes we have our reasons! :-)

Ha… OK back in my box then ;-)

FWIW I would dearly love send in time to remember the caller and if the target 
is the caller then allow private handlers. I often have to write long 
complicated handler names for things simply because they will be in the message 
path and I want to avoid their conflict with other handlers… It’s a little 
hairy a proposition when it comes to behaviors as I’m not really sure what 
happens if you send to `this me`… you probably don’t get the script locals 
related to `me`… would need some testing I guess.

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


--
Phil Davis


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: private command gotcha

2017-09-07 Thread Monte Goulding via use-livecode

> On 8 Sep 2017, at 7:19 am, Phil Davis via use-livecode 
>  wrote:
> 
> You asked me a similar question on 11-Nov-2016 - here is the back-and-forth. 
> Sometimes we have our reasons! :-)

Ha… OK back in my box then ;-)

FWIW I would dearly love send in time to remember the caller and if the target 
is the caller then allow private handlers. I often have to write long 
complicated handler names for things simply because they will be in the message 
path and I want to avoid their conflict with other handlers… It’s a little 
hairy a proposition when it comes to behaviors as I’m not really sure what 
happens if you send to `this me`… you probably don’t get the script locals 
related to `me`… would need some testing I guess.

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: private command gotcha

2017-09-07 Thread Phil Davis via use-livecode

Make that 8-Nov-2016.
Phil

On 9/7/17 2:19 PM, Phil Davis wrote:
You asked me a similar question on 11-Nov-2016 - here is the 
back-and-forth. Sometimes we have our reasons! :-)


--
Phil Davis


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: private command gotcha

2017-09-07 Thread Phil Davis via use-livecode


On 9/7/17 2:01 PM, Monte Goulding via use-livecode wrote:

On 8 Sep 2017, at 3:57 am, Bob Sneidar via use-livecode 
 wrote:

Here's a surprise! You cannot dispatch to a private command or function, EVEN 
THOUGH the private command or function is in the SAME SCRIPT!

Nor can you send in time… however why do you want to dispatch to the same 
script?


Hi Monte,
You asked me a similar question on 11-Nov-2016 - here is the 
back-and-forth. Sometimes we have our reasons! :-)

Phil Davis

Actually here's another situation where I've used 'dispatch' simply to 
avoid a 'do'. But I could as easily use 'send' to get the job done:



function app_helperAppPath pAppName
    dispatch function ( "_helperAppPath_" & the platform ) to me with 
pAppName

    return the result
end app_helperAppPath


function _helperAppPath_MacOS pAppName
    -- Mac-specific app path discovery code
end _helperAppPath_MacOS


function _helperAppPath_Win32 pAppName
    -- Windows-specific app path discovery code
end _helperAppPath_Win32


Phil Davis



On 11/8/16 5:27 PM, Monte Goulding wrote:

On 9 Nov. 2016, at 12:23 pm, Phil Davis  wrote:

Use case: You use 'dispatch' as a coding style preference.

(That's all I could come up with.)



Actually thinking on it I can imagine a use case but it fails if you 
are wanting to dispatch a private handler:


dispatch “SomethingOverridableInABehaviorInstance” to me

command SomethingOverridableInABehaviorInstance
    — default implementation
end SomethingOverridableInABehaviorInstance 





Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


--
Phil Davis

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: private command gotcha

2017-09-07 Thread Monte Goulding via use-livecode

> On 8 Sep 2017, at 3:57 am, Bob Sneidar via use-livecode 
>  wrote:
> 
> Here's a surprise! You cannot dispatch to a private command or function, EVEN 
> THOUGH the private command or function is in the SAME SCRIPT!

Nor can you send in time… however why do you want to dispatch to the same 
script?

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

private command gotcha

2017-09-07 Thread Bob Sneidar via use-livecode
Here's a surprise! You cannot dispatch to a private command or function, EVEN 
THOUGH the private command or function is in the SAME SCRIPT! And since 
dispatch fails SILENTLY. I *almost* introduced a but where my passwords no 
longer encrypted/decrypted in transit to my database! 

Bob S  <--- begins to re-enable all the safeties on the torpedoes>



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode