Вверх ↑
Этот топик читают: Гость
Ответов: 9906
Рейтинг: 351
#31: 2007-03-14 07:07:44 ЛС | профиль | цитата
Dilma писал(а):
вопрос остался без ответа:

На вопрос дан ответ.
Мы не имем право использовать свою уверенность, или не уверенность, при принятии решений, связанных с потерей данных.

Гипотетический пользователь задает вопрос из серии
Я сортирую файлы по времени создания, и точно знаю, что файл A имеет время создания на пол-секуды ранее, чем файл B
А HiAsm это не отличает.
Хотя все нормальные программы - запросто.
И зачем вы делали формат real для времени, если дробную часть потеряли с самого начала
.....

Нечего ему будет ответить, не потеряв уважения к себе.
Не обсуждать же вопросы "нормальности".

Dilma писал(а):
файлы большие 4гб это не бред - образ двустороннего DVD диска

Вопрос не в том, как мы к этому относимся, а в том что мы не имем право использовать свое отношение к этому.
И приведен как пример отрицательного своего отношения к этому, но игнорировании этого отношения при кодировании.

Относиться можно как угодно, но есть объективный признак: потеря информации.
карма: 9

0
Ответов: 2125
Рейтинг: 159
#32: 2007-03-14 11:11:51 ЛС | профиль | цитата
Dilma писал(а):
А есть уверенность, что ОС Windows вернет скажем время создания файла с такой точностью?

А что дата есть только у файла? Можно, например, протоколировать события, происходящие очень часто, тот-же TimeCounter позволяет измерять время в миллисекундах, что теперь - всегда время в миллисекундах считать?
карма: 1

0
Ответов: 105
Рейтинг: 2
#33: 2007-03-14 11:51:52 ЛС | профиль | цитата
Меня как пользователя, формат real вполне устраивает. Я так понимаю, точность только до секунд? Пока еще не возникло задач требующей большей точности. А что увеличение точности представляет собой какие-то сложности?
карма: 0

0
Ответов: 16884
Рейтинг: 1239
#34: 2007-03-14 11:58:56 ЛС | профиль | цитата
GRIMAN, наоборот
карма: 25
Немного терпения! Дежурный экстрасенс скоро свяжется с Вами!
0
Ответов: 3655
Рейтинг: 69
#35: 2007-03-14 20:05:46 ЛС | профиль | цитата
А кто мешает сделать два компонента
1)Дата
1)Дата повышенной точности.
Мне кажется это нормально есть же каклькулятор и калькулятор повышенной точности.
И ни кто не возмущяется.
Кому что надо тем и пользуется.
карма: 0

0
Администрация
Ответов: 15295
Рейтинг: 1519
#36: 2007-03-14 21:02:59 ЛС | профиль | цитата
Вячеслав, насколько я понимаю проблему, поднятую в этом топике данное предложение не решит. Сделать два компонента(или просто две точки) конечно же можно. Но не будите же вы дублировать все компоненты, которые работают со временем? Просто видимо сказывается разница во взглядах. HiAsm это средство написания конечных программ большей частью что называется для себя. Во всяком случае таковой была задумка. Т.е. наиболее приоритетная задача при разработке компонентной базы это простота, доступность и наглядность. Есть как мы видим и иные мнения. Вот и хотелось бы выяснить, что думают остальные
карма: 27
0
Ответов: 2125
Рейтинг: 159
#37: 2007-03-14 21:15:54 ЛС | профиль | цитата
Вобщем, в каком виде выдавать дату для математических действий над ней - всё равно. Если исходить из того, что имеется в API, то хранить дату можно в том виде, в каком она передаётся через API функции, т.е.
typedef struct _SYSTEMTIME {  // st 
    WORD wYear; 
WORD wMonth;
WORD wDayOfWeek;
WORD wDay;
WORD wHour;
WORD wMinute;
WORD wSecond;
WORD wMilliseconds;
} SYSTEMTIME;
Тут вам есть и миллисекунды, и день недели. Т.е. компонент "Дата" лучше всего сделать с храненем даты в этом формате. Есть функции для получения и локального времени, и UTC (GMT).

Выдавать дату в виде числа, я считаю, лучше всего как real. SYSTEMTIME c помощью того же API переводится к FILETIME, которое по сути есть 64-битное число. Где еденица это 100 наносекунд (непонятно правда, нафига у даты файла такая точность!). Начало отсчёта 1 января 1601 года! Причём как в одну сторону, так и в другую.
карма: 1

0
Ответов: 3655
Рейтинг: 69
#38: 2007-03-14 21:49:47 ЛС | профиль | цитата
Ну вот вроде и решение проблемы
карма: 0

0
Ответов: 9906
Рейтинг: 351
#39: 2007-03-15 06:34:50 ЛС | профиль | цитата
tsdima писал(а):
Если исходить из того, что имеется в API, то хранить дату можно в том виде, в каком она передаётся через API функции

Про хранить - это личное дело элемента, видимо
А вот выдавать - коллективное

Припоминаю страстные призывы апологета элемента DataPicker - сделайте внешнюю предустановку даты в элементе (oldTV его фамилия).
Так дело только за этим было, по большому счету...
У колышка есть этот метод, который на вход просит TDateTime (Real - по нашему)
Вывести входную точку - метод с одной строкой, а вот где он возьмет этот Real...
карма: 9

0
Разработчик
Ответов: 26149
Рейтинг: 2127
#40: 2007-03-15 09:53:33 ЛС | профиль | цитата
Galkov писал(а):
Припоминаю страстные призывы апологета элемента DataPicker - сделайте внешнюю предустановку даты в элементе
Я проверил это и у себя реализовал. Прекрасно это дело работает и дата предустанавливается в контроле, не влияя на системную.
карма: 22

0
Ответов: 689
Рейтинг: 20
#41: 2007-03-16 09:13:42 ЛС | профиль | цитата
насчет апологетства DataPicker: я вообще считаю, что в этом компоненте само собой разумеется должна быть предустановка даты (заодно было бы неплохо и времени). Я сюда прихожу визуально проектировать и писать быстро программки. Я не программирую в делфях, не понимаю вообще этот язык. Я чистый хиасмиcт. И если боги могут мне помочь, помогите. Проект заморожен из-за этого.

nesco, пожалуйста, выкладывай уже таки компонент, я тебя прошу
карма: 0

0
Ответов: 9906
Рейтинг: 351
#42: 2007-03-16 10:02:29 ЛС | профиль | цитата
Добавляешь левую точку doTime

........
     procedure _work_doTime(var _Data:TData; Index:word);
........
procedure THIDatePicker._work_doTime;
begin
DatePicker.DateTime:=ToReal(_Data);
end;

И радуешься, если знаешь откуда взять действительное число на вход.
Что собственно и является предметом настоящего обсуждения


карма: 9

0
Разработчик
Ответов: 26149
Рейтинг: 2127
#43: 2007-03-16 10:48:15 ЛС | профиль | цитата
oldTV, нет этого метода в компоненте. Я добавил этот метод для DataPicker'a в версии XLStrGrid'a, чтобы брать данные из ячейки и, пока, только для даты (для времени -- нет). Я, конечно, могу добавить этот метод и в основной компонент DataPicker, но у меня нет никаго желания, затем, брать на себя ответственность по его поддержке.

[size=-2]------ Добавлено в 10:48
Galkov,
я по другому решил этот вопрос, но с датой
........
     procedure _work_doSetDate(var _Data:TData; Index:word);
........
procedure THIDatePicker._work_doSetDate;
begin
DatePicker.DateTime:= Str2DateTimeShort(ToString(_Data));
end;
карма: 22

0
Ответов: 9906
Рейтинг: 351
#44: 2007-03-16 11:10:52 ЛС | профиль | цитата
Кстати, про радуешься - до поры до времени.
Ибо ключница водку делала...
Он сделан в том же "рационализаторском" стиле, что и FontBox
http://hiasm.com/xf/topic.php?p=49249#P49249
Т.е., являсь наследником Win, таковым по сути не является.
Дурдом на каникулах
карма: 9

0
Разработчик
Ответов: 26149
Рейтинг: 2127
#45: 2007-03-16 11:22:41 ЛС | профиль | цитата
Galkov писал(а):
Он сделан в том же "рационализаторском" стиле, что и FontBox

то-то он нет-нет и подглючивает. И зачем его наследником Win'a пихать? В принципе, он может быть наследником любого контрола.
карма: 22

0
Сообщение
...
Прикрепленные файлы
(файлы не залиты)