Hi Kohei, *,
Inspired by - guess what (*) - I pick up this thread again.
Kohei Yoshida wrote (10-12-2007 23:12)
On Mon, 2007-12-10 at 22:04 +0100, Cor Nouws wrote:
Also for me, a input box for dates would be a big mistake. The current
system allows fast working.
Fair enough. Scratch the
Hi Cor,
On Tuesday, 2007-12-11 09:05:10 +0100, Cor Nouws wrote:
How about problems when entering by key board?
If those are rare, maybe an option to turn of auto-date by
importing/pasting is enough?
There are enough complaints that when entering 1.2 in a locale where the
dot is not the
Eike Rathke wrote (18-12-2007 16:09)
Hi Cor,
On Tuesday, 2007-12-11 09:05:10 +0100, Cor Nouws wrote:
How about problems when entering by key board?
If those are rare, maybe an option to turn of auto-date by
importing/pasting is enough?
There are enough complaints that when entering 1.2 in
Hi all,
Issue 77973 further discusses the Date-issue (see
http://www.openoffice.org/issues/show_bug.cgi?id=77973). That issue is
still unconfirmed, but in the meantime I think it is really justified to
confirm it. Therefore, someone with the appropriate rights should
change the issue to
Hi Kohei,
Kohei Yoshida wrote (10-12-2007 23:12)
Fair enough. Scratch the input box idea then. That was just an idea
anyway (a bad one).
Never mind. It would be annoying if you only had good ideas ;-)
With typing in dates, once you know how it works and /or set your cell
formatting /
Hi all,
Cor Nouws wrote:
Hi *,
...
The current system allows fast working.
With typing in dates, once you know how it works and /or set your cell
formatting / styles correctly, it is OK.
No, it is not OK. If you work in a multi-user, multi-locales
environment, you will feel the heat
Hi Kohei,
On Friday, 2007-12-07 10:09:50 -0500, Kohei Yoshida wrote:
The rough idea I've just come up with is to do what web applications do:
provide a date input box. This way Calc also knows that the user is
about to enter a date, and try not to even parse an input as a date if
the date
Hi Leonard,
On Monday, 2007-12-10 00:19:55 +0200, Leonard Mada wrote:
Aloow the user to specify, what should be interpreted as a date (and how).
E.g., IF the user specifies that dates are only strings of the form:
dd.mm.yy or dd.mm., then only such strings would be converted to dates
Hi Eike,
On Mon, 2007-12-10 at 13:44 +0100, Eike Rathke wrote:
Hi Kohei,
On Friday, 2007-12-07 10:09:50 -0500, Kohei Yoshida wrote:
The rough idea I've just come up with is to do what web applications do:
provide a date input box. This way Calc also knows that the user is
about to
On Mon, 2007-12-10 at 13:21 -0500, Kohei Yoshida wrote:
You just described how complex it is to parse a date input, and that's
exactly my point. :-) And the point I was trying to make with my date
input box idea was to give the user a way to bypass that complex
parsing
process when it's
Hi *,
Kohei Yoshida wrote (10-12-2007 19:39)
On Mon, 2007-12-10 at 13:21 -0500, Kohei Yoshida wrote:
You just described how complex it is to parse a date input, and that's
exactly my point. :-) And the point I was trying to make with my date
input box idea was to give the user a way to bypass
Hi Cor,
On Mon, 2007-12-10 at 22:04 +0100, Cor Nouws wrote:
Also for me, a input box for dates would be a big mistake. The current
system allows fast working.
Fair enough. Scratch the input box idea then. That was just an idea
anyway (a bad one).
With typing in dates, once you know how
Kohei Yoshida a écrit :
Hi Cor,
On Mon, 2007-12-10 at 22:04 +0100, Cor Nouws wrote:
Also for me, a input box for dates would be a big mistake. The current
system allows fast working.
Fair enough. Scratch the input box idea then. That was just an idea
anyway (a bad one).
With
Hi all,
Kohei Yoshida wrote:
...
* determining whether the input is a date without any other clues has
been (almost) proven to be error-prone, can never reach an acceptable
level, and leads to the wrath of users, largely due to localized date
formats.
So, what can we do?
The rough idea I've
14 matches
Mail list logo
