Java update?

[J. Landman Gay via use-livecode]

I just received notification that Java version 8 update 231 is 
available. I have an older version of Java 8. Should I update?


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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: Groups in the message path: Trapping Mouseup

[Richard Gaskin via use-livecode]

Mark Wieder wrote:
> The syntax for describing the message path gets
> pretty gnarly.

It gets somewhat simpler when we consider the origins of the object 
model, though admittedly this is help more for us ol' timers than 
newcomers.


For newcomers I just don't mention backgrounds at all unless there's a 
specific need for it, and as long as I do that the message path is 
pretty easily learned,



HISTORY
---

HC didn't have groups, and its background was a layer that filled the 
entire card.  For what it was, its message path was reasonable 
straightforward once you learned what the background layer is and how to 
use it.


MC had groups, far more flexible than backgrounds, and their place in 
the message path is consistent with everything else: starting at the 
control, moving on to containers the control is within.


MC's groups were super-awesome for many of us HC fans who'd dreamed of 
such a feature for years, BUT -


The MC object model had no background layer, so importing HC stacks 
would be a non-starter.


So Dr. Raney adapted the group object so that it could also serve the 
role of an HC background.  Once a group is made sharable, it acts like 
an HC group.


Sounds good, but -

It's counter to the rest of the MC object model's message path.

So, after MC became LC, Mark Waddingham explored ways to both retain the 
compatibility with HC while respecting that LC is inherently a different 
model, and split the way shared groups are handled into two properties:


sharedBehavior: allows a group to be automatically copied to new cards, 
retaining the simplicity of the object model in the message path, in 
which messages flow from the control through its containers in visual 
order (group then card then stack).


backgroundBehavior: emulates HC by altering the position of the object 
in the message path per HC's convention for backgrounds (card then 
background then stack).



CURRENT USAGE
-

As long as we think of backgroundBehavior as a sort of HC compatibility 
mechanism, distinguishing its affect on the message path becomes easier.


For newcomers, I don't even mention backgroundBehavior at all, 
introducing them only to sharedBehavior.  With this orientation I find 
they enjoy the benefits of shared groups and they never get confused.


--
Richard Gaskin
Fourth World Systems

___
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: Groups in the message path: Trapping Mouseup

[Mark Wieder via use-livecode]

On 12/9/19 11:13 AM, Alex Tweedly via use-livecode wrote:


I think the correct (and nit-picky) statement is ...

Mark Weider says "A background group will definitely get the message 
before the stack
script does. Also any script being used as a behavior **for the 
background group**."


**and also a behavior script for the object being clicked on**



Hope I'm not misconstruing it, and that's not making everything more 
confusing ...


Thanks for clarifying. The syntax for describing the message path gets 
pretty gnarly.


--
 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: Groups in the message path: Trapping Mouseup

[Alex Tweedly via use-livecode]

On 12/9/19 6:30 AM, Sannyasin Brahmanathaswami via use-livecode wrote:

In this use case,

- the button "starWidget"  is a "standalone" button on an independent 
layer on the card  and not a part of any group
-- @Jacque... the groups that are trapping the mouseup I are 
background groups using on various card.
  Mark Weider says "A background group will definitely get the 
message before the stack

script does. Also any script being used as a behavior."

BR: is this "really" expected behavior? gosh, I hope not! 
"Encapsulation"would mean


BR - are you maybe reading more into it than Mark meant.

I think the correct (and nit-picky) statement is ...

Mark Weider says "A background group will definitely get the message 
before the stack
script does. Also any script being used as a behavior **for the 
background group**."


Hope I'm not misconstruing it, and that's not making everything more 
confusing ...


Alex.

___
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: Help Wrapping HTMLTidy in LCB

[Trevor DeVore via use-livecode]

On Fri, Nov 22, 2019 at 10:30 AM Trevor DeVore 
wrote:

> While looking at solutions for converting HTML into XHTML that can be
> parsed by revXML I decided to test HTMLTidy which has an option to output
> the input as XHTML. While I could bundle up the tidy command line tool and
> include it with my app, I prefer to wrap things up in LCB if possible.
>
> Unfortunately I haven't gotten very far with HTMLTidy and I'm
> hoping someone else might be able to figure out what I'm doing wrong. If
> you are up for loading up an LCB project in LC 9 on macOS and looking at
> some C files then please read on:
>

UPDATE:

I made some progress on the HTMLTidy project and this morning Mark
Waddingham and Brian Milby helped me over the last hurdle. The code base
now has a tidyHTMLToXHTML() function which works on macOS. You can try it
out using the test stack included in the repo. The code may also be of
interest to those trying to wrap other libraries.

https://github.com/trevordevore/lc-htmltidy

I will be adding the Windows DLL so that the extension works on Windows and
then trying to create a sensible API around HTMLTidy for my current needs.
I don't plan on making it feature complete at the moment as I just need to
for my own work. If someone else wanted to take that up they are welcome to.

-- 
Trevor DeVore
ScreenSteps
www.screensteps.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: Groups in the message path: Trapping Mouseup

[Mark Waddingham via use-livecode]

On 2019-12-09 14:30, Sannyasin Brahmanathaswami via use-livecode wrote:

-- background groups: "encapsulated" only receive mouse/touch events
from objects that are contain in "itself" --  group
-- behaviors: "encapsulated": only receive mouse events for the object
or group the behavior is assigned to.

Isn't this a bug?  Otherwise, "We have chaos on the Highway 666, total
car wreck on the Message Path"


No - background groups have always worked this way (and behaviors work 
the way you'd expect, they receive events which the object they are 
attached to doesn't handle).


All background groups placed on a card appear after the card in the 
message path.


There are two settings you can apply to a group - 'Shared Group' and 
'Background behavior'.


The 'Shared Group' setting means it can be placed on more than one card.

The 'Background Behavior' setting means it behaves like a background - 
rather than a normal group.


If you turn 'background behavior' off, then your shared group should no 
longer receive messages after the card does.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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: Groups in the message path: Trapping Mouseup

[Mark Wieder via use-livecode]

On 12/9/19 6:30 AM, Sannyasin Brahmanathaswami via use-livecode wrote:

In this use case,

- the button "starWidget"  is a "standalone" button on an independent layer on 
the card  and not a part of any group
-- @Jacque... the groups that are trapping the mouseup I are background groups 
using on various card.
  
Mark Weider says "A background group will definitely get the message before the stack

script does. Also any script being used as a behavior."

BR: is this "really" expected behavior? gosh, I hope not! "Encapsulation"would 
mean


If you set a group to have background behavior then it sits above the 
stack layer in the message path (or below, depending on how you view the 
layers). At any rate, messages will hit the background group before the 
stack script sees them. That's the way it is, the way it has always 
been, and the way the path was designed from the start. If you want 
something different you need to rethink your stack design.


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

[ANN] This Week in LiveCode 205

[panagiotis merakos via use-livecode]

Hi all,

Read about new developments in LiveCode open source and the open source
community in today's edition of the "This Week in LiveCode" newsletter!

Read issue #205 here: http://bit.ly/2sYLm4d

This is a weekly newsletter about LiveCode, focussing on what's been
going on in and around the open source project. New issues will be
released weekly on Mondays. We have a dedicated mailing list that will
deliver each issue directly to you e-mail, so you don't miss any!

If you have anything you'd like mentioned (a project, a discussion
somewhere, an upcoming event) then please get in touch.

-- 
Panagiotis Merakos 
LiveCode Software Developer

Everyone Can Create Apps 
___
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: Groups in the message path: Trapping Mouseup

[Paul Dupuis via use-livecode]

I use groups in use cases where I want a on mouseDown script in the 
group to respond to any mouse click anywhere in the rect of the group, 
so, no, groups should not ONLY respond to mouse messages passed though 
object contained in the group



If you have groups where you need to pass a mouseDown (or mosueWhatever) 
mesage to the card or stack, just add a behavior to the group for a 
script that contain handlers like


on mouseDown
  pass mouseDown
end mouseDown

on mouseUp
  pass mouseUp
end mouseUp

Although if there is no handler for the mouse event it should pass to 
the card and then the stack and then any library or backscripts and then 
the engine.


 On 12/9/2019 9:30 AM, Sannyasin Brahmanathaswami via use-livecode wrote:

In this use case,

- the button "starWidget"  is a "standalone" button on an independent layer on 
the card  and not a part of any group
-- @Jacque... the groups that are trapping the mouseup I are background groups 
using on various card.
  
Mark Weider says "A background group will definitely get the message before the stack

script does. Also any script being used as a behavior."

BR: is this "really" expected behavior? gosh, I hope not! "Encapsulation"would 
mean

-- background groups: "encapsulated" only receive mouse/touch events from objects that 
are contain in "itself" --  group
-- behaviors: "encapsulated": only receive mouse events for the object or group 
the behavior is assigned to.

Isn't this a bug?  Otherwise, "We have chaos on the Highway 666, total car wreck on 
the Message Path"

___
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: Groups in the message path: Trapping Mouseup

[Sannyasin Brahmanathaswami via use-livecode]

In this use case, 

- the button "starWidget"  is a "standalone" button on an independent layer on 
the card  and not a part of any group
-- @Jacque... the groups that are trapping the mouseup I are background groups 
using on various card.
 
Mark Weider says "A background group will definitely get the message before the 
stack 
script does. Also any script being used as a behavior."

BR: is this "really" expected behavior? gosh, I hope not! "Encapsulation"would 
mean

-- background groups: "encapsulated" only receive mouse/touch events from 
objects that are contain in "itself" --  group 
-- behaviors: "encapsulated": only receive mouse events for the object or group 
the behavior is assigned to.

Isn't this a bug?  Otherwise, "We have chaos on the Highway 666, total car 
wreck on the Message Path"

___
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

AW: OT: update RDS SSL/TSL certificates at aws

[Tiemo Hollmann TB via use-livecode]

Thank you Matthias for your experience.

I didn't tested yet, but I hope I won't run into an SSL verification error. And 
actually I think in my case the SSL change on the db server won't affect my LC 
programs at all, because there is PHP in between, which connects to the db.

Thanks
Tiemo

-Ursprüngliche Nachricht-
Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im Auftrag von 
Matthias Rebbe via use-livecode
Gesendet: Dienstag, 3. Dezember 2019 11:24
An: How to use LiveCode 
Cc: Matthias Rebbe 
Betreff: Re: OT: update RDS SSL/TSL certificates at aws

Tiemo,

i have no experiences with AWS. But what i can say is, that when changing an 
SSL certificate on a server  there should no changes be required in the 
frontend application created with LC. At least here i did not encounter any 
problems when i switched from unsecure to secure connections or when a server 
certificate was renewed / replaced.

What i´ve encountered in one case was that   i´ve received an SSL verification 
error. I think it was tsnet/curl error 48.

As a workaround  i used  tsNetVerifySSLPeer false   to disable verification.


Regards,
Matthias


Matthias Rebbe

free tools for Livecoders:
InstaMaker 
WinSignMaker Mac 

> Am 03.12.2019 um 09:18 schrieb Tiemo Hollmann TB via use-livecode 
> mailto:use-livecode@lists.runrev.com>>:
> 
> Hello,
> 
> this is a little bit off topic, but I hope I find here some experts 
> and hints to this issue.
> 
> I have some LC programs which communicate via https to PHP programs on 
> a webserver. Those PHP programs communicate with a RDS database on a 
> aws server.
> 
> 
> 
> Now I got a mail from aws, that they are going to exchange their 
> SSL/TSL certificates on the server and I have to take action to avoid 
> interruption of my applications. As far as I have understood, I have to do 
> two steps. 1.
> I have to renew the certificate from my RDS database at aws via the 
> aws console. Ok that seems to be some clicks at the aws console and that's it.
> 
> But 2. aws says, I should test my applications in an staging 
> environment, if everything works fine with the new certificates. And here 
> comes my question.
> I have no idea, what to test and what to look for, much less, where in 
> my PHP or even in my LC programs anything reflects to SSL certificates 
> and where I could change anything (and if yes what), if the test would fail.
> 
> 
> 
> Perhaps I am thinking to complex and all this isn't related to my apps 
> at all, but it scares me, because of the aws announcement "to avoid 
> any broken apps"
> 
> 
> 
> Has anybody experience with this issue in relation to LC and PHP?
> 
> 
> 
> Thanks for any hints how to handle this issue
> 
> 
> 
> Tiemo
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> 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


___
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