Нужно создать поле хитрое ввода в таблице.

← →
Vovochka © (2002-09-16 11:00) [0]

Нужно ввести число в особом формате. Что-то типа "12.34.5". Для вывода я на
field зделал onGetText, но поле чиловое и OnSetText уже неподходит - недаёт
ставить вторую точку. Как быть? Просто сейчас сделано ввод и ввывод в одном
гриде и нехочется для изменения писать еще одну форму.

← →
Sergey13 © (2002-09-16 11:22) [1]

И чему равно число "12.34.5" в нормальном формате? ИМХО, это строка(текст) и хранить ее надо как текст, а уж интерпретировать - это как заблагорассудится.

← →
oss © (2002-09-16 11:51) [2]

напиши яснее как ты потом работаешь с этим числом

← →
Anatoly Podgoretsky © (2002-09-16 11:58) [3]

Новая отрасль математики, superfloat numbers

← →
Vovochka © (2002-09-16 12:21) [4]

Нужно хранить UTC и широту и долготу.

UTC это отлие часового пояса от гринвича
(value<11.59)and(value>- 11.59) - По понятным причинам TIME неподходит. Хронится как одно поля типа Integer.
fix - cделал как Numeric(4,2)

Широта та-же жопа - вид с боку. Градусы(len 2).Минуты(len 2).Доли минут(len 1) - exp "с 45.30.8" - так она должна видется.
Хронится как одно поля типа Integer.
С градусами алкоголично. Хронится как одно поля типа Integer.

← →
ЮЮ © (2002-09-17 03:36) [5]

Cм. DisplayFormat и EditFormat у TIntegerField

← →
Sergey13 © (2002-09-17 09:20) [6]

2Vovochka © (16.09.02 12:21)
>Градусы(len 2).Минуты(len 2).Доли минут(len 1) - exp "с >45.30.8" - так она должна видется.
>Хронится как одно поля типа Integer.
А почему именно одно поле. Может проще 3 поля. А при выводе соедини в одно - хоть в запросе, хоть в калк.поле - и храниться будет правильно и "видется" будет как надо.

← →
ЮЮ © (2002-09-17 09:37) [7]

>Sergey13 © (17.09.02 09:20)
А сам ты поля типа DateTime используешь? Или в 7-ми отдельных полях хранишь? И соединяешь в одно в запросах?

>Хронится как одно поля типа Integer.
А может поступить как в случае с TDateTime? Хранить радианы в float, а отображать, как удобно пользователю

← →
Sergey13 © (2002-09-17 10:08) [8]

2ЮЮ © (17.09.02 09:37)
А ты считаешь что "Градусы(len 2).Минуты(len 2).Доли минут(len 1)" - это типа DateTime? Ню-Ню.

← →
ЮЮ © (2002-09-17 11:32) [9]

А ты считаешь, что День(len2)Месяц(len2)Год(len2)Час(Len2)Мин(len2)Ceк(len2)mc(len3) - это семь полей в таблице? И тебе Ню-Ню :-)

← →
Johnmen © (2002-09-17 11:36) [10]

Если вообразить, что Градусы - Часы, то очень даже реально хранить значение величины угла в поле TIMESTAMP или TIME (в зависимости от диалекта)

Ну и попробуйте поработать с "89.59.16" как со временем.
Желаю удачи.

89.59.16 -> в радианы -> float
TDateTime === float
Именно это имел в виду, когда говорил "поступить как в случае с TDateTime"

>Sergey13 © (17.09.02 11:56)
>Ну и попробуйте поработать с "89.59.16" как со временем.
>Желаю удачи.

Пардон, а где это такое предлагалось ? Автор именно и спрашивает, как лучше ему хранить значение угла...

← →
REA (2002-09-17 12:15) [14]

Можно попробовать сделать вычисляемое поле и работать через него - не уверен что получится. А прямо в строке почему бы не хранить? Неудобно?

2ЮЮ © & Johnmen ©
Да не спорю я, что можно. Я спорю за то, что нужно ли? Аналогия с TDateTime(ЮЮ, не надо меня обвинять в идиотизме, TDateTime я храню как TDateTime, а не в 7 полях) не удачна потому, что этот тип понимают обе стороны(база и прога), а в случае с градусами нужно ПОСТОЯННО переводить из одного в другое САМОСТОЯТЕЛЬНО ( кстати почему именно в радианы, достаточно просто привести к нормальному формату типа 15.30.00 = 15.5, все равно это надо делать для перевода в радианы). При этом все равно придется разбивать экранный вывод на 3 целых числа - не радианы же юзеру вводить/редактировать. Ну и на фига козе баян, зачем постоянно переводить если автор вопроса хочет работать именно со своей формой этого "числа"? Единственный плюс от этого запись меньше на 16 бит (3 smallint- 1 float).
В общем я остаюсь при своем мнении. Хранить "80.20.30" лучше или строкой или (в случае активной обработки этих данных) в 3 полях.

Нужно создать поле хитрое ввода в таблице. Найти похожие ветки