Yup. I do that a lot. Where I have an issue is dividing up a block of time into
multiple segments, where the minutes may not divide evenly between all the
segments. So I produced this:
function timeTable pStartTime, pStartLunch, pEndLunch, pEndTime, pItemCount
set the itemDelimiter to ":"
On the topic of keeping LC stupid-simple, here's of one of those ways that
LC makes ugly math fun:
#
put the short date into theDate
convert theDate to dateItems
put 0 into item 3 of theDate
convert theDate to short date
put theDate
#
On Wed, Apr 26, 2017 at 12:45 PM, Mike Kerner
wrote:
> I th
I think 3 is something we should scratch off the list, since we have more
important fish for you to fry.
On Wed, Apr 26, 2017 at 11:42 AM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:
> On 2017-04-26 16:00, prothero--- via use-livecode wrote:
>
>> Ok, I'll shut up abou
Whenever we decide we're done with this, someone needs to send me the code
and I'll throw it up on github, since I'd like to have a central repo for
helpful code, especially since with git and levure we have a pretty easy
way of adding those modules to our projects.
On Wed, Apr 26, 2017 at 11:14 A
On 2017-04-26 16:00, prothero--- via use-livecode wrote:
Ok, I'll shut up about this for now. Sorry to unfocus the thread.
To be fair, I managed to conflate three issues:
1) Improving numberFormat
2) How we could get arbitrary precision integers whilst retaining
doubles for reals
3)
Roland Huettmann wrote:
> It is a very nice approach that Curry already realized: and it is
> available:
> http://curryk.com/ck-num-format.pngn better
That does look very nice indeed. If that formatting is factored in a
way that would lend itself to a generalized behavior script for fields,
a
Folks,
This thread addresses two issues with numbers. The main issue being discussed
is the display of numbers. This is very important and the main point of
diddling with numberformat. I like the idea of making a behavior we can all use
to format numbers in a variety of ways.
The other one is t
Curry,
This is great and best of all is the table of examples. This, in the
dictionary, would have made my thrashing around with format, to get what In
wanted a lot easier.
Bill
William Prothero
http://es.earthednet.org
> On Apr 26, 2017, at 2:31 AM, Curry Kenworthy via use-livecode
> wrote:
Thank you, Richard, Curry, Mark...
It is a very nice approach that Curry already realized: and it is available:
http://curryk.com/ck-num-format.pngn better
But what I do not yet understand is how to make a joint effort with
hundreds of developers ))) available to ALL of us in practical terms --
s
Roland:
I vote for the LC-NATIVE "Excel style" number format
(enhanced numberFormat in LC, not a new one, no
depreciation, but just different ways to achieve the same)
Excel number format is powerful and popular, that's for sure.
Richard:
The Excel spec is a guide, but not an implementatio
Roland Huettmann wrote:
> AGAIN -- having read all - I vote for the LC-NATIVE "Excel style"
> number format (enhanced numberFormat in LC, not a new one, no
> depreciation, but just different ways to achieve the same) and the
> ability of fields (text controls) to express at least the same
> styl
With reference to the past suggestions, and the last one from Richard
Gaskin:
"Even if the core team were in a position to drop other priorities to add
formatting to fields, they couldn't do it any faster than a scripter who
has the advantage of doing it in LiveCode itself."
I have been thinking
Mark:
> If we made this distinction, then it would be viable to
> make it so that numberFormat *only* affects reals:
> put 1 + 0 into tInteger
> put 1. + 0 into tReal
> set the numberFormat to "0.00"
> put tInteger , tReal
> => "1,1.00"
I would expect big problems doing that generally! But it
Curry Kenworthy wrote:
> Some people are trend-attuned, bandwagonish and when something
> like JavaScript becomes extremely popular, they feel the need
> to compromise or follow it beyond the extent which is already
> dictated by technology. It's possible that nothing will make
> those people fee
Roger:
> I wouldn't even be here if not for my introduction to
> English-like syntax via HyperCard 25+ years ago. My
> apparently "not very useful work" over the past 25 years
> ... has kept me employed, my family clothed and fed,
> a roof over our heads, and all my bills paid.
Well said! I'd
Sorry Roger. I didn’t mean to open a debate on whether English-like syntax is
good or bad. Just to make a point about doing coding gymnastics to follow a
viewpoint, that actually makes things more complex. I think that all of us who
start with LiveCode get hooked, then learn more by discussing a
I wouldn't even be here if not for my introduction to English-like syntax
via HyperCard 25+ years ago. My apparently "not very useful work" over the
past 25 years while benefiting from that very same "less complex" syntax
has kept me employed, my family clothed and fed, a roof over our heads, and
Way to steal my post and make it eloquent, Bill :-P
On Tue, Apr 25, 2017 at 12:57 PM, prothero--- via use-livecode <
use-livecode@lists.runrev.com> wrote:
> My point was to set variable types when they need to be set explicitly.
> Those who don't want to set a type can just use forget about it. O
My point was to set variable types when they need to be set explicitly. Those
who don't want to set a type can just use forget about it. Once you get into
more scientific, numeric type applications, the precision and type of variables
can get crucial. To me, the suggested changes to numberformat
On 2017-04-25 12:48, Lagi Pittas via use-livecode wrote:
Hi
I don't know why you want to adapt/enhance the number format as that
could
break already working code that uses the nuances of numberformat
already.
Although it may have not been 100% clear in my previous post, as
numberFormat
in L
Variable Typing! EEEK!!!
Bob S
> On Apr 25, 2017, at 08:33 , prothero--- via use-livecode
> wrote:
>
> Folks,
> What I see in this discussion is extreme efforts to do something that is
> straightforward and transparent in other languages (I can see these suggested
> solutions as creating u
On 04/25/2017 08:33 AM, prothero--- via use-livecode wrote:
Folks,
What I see in this discussion is extreme efforts to do something that is
straightforward and transparent in other languages (I can see these suggested
solutions as creating unnecessary complexity).That is to simply declare some
Folks,
What I see in this discussion is extreme efforts to do something that is
straightforward and transparent in other languages (I can see these suggested
solutions as creating unnecessary complexity).That is to simply declare some
variable types.
E.g.
variable ix=integer double
variable yzz
+1
And if you must introduce a arguably newer/better term, please make its
syntax more English-like and less code-like. This _is_ LiveCode. Cryptic
is for those other languages. /2_cents
~Roger
On Tue, Apr 25, 2017 at 10:11 AM, Rick Harrison via use-livecode <
use-livecode@lists.runrev.com>
Hi Lagi,
I can’t agree more. Never break anyone’s code if at all possible.
Create a new numberformat like NumberFormatXL or something
similar. Leave the old working stuff alone.
Just my 2 cents for the day!
Rick
> On Apr 25, 2017, at 6:48 AM, Lagi Pittas via use-livecode
> wrote:
>
> Hi
>
Would it make sense to say that if a container is strongly typed (i.e.
declared as type x) it is type x and if it is not then it is not? Why
can't you have it both ways?
On Tue, Apr 25, 2017 at 6:48 AM, Lagi Pittas via use-livecode <
use-livecode@lists.runrev.com> wrote:
> Hi
>
> I don't know wh
Hi
I don't know why you want to adapt/enhance the number format as that could
break already working code that uses the nuances of numberformat already.
Why not add an instruction NumberFormatXL and create the an Excel version
like Curry says. You won't have to jump through hoops to make sure it
d
On 2017-04-25 09:01, Curry Kenworthy via use-livecode wrote:
To handle arrays better without requiring more lines of code, how
about making numberFormat itself an array with at least two parts?
Similar to the way the clipboardData has parts.
Using it without a key works exactly like before, by s
We've talked about this topic so much that now it almost seems a waste
to let it go without trying to make some progress. :)
Mark:
> I'd disagree that anything involving the use of arrays could
> be considered a 'rare case' or an 'outlier case'
To handle arrays better without requiring more
29 matches
Mail list logo
