sed equivalent for Livecode all

[triantaresX]

its incredible compared to other languages. I've not yet hit any significant limitations/showstoppers

I agree it has some very nice strong points ----- like the floating point arithmetic for one: It felt a bit unnerving using "get text from field " to import a number but Livecode has that covered quite well.

The big pro is the customizing allowed for GUI creation, most other languages come with fairly drab standard widgets or require extra C coding knowledge to alter widgets or windows.
Qtdesigner has that covered quite well too but is a bit of overkill and (naturally) requires Qt to be installed.

[golife]

You find very good articles about number formats and date formats on Wikipedia:

https://en.wikipedia.org/wiki/Decimal_separator
https://en.wikipedia.org/wiki/Calendar_date#Date_format

In many countries (including Germany) the decimal separator is a comma, the thousands separator is a point. But in Switzerland the decimal separator is a point, the thousands separator is a high comma (apostrophe). The formats for dates vary as everyone knows.

In LiveCode, when working for international clients, you need to think about how to handle such different format since they are what I call "presentation layer". The storage layer in LiveCode could be a custom property, an array, a SQLite database or a text file. So, presenting dates, times and decimal numbers is different from the storage.

Instead of putting something into a field, you might set a custom property:

Code: Select all

--- Example:
set the uValue of field "myThousands" to 1000000"
put convertNumber(the uValue of field "myThousands") into field "myThousands" 

The resulting formatted number may look like "10,000,000.00" or like "10.000.000,00" or like "10 000 000.00" or like "10'000'000.00" depending on the lokale value the user sets or the system default settings.

So, on closeField or changeText or similar messages, formatted data will also be changed on the storage level.

To automate this, you can use setProp and getProp handlers that will automatically convert a changed or entered value in both directions and present the desired format according to chosen locale.

Of course, there are also disadvantages using such method. Ideally, the presentation layer is so closely and automatically bound to the stored value that I would even favor a special field property to define the presentation and the storage and the field will take care of the binding itself (see this in Filemaker). The presented formatted value may not even have to be stored at all and is always an unstored calculated value. But I would not know how to do this in LiveCode as fields always store data put in. Or not?

Problems appear when importing other sets of formatted numbers since it is not always possible to know in advance which format such imported numbers (or dates) have. In some countries you cannot even be sure that the fractional part of the number is not also formatted leaving number formats to become a wild guess.

In my opinion, it would be DEVELOPER FRIENDLY if such functions for the formatting of dates and times as well as decimal numbers would be engine functions covering all defined international locales. In Excel and all other kinds of applications we do not need to write functions (usually), but just define the type to be used. It is just an overhead for us now.

I very much hope to once see the international date format supported by the engine: YYYY-MM-DD HH:MM:SS. It should be simple to use and convert to date items, other date formats, etc. It is used in databases.

[bogs]

In my opinion, it would be DEVELOPER FRIENDLY if such functions for the formatting of dates and times as well as decimal numbers would be engine functions covering all defined international locales. In Excel and all other kinds of applications we do not need to write functions (usually), but just define the type to be used. It is just an overhead for us now.

I very much hope to once see the international date format supported by the engine: YYYY-MM-DD HH:MM:SS. It should be simple to use and convert to date items, other date formats, etc. It is used in databases.

Erm, have you come across dateFormat in the dictionary ?

Use the dateFormat function to obtain the general format of the date for further processing.

Value:
The dateFormat function returns a string.

Comments:
The dateFormat function returns a string containing one or more formatting incantations, each of which describes a part of the requested date format. The possible incantations are as follows:

Code: Select all

%a - Abbreviated weekday name:  the abbreviated day of the week, as reported by the weekdayNames function

%A - Full weekday name:  the full day of the week, as reported by the weekdayNames function

%b - Abbreviated month name:  the abbreviated month name, as reported by the monthNames function

%B - Full month name:  the full month name, as reported by the monthNames function

%d - Day of the month:  the day of the month as a number

%m - Month number:  the number of the month

%y - Two-digit year:  the year as a two-digit number

%Y - Four-digit year:  This incantation indicates the year as a four-digit number (including the century)

%w - Day of the week:  A number between 1 and 7

Note: The dateFormat differs from other date/time functionality in that the default is to return information relative to the system locale. i.e. the dateFormat is equivalent to the system dateFormat

[SparkOut]

A still better engine enhancement would be cross-platform support for dates pre 1970.

[golife]

Well, fair enough and good points. Actually, I forgot about the dateformat function. LiveCode is rich in functions but to always remember them is more difficult, especially when not exactly knowing what to search for.

But nevertheless, this dateformata function that returns values, and yes, it is relative to the system settings. What I cannot do as a user is defining the format myself (as easily). So, that would require overhead.

On a shared device (computer, smart phone, ...), I should not assume that the default values of the device are the actual values for presentation and entries preferred by the user.

In my opinion, the user should be allowed to define user preferences while system preferences are just default settings.

When I know the user (user login) and the preferences then I can adjust the system according to such preferences.

I need to know which preferences guide the presentation of dates and numbers plus in case of handling different external sets of data (import from databases, spreadsheets, other users) how to convert between them, how to import, how to eventually automatically detect their formatting, how to export in the same or other formats. And I may have my own users that prefer different formats individually.

If such scenario is the use case then I need to be on the safe side. My global application shall store correct values and present user-defined formatted values. Switching the user settings (not the system settings) should reformat all values.

If values are mixed (e.g. American date formats mixed with European ones) then problems will appear. So, I also need to validate user input / copy and paste, and import/export as well as my own storage formats when using external servers or connecting users with each-other in different continents.

And also, my local system date only works and is recognized as a date when the useSystemDate is set to true. Doing this will make the standard LC date format MM/DD/YYYY become invalid, and vice versa, unless the system date is in the standard date format.

I also did not find support for thousands separators in the numberFormat setting command depending on the system locale or overriding it with user preferences. Everyone uses his/her own function for this.

Maybe I am thinking too much about edge cases, but as an international user with international clients, this is far from trivial and requires careful thinking. Too many times I faced problems handling different formats of numbers and dates at the same time in the same application, and errors jump up.

[dunbarx]

@golife

Code: Select all

What I cannot do as a user is defining the format myself (as easily). So, that would require overhead.

Along with the "dateFormat" I assume you know about the "dateItems". And a little overhead is not a bad thing if it results in perfect solutions to your issues.

@Sparkout

A still better engine enhancement would be cross-platform support for dates pre 1970.

You recall this thread?
viewtopic.php?f=9&t=26619&p=138530&hili ... ng#p138530

To be fair, I do not know how "cross-platform" this is.

Craig

[bogs]

@golife

Code: Select all

What I cannot do as a user is defining the format myself (as easily). So, that would require overhead.

Along with the "dateFormat" I assume you know about the "dateItems". And a little overhead is not a bad thing if it results in perfect solutions to your issues.

Craig hit it out of the park, I think. Your writing the program, you should set it up so that the end user has whatever preferences they want, you certainly have the tools to do so within the language as it sits.

That is aside from ~

LiveCode is rich in functions but to always remember them is more difficult, especially when not exactly knowing what to search for.

As to the first part, you already have so many functions built in that it is hard to remember them, but you want to add more?
As to the 2nd part, one strategy to finding what is relevant is to start your search with the most relevant part of what you need to do. In this case, simply typing in 'date' would bring you quite a few bits worth of reading.

[dunbarx]

the most relevant part of what you need to do. In this case, simply typing in 'date' would bring you quite a few bits worth of reading.

Bogs knows.

This addresses a common complaint, or at least gripe. I think there are well over 2500 native words in LC. You need 10,000 words to read the New York Times. I think that the phrase above, reworded nicely into a general "RULE # 1", ought to be printed in bold right at the beginning of the User Guide.

Craig

[golife]

Well, again thanks to all.

I am not writing as if I do not know what to do in LiveCode. I do search the library when I need something and I know usually where to find, even elsewhere. For a long time, I am using my own functions for conversions or copy those that are free to use from any library.

Well, I am mainly writing putting myself into the shoes of someone who is new to LiveCode and may not understand all the terms, and I take these postings as a kind of focal point for everyone to share and think about.

If I were a newby, I immediately would ask about what "LCS" is, or "PB", or some other acronyms used. To deal with dates and times and number formats is no issue for me in reality, but it may be for others.

Agreed, I may be wrong arguing in a way about things which I myself already know.

[dunbarx]

goLife.

Your comments are welcome. Keep them coming.

Craig

[bogs]

Agreed, I may be wrong arguing in a way about things which I myself already know.

I sincerely hope you don't mistake my comments for hostility, or as my way of demeaning you, as that was not my intention. I was merely trying to point out something I found ironic in what you had written.

For a long time, I am using my own functions for conversions or copy those that are free to use from any library.

I often find myself doing the same, just in case you wondered. Usually I find myself doing this when I'm thinking through a problem, then realize the problem itself broken down almost had to have been thought through before and probably by people much smarter than I.

Then I look it up, sure enough, I need not have bothered heh, but on the plus side, it is good extra practice.

[golife]

No, no, please, I am not bothered, there is no problem at all, I like your and other people's posts. This is simply a discussion and I am trying to make myself understood as everyone else is doing. Just, generally said, sometimes I fall into a trap of communicating not clearly enough and then wondering about the reaction. I tend to open rhetorical questions and being critical just for the sake of being critical. This way I learn myself (all the time) and I hope that others take a benefit as well, but communication can always be improved and thought about it before rather than after.

[SparkOut]

@Sparkout

A still better engine enhancement would be cross-platform support for dates pre 1970.

You recall this thread?
viewtopic.php?f=9&t=26619&p=138530&hili ... ng#p138530

To be fair, I do not know how "cross-platform" this is.

Craig

Not cross-platform as far as Windows goes anyway.
Values representing dates pre-1970 are not recognised as dates on Windows. Any value provided to the "convert" function is left unchanged.

Code: Select all

   set the useSystemDate to true
   put "2/1/1970" into tDate  --because UK
   convert tDate to dateItems
   put tDate --> 1970,1,2,0,0,0,6
   subtract 1 from item 3 of tDate
   put tDate --> 1970,1,1,0,0,0,6
   convert tDate to short date
   put tDate --> 01/01/1970
   put tDate is a date --> true
   convert tDate to dateItems
   put tDate --> 1970,1,1,0,0,0,5
   subtract 1 from item 3 of tDate
   put tDate --> 1970,1,0,0,0,0,5
   convert tDate to short date
   put tDate --> 1970,1,0,0,0,0,5
   put tDate is a date --> false