Object Referencing in LC 9.0.0

2018-05-26 Thread Michael Doub via use-livecode

Can someone using 9.0.0 help me out?

This used to work in LC 7 but now generates an error on the second line 
(*put*thelongidofobjRef intot1).  What is the new correct syntax?   This 
popped up in the MasterLibrary.


-= Thanks
  Mike


*on*seSetObjectState objRef, objState*
   put*thelongidofobjRef intot1 *
   put*thelongidofbtn"Lib"ofcd"LibMgr"ofstack"MasterLibrary"intot2*
   if* t1 = t2 andobjState = "applied"*then**
       send*"updateMasterIndex"tocd"LibMgr"ofstack"MasterLibrary"in1ticks*
   end* *if**
   pass*seSetObjectState*
end*seSetObjectState

___
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: is a date

2017-10-14 Thread Michael Doub via use-livecode

What about this from the Master Library from Ken Ray?

function isDate pWhat
   /* isDate Date
   Syntax:
   isDate (pWhat)
   Examples:
   isDate("10/10/2001")
   Description:
   Determines if the container passed to it in  contains a valid 
date.


   Returns true or false.

   Source:
   Ken Ray, sdtlib 1.0b
   isDate */
   convert pWhat to short date
   return not(the result is "invalid date")
end isDate


On 10/14/17 3:52 PM, J. Landman Gay via use-livecode wrote:

On 10/14/17 2:14 PM, Yves COPPE via use-livecode wrote:

Try this

function CheckDate pDateToCheck

return 
matchText(pDateToCheck,"([1-9]|[12][0-9]|3[01])/(0[1-9]|1[0-2])/([0-9][0-9][0-9][0-9])")


end CheckDate


Promising, but fails with dates like "1/1/19".




___
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: Color Conversion - RGB to HSV and back... (almost)

2017-04-14 Thread Michael Doub via use-livecode
Al,  I wrote some color conversion routines a long time ago. They are in 
the MasterLibrary:


https://www.dropbox.com/s/3wpwn3hfbmpl7sk/MasterLibrary.livecode?dl=0

I cant comment on their ability to not loose precision on a round trip.

-= Mike


On 4/13/17 6:14 PM, Alejandro Tejada via use-livecode wrote:

Hi All,

Download this GUI Stack for Scott Raney's Color Conversion Functions:
RGB to HSV and HSV to RGB from this forum post:
http://forums.livecode.com/viewtopic.php?f=10=29127

Only for certain colors this is a lossy conversion: Once you convert some
RGB colors to HSV, the function HSVtoRGB does not convert them back
exactly as they were before.

Does anyone knows or have created a pair of RGB/HSV color conversion
functions that do not lose (or change) color information?

Thanks in advance!

Al
___
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: Problem with converting time

2017-03-17 Thread Michael Doub via use-livecode
Sorry Mark and Richard.   Here is the real code snipit that includes a 
hack that seems to work:


getaData[x]["time"]
if not(theenvironmentisamongtheitems"development,standalone 
application") then

subtract(4*60*60) fromit
end if
convertit todateitems

Mark, in your situation, you and the server are in the same timezone so 
I would not expect to see a problem.   I have no idea where my server 
is, but it must not be in my timezone.  I am guessing on the west coast 
since taking off 4 hours seems to fix the problem.


It still does not make any sense why a timezone comes into play at all.

Here is the silly little app:   Http://tarwheels.net/weather   It has 
been really cold  here the last few days and I was not able to cycle, so 
this was a fun diversion.  Seems to work, but it has not had much 
testing.  And as you can see I know next to nothing about making things 
look nice in html.


-= Mike


On 3/17/17 4:42 PM, Mark Wieder via use-livecode wrote:

On 03/17/2017 01:20 PM, Michael Doub via use-livecode wrote:

Sorry guys, I must not have been clear in my statement of the problem.
Here is the code:

put 1489755600 into tVar
convert tVar into dateitems
 -- on the mac tVar contains 2017,3,17,9,0,0,6
 -- on the server tVar contains 2017,3,17,12,0,0,6

The local time should not be involved since you are converting a fixed
value.  What is happening?


Sorry - I can't replicate that.
With the desktop and server engines running on the same machine,

put 1489755600 into tVar
convert tVar into dateitems

gives me
IDE message box: 2017,3,17,6,0,0,6
server:  2017,3,17,6,0,0,6

Note that "convert into" is not supported.
It might be better to post the code you're actually using.



___
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: Problem with converting time

2017-03-17 Thread Michael Doub via use-livecode
Sorry guys, I must not have been clear in my statement of the problem.  
Here is the code:


put 1489755600 into tVar
convert tVar into dateitems
 -- on the mac tVar contains 2017,3,17,9,0,0,6
 -- on the server tVar contains 2017,3,17,12,0,0,6

The local time should not be involved since you are converting a fixed 
value.  What is happening?


-= Mike


On 3/17/17 12:44 PM, Richard Gaskin via use-livecode wrote:

Michael Doub wrote:

> time = 1489755600
> Mac:  dateitems = 2017,3,17,9,0,0,6
> server:   dateitems = 2017,3,17,12,0,0,6
>
> Code:   get time
> convertit to dateitems
>
> Richard here is another example:
> time = 1489752000
> mac:dateitems = 2017,3,17,8,0,0,6
> server: dateitems = 2017,3,17,12,0,0,6
>
> I just wanted to double check that I was showing you good comparison
> since I am copying from multiple windows of debug output.
>
> I don't understand how the local time comes into play when converting
> a constant number of seconds.  The resulting date should be a
> constant as well.
>
> What am I missing?

The beauty of "the seconds" is that the value you get is in GMT, 
regardless of where the machine is at the moment that value of 
obtained.  It does the offset according to the locale settings on the 
local machine.


"The seconds" and "the internet date" are the only two forms that take 
local time zone settings into account.


The benefit with this approach is that either can be used in 
applications where usage may span time zones but you need to maintain 
time stamps that will work across any time zones.



For example, suppose I'm in Los Angeles and I share a server app with 
one user in New York, another in Brisbane, and another in Edinburgh.


GMT offsets for each are:

Edinburgh: 0
New York: -4h
Los Angeles: -7h
Brisbane: +10h (they're across the International Dateline)

The "internet date" format reflects this explicitly, noting the GMT 
offset at the end of the string it returns:


  Fri, 17 Mar 2017 09:09:03 -0700

But "the seconds" of course is just an integer, so while the GMT 
offset has also been accounted for it's less evident.


If all four of us get "the seconds" at the same moment, the value we 
get will be the same, in GMT time.


But since only one of us is actually in the GMT time zone, how does it 
know?  That's where the local system settings come into play.


When *obtaining* either "the seconds" or "the internet date", local 
time zone is used to create a value that can be understood globally.


When *converting* either "the seconds" or "the internet date", LC uses 
time conversion routines dependent on the system locale settings of 
the machine where the conversion is taking place.


With "the internet date" the time zone is explicitly included, so it 
adjusts from that GMT offset to bring it into alignment with the GMT 
offset in the local OS.


With "the seconds", the value is already adjusted to be GMT, so 
conversion adjusts it again for the local settings to deliver an 
accurate representation of that moment in local time.



In the example above, all four users would get the same value from 
querying "the seconds" at the same moment, no matter where they are in 
the world.


And when my software needs to display the date and/or time in 
human-readable form, the "convert" command takes local settings into 
account to deliver an accurate representation that makes sense in 
local time.


So if I modify a record right now, in my system it'll show March 17 at 
9:18 AM.  But when my Brisbane use sees the modification date that 
I've stored using "the seconds", he'll see March 18 at 2:18 AM, which 
is the same global moment.



In short:

The key to getting accurate reflections of time is to store either 
"the seconds" or "the internet date" on the server (or really, 
anywhere timestamps may be shared across time zones), and then do any 
conversions needed for human readability locally.


If you do a conversion from either of those two formats on the server 
to any other format, the result will be correct for the server's 
locale, but unless you're nearby probably not correct for you.



Quick Exercise:

It took me a while (and some experimentation) to appreciate that "the 
seconds" reflects GMT just as "the internet date" does, something I 
learned from Sarah Reichelt back in the day.


One quick way to verify this is to check while changing your local 
machine's Date and Time settings:


Set to Los Angeles: 1489768020
5 seconds later,
Set to Montreal:1489768025
10 seconds after that,
Set to London:  1489768035

Except for the few seconds it took me to click on my Locale map in my 
Control Panel, the numbers are effectively all the same.


Once I became confident with that, I've used it for everything on 
servers ever since (except logging - I like the built-in readability 
of "internet date" in logs).





___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, 

Re: Problem with converting time

2017-03-17 Thread Michael Doub via use-livecode

Richard here is another example:

time = 1489752000

mac: dateitems = 2017,3,17,8,0,0,6

server: dateitems = 2017,3,17,12,0,0,6

I just wanted to double check that I was showing you good comparison 
since I am copying from multiple windows of debug output.


-= Mike

On 3/17/17 8:46 AM, Michael Doub wrote:


time = 1489755600

Mac:  dateitems = 2017,3,17,9,0,0,6
server:   dateitems = 2017,3,17,12,0,0,6

Code:   get time
convertit to dateitems

I don't understand how the local time comes into play when converting 
a constant number of seconds.  The resulting date should be a constant 
as well.


What am I missing?

-= Mike


On 3/16/17 4:05 PM, Richard Gaskin via use-livecode wrote:

Michael Doub wrote:

> I am getting different answers based on environment when trying to
> convert EPOC seconds to dateitems or internet date.   On my mac I get
> the expected result but on a HostM server I get something totally
> different.

How different?

> Does any one have a conversion function that does not use the
> livecode's convert function that they would be willing to share?

The seconds are usually a very good choice for their compactness and 
ease of calculation, and more so because the value we get is in GMT 
based on the offset from host OS.


What this should mean is that you can convert values obtained from 
"the seconds" and get a good date/time regardless of which time zone 
you're in.


So seconds are usually ideal (along with "internet date") for network 
applications such as the one you're working on.


But for the conversion to take your local system into account, you'll 
need to do the conversion locally.


If you're doing the conversion on the server, the date/time will 
reflect the time zone settings in the server OS.






___
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: Problem with converting time

2017-03-17 Thread Michael Doub via use-livecode

time = 1489755600

Mac:  dateitems = 2017,3,17,9,0,0,6
server:   dateitems = 2017,3,17,12,0,0,6

Code:   get time
convertit to dateitems

I don't understand how the local time comes into play when converting a 
constant number of seconds.  The resulting date should be a constant as 
well.


What am I missing?

-= Mike


On 3/16/17 4:05 PM, Richard Gaskin via use-livecode wrote:

Michael Doub wrote:

> I am getting different answers based on environment when trying to
> convert EPOC seconds to dateitems or internet date.   On my mac I get
> the expected result but on a HostM server I get something totally
> different.

How different?

> Does any one have a conversion function that does not use the
> livecode's convert function that they would be willing to share?

The seconds are usually a very good choice for their compactness and 
ease of calculation, and more so because the value we get is in GMT 
based on the offset from host OS.


What this should mean is that you can convert values obtained from 
"the seconds" and get a good date/time regardless of which time zone 
you're in.


So seconds are usually ideal (along with "internet date") for network 
applications such as the one you're working on.


But for the conversion to take your local system into account, you'll 
need to do the conversion locally.


If you're doing the conversion on the server, the date/time will 
reflect the time zone settings in the server OS.




___
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


Problem with converting time

2017-03-16 Thread Michael Doub via use-livecode
I am getting different answers based on environment when trying to 
convert EPOC seconds to dateitems or internet date.   On my mac I get 
the expected result but on a HostM server I get something totally different.


Does any one have a conversion function that does not use the livecode's 
convert function that they would be willing to share?


Regards,

Mike



___
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