Выбор даты в календаре

[Vstr]

Пытаюсь сделать так что бы при выборе Определенной даты в календаре появлялась надпись, но надпись появляется при выборе любой даты.
Помогите!Заранее спасибо!

procedure TForm1.Calendar1Change(Sender: TObject);
begin
if Calendar1.Date='01-06'+ (Calendar1.Date) then
Label1.Visible:=true
else
Label1.Visible:=false;

end;

[pupsik]

Код: Выделить всё

if Calendar1.Date='01-06'+ (Calendar1.Date) then

если "строка даты" равна "строка" + "строка даты", то =..... - это, кажись, бред (или я ошибаюсь?)...

Попробуйте так:

Код: Выделить всё

procedure Tfrm_main.Calendar1DayChanged(Sender: TObject);
var
  i : integer;
begin
  i := CompareStr(Calendar1.Date, '01.06.2016');
  if i = 0 then
    Label1.Visible :=true
      else
        Label1.Visible :=false;
  Label1.Caption := Calendar1.Date ;
end;

{ Tfrm_main }

initialization
  DateSeparator := '.';
  ShortDateFormat := 'dd.mm.yyyy';
  LongDateFormat := 'dd. mmmm yyyy'; 

п.с.
Жестко указывать формат даты - весьма плохой вариант. Что бы работало вам необходимо сперва узнать какой формат используется в системе и по нему проводить проверку. Или перевести дату в удобочитаемый для вас вариант (для сравнения).

[sign]

Код: Выделить всё

Label.Visible := Calendar.Date = StrToDate('01.06.2016');
Label.Caption := Calendar.Date;

[alexs]

Vstr
Работать с датой как со строкой НЕЛЬЗЯ!
Есть специально тип TDateTime

Код: Выделить всё

procedure TForm1.Button3Click(Sender: TObject);
begin
  if Calendar1.DateTime = EncodeDate(2016, 06, 14) then
    Label3.Caption:='Совпало!'
  else
    Label3.Caption:='Неудача';
end;


Будет работать всегда, вне зависимости от вашей локали и настроек отображения.

[Vstr]

Все работает! Спасибо!

[pupsik]

Работать с датой как со строкой НЕЛЬЗЯ!

хм... Почему об этом sqlite не знает (и не только)?
п.с.
sign у вас получается: если "строка" равна "дате". Т.е., если не ошибаюсь, должно быть:

Код: Выделить всё

Label.Visible := Calendar.DateTime = StrToDate('01.06.2016');
Label.Caption := Calendar.Date;

[alexs]

хм... Почему об этом sqlite не знает (и не только)?

Вы работаете со строками или с датами?
А кто вам гарантирует, что в строке будет именно дата? И именно ожидаемого вами формата? Например - что вот здесь записано - 07.06.2016
Это 7 июня 2016 года? Или 6 июля 2016?
Потому пользуйтесь типом TDateTime, который предназначен для хранения дат.
PS
А насчёт sqlite - у меня очень не однозначное отношение к этой недоБД.
Пока в неё хранится мало данных - ещё можно мириться с ней. Но вот когда данных становится больше (неожиданно) - и всё.
В качестве примера можно посмотреть, как работает amarok (пришлось его на MySQL переводить) на большой музыкальной базе, или QuiteRss с большой базой новостей.

[pupsik]

Вы работаете со строками или с датами?

код выше. ..

А кто вам гарантирует, что в строке будет именно дата?....

см. выше... Т.е.

удобочитаемый для вас вариант

А насчёт sqlite - у меня очень не однозначное отношение к этой недоБД.

оно занимает свою нишу. А то что при написании программы не учли вариант работы с большим набором это является проблемой хранилища?

п.с.
я не пользуюсь кде... а то что на гноме вполне таки нормально работает. Хотя, по памяти, greatnews пользуется литлом. И когда им пользовался вполне таки шустро работало (10000 + подписок, если не больше).

А кто вам гарантирует, что в строке будет именно дата? ...

если не ошибаюсь то это и есть причина такого рода хранения дат в sqlite. Как бы своего рода стандартизация.

[Лекс Айрин]

pupsik, работа с датами это как раз тот случай, когда неизвестно как поведет код в каждом конкретном случае.

[alexs]

если не ошибаюсь то это и есть причина такого рода хранения дат в sqlite.

В базе оно может и стандартизировано (хотя не факт, надо смотреть специ и исходники - вдруг там региональные настройки тоже учитываются).
А вот на вашем (как разрабочика - прикладника) уровне вы работаете с представлением дат в виде строки, которое вам отдала библиотека доступа к БД. А она точно будет зависима от региональных настроек.
И ещё - учитываете следующее :
- В файле БД дата хранится в виде строки
- ядро sqllite перекодирует эту строку во внутренне бианрное представление даты
- движок из лазаря (sqldb или zeos) приводят это бинарное представление к TDateTime
- вы, обращаясь к значению поля как к .AsString заставляете перекодировать TDateTime в string
Не многовато ли действий? Причём последнее абсолютно лишнее, ведущее только к замедлению.
И ещё - как вы будете делать эелементарную задачу - увеличить дату на 1 день? для TDateTime это просто D+1. А для даты в виде строки надо кучу телодвижений сделать.

А то что при написании программы не учли вариант работы с большим набором это является проблемой хранилища?

Это является проблемой разработчика, которую он почему-то переносит на пользователя.
Поэтому я и сказал о неоднозначном отношении. Разработчик ленится подумать о последствиях использования. Кажущаяся простота в дальнейшем вызывает проблемы.

Добавлено спустя 44 секунды:
Надо последние посты во флейм переносить. Они к данной теме не имеют отношения.

[pupsik]

Лекс Айрин

сперва узнать какой формат используется в системе

не оно???

...эелементарную задачу - увеличить дату на 1 день?...

а вопрос о ней?
По поводу исходников... Если это про компоненты то я не о них писал...

п.с.

Это является проблемой разработчика...

вроде я аналогично написал... Только не столь широко Или вы имели ввиду разработчика sqlite?

[Лекс Айрин]

не оно???

А где уверенность, что формат даты системы совпадает с форматом даты источника? Например, той же БД. Например, по известным мне данным, американцы пишут сначала месяц, а потом число.

[alexs]

а вопрос о ней?

Просто это будет следующий вопрос.

вроде я аналогично написал...

Я именно о этом и говорю, что не однозначное отношение. И именно для разработчиков-прикладников. Кажущаяся лёгкость работы с этой системой порождает проблему того, что отлично написанное приложение и проверенное на тестовых данных начинает дика лагать в боевой ситуации. И потом приходится переделывать.
Поэтому и предупреждаю.
ps
Для таких систем я бы всё же рекомендовал брать FireBird - вот у него с мсаштабируемостью данных этих проблем нет.

[pupsik]

Лекс Айрин зная что в системе "творится" куда проще работать.
Угу, американцы
Они ищо и ругаются, если не соответствие. И это не только они. С этими системными форматами можно "влететь". Из-за этого и жесткая установка удобная вам - не есть найс.

Просто это будет следующий вопрос.

вопроса то ищо нету.... Дык что. Будет день - будет пища.

Для таких систем я бы всё же рекомендовал брать FireBird...

я ничего не предлагал и не рекомендовал. просто весьма замечательный пример.

[Лекс Айрин]

зная что в системе "творится" куда проще работать.

Но это может только программист в идеальной (собственной) системе.

Из-за этого и жесткая установка удобная вам - не есть найс.

Именно для этого есть тип TDateTime. Все остальные варианты это "жесткая установка". И, кстати, у меня не было задач в которых дата имела существенное значение. Максимум, вставка текущей в текст. Ах да... еше "тикающие" часы с датой.