Дамы и господа, пишу курсовой на Delphi тема проста как пять пальцев - "Органайзер" столкнулся с некоторыми банальными и не очень трудностями. Помогите пожалуйста в решении пары траблов и как более опытные подскажите лучшие чем мои алгоритмы. Исходный код (правда в нем много мусора) прилагается.
Кратко о проекте: 4 формы. Основная форма, это TMonthCalendar и TMainMenu. Вторая форма это добавление события на дату.Третья - чтение события с даты (т.е при двойном щелчке на дате в MonthCalendar на основной форме). Четвертая - пока не активная (пытался сделать несколько событий на одну дату). Пятая(ну как же без сентиментализма) - "О программе" или хвала разработчикам
===
Трабл #1) Довольно странная ошибка - сохраняю событие в файл
 showmessage(inttostr(filepos(base))); - выдает мне текущую позицию указателя в файле, дык вот при каждом сохранении программа перезаписывает предыдущую запись т.к. указатель не сдвигается, хотя это должно происходить автоматически
--
На всякийслучай - проверьте корректность чтения
--
Трабл #2)Сохранение выравнивания текста

    1)Проверяю применены ли операции выравнивания посредством стандартных action'ов и присваиваю их выделенным под них элементам булево-массива в типе данных

        

    2)При Двойном щелчке на дате проверяю содержимое файла на операции выравнивания и определяю свойства объекта RichEdit1 на форме три

        

    Как видите пробовал по разному, в том варианте который вы видите сейчас я присваиваю булева массиву который использую как флаг значения а на создание формы три вешаю присвоение выравнивания либо вариант два

        

Вопрос по другим свойствам текста, почему операция
Приводит к "[DCC Error] Unit1.pas(122): E2010 Incompatible types: 'TFontStyles' and 'TFontStyle'"
Как это предотвратить?

Если у кого-нибудь появится идея как можно написать (условиях уже написанного кода, т.е дописать) запись нескольких событий одного или разного типа на одну дату буду очень рад выслушать и принять к сведению.

Есть еще парочка вопросов и траблов, но их пока трогать не буду. Заранее благодарю

Присоединённый файл ( Кол-во скачиваний: 70 )
 bproject.zip 476,76 Kb

BlackDan, во-первых: сильно много букв. Не устал писать? Я пока до последней строчки дочитал - забыл что было в начале.

И сразу вопросы: а почему ничего не работает? Непонятные названия? И что вообще убило - поиск записи для редактирования (по дате и времени создания записи) задаешь вплоть до секунд! Я например если сделаю заметку, а для того она и делается что память ни к черту, я не буду помнить в какой дате я ее назначал, и уж точно не скажу в котором часу, минуте и секунде! 

А вообще не люблю я работать с текстовыми файлами если надо хранить более 10-100 строк, и еще постоянно их обрабатывать. Мой тебе совет - использу базу данных, хоть Аксесс, реально проще.

Вот когда-то мне делать нечего было тож писал органайзер, но все время отвлекали, так и не закончил его. Ниже ссылка на файл (весит ~3Мб, а здесь можно только метр, так что залил на  летитбит) - мой проект, еще прошлогодний, много чего надо доработать, но по крайней мере работает. Может музу играть, сообщение показать, или прогу запустить, плюс сколько угодно записей на одну дату!, плюс поиск (корректный, по календарю), плюс висит в трее (исходник "трея" был из какойто книжки, я его просто под свои нужды подмонтировал, и т.д.). Приятный, более менее красивый интерфейс программы, только кнопки бешено мигают, та надо проверку на текущую картинку поставить, и все будет ок.

Вообщем могу много хвалить, а времени мало... Вот "оно": Органайзер.rar

Не вижу ничего странного.
Reset переводит указатель на начало файла.



Лучше сделать так:
поле с_t.Format сделать типа TAlignment(нажмите F1), будет занимать 1 байт и будет сохраняться/загружаться и использоваться гораздо легче.



потому что RichEdit1.font.Style - это набор из стилей.
нужно так: RichEdit1.font.Style:=[fsbold]; И это следует хотя бы из инспектора объектов.

Добавлено через 2 минуты и 2 секунды

Да?
А я бы не сказал так. Но вам виднее.

Добавлено через 4 минуты и 29 секунд

Ну, это кому как.
Не сложилось у меня с базами. Хотя Access даже не требует присутствия офиса на компьютере, поддержка его баз заложена в саму Windows. Но - все равно не сложилось.
Наверное, потому что задач, действительно требующих работы с базами и только с базами до сих пор не было.

Я думаю дело не в количестве строк, а в структуре проекта. Я бы здесь использовал БД, хотя в данном случае это должно оговариваться преподавателем.

Спасибо, но как тогда правильно открыть типизированый файл, append'ом не открывает

Да, так намного лучше!

Я имел ввиду под простотой не сложность программы, а простоту понимания темы как таковой   

У вас случайно нет идей как записать на одну дату несколько событий без использования БД?

для кажой даты на которую создается событие(я) создавать файл, и хранить несколько событий там

Слишком много файлов, а это не есть хорошо=) Я уже думал о таком решении и решил что оно не из лучших но все равно спасибо)

Все, траблы с записью решил =) Записываю теперь так 

А читаю вот так:


Оцените пожалуйста корректность и оптимальность кода. 
===
FontStyle тоже записывает теперь нормально, а вот выравнивать не хотит...
Сохранение(На форме2 во время сохранения всех данных в файл):

Присваивание(происходит на форме1 при двойном клике на дату): 


Это сообщение отредактировал(а) BlackDan - 1.6.2009, 15:49

поэтому и придумал бд, но файлы тоже не так плохо, просто называть их 0106.txt для примера... и все... сколько много? в год максимум 365 файлов, это разве много... тем более не каждый же день события... хз, а для каждого года создавать новую папку... и получится вполне нормально... 

В принципе тоже верно =) 

так.
Все нижесказанное - сугубо imho, не претендующее на истину ни в какой инстанции.

для чтения/записи в файл давно придумали TFileStream. А всякие AssignFile и иже с ними - пережитки паскаля. Но это не значит, что их нельзя использовать - все зависит от задачи.

Мое видение процесса (ваши исходники я НЕ скачивал).
Файл должен быть один. В начало записывается количество записей, потом - сами записи. Я использую работу со строками (т.е. string, а не string[200] к примеру).



Это был код только для чтения и записи строк.
Теперь - работа по сохранению записей. (пример, опять-таки).



Итак, теперь у нас есть код считывания/записи каждой структуры нашей базы.
Настало время загрузить базу полностью:



Вот и все.
Осталось только привести процедуры загрузки/записи в/из файла.


Напоследок:
Я понимаю, что переделывать код - это не хорошо.
Но если задачу начинать с нуля, я бы сделал ее не записями, а объектами, каждый из которых будет иметь свои поля, возможно - собственные методы редактирования, определения срабатывания события и т.д. (однозначно - методы сохранения и записи в поток).
И - не массив для их хранения, а потомок TList или TObjectList. тоже - с добавлением нужных методов.

1. Добавить в описатель заметки поле Date:TDateTime; (само собой - с сохранением/загрузкой этого поля)
2. После загрузки/добавления записи проводить сортировку по этому полю.// хотя можно и без этого
3. При выводе (клике на календаре) проходить в цикле по всей базе. Если поле Date (с отбросом времени, которое лучше делать при добавлении заметки) совпадает с выбранным в календаре - отображать в форме№4.

У меня примерно так и работает =)

Так и не могу разобраться с выравниванием текста...

В принципе, с richEdit я не работал, но все же задам вопрос:


Это до или после загрузки в RichEdit текста?
Мне кажется (только кажется) что выравнивание, fsBold и иже с ними свойства должны присваиваться до записи самого текста.

BlackDan, просто хочу дополнить.
Я так понимаю, что утебя запись в текстовичке может выглядеть следующим образом:

31.05.09|Сам текст заметки|дополнительная инфа...|еще что нибудь

ты ее парсишь при загрузке в прогу по символам-разделителям типа "|" и вуаля! или еще как-нибудь.

но не все так просто, как кажется... 

Во-первых, если твой органайзер работает по принципу: "оставил сегодня заметку - смогу завтра ее найти и прочесть", то чаще всего пользователь забывает не события, а как раз таки даты этих самых событий. Поэтому поиска заметки только по дате - недостаточно, надо бы организовать просмотр всех имеющихся заметок (списком), а также по ключевым фразам или словам и уже при выборе необходимой заметки показать о ней всю информацию. 

Во-вторых, пользователь вообще может забыть о том, что вообще когда-то делал заметку в этом твоем органайзере, поэтому появляется необходимость периодически напоминать юзверю о заметках, типа "Не желаете ли посмотреть хронологию заметок?". Тем самым данная тактика плавно перетекает из заметок в задания. Например, пользователь назначает органайзеру задание, и последний в свою очередь обязан периодичеки как-то информировать польз-ля о выполнении задания, будь то вспл. подсказки, звуки, всякие мессаги и т.д., не это важно, а то, что органайзер не может ограничиться единоразовым уведомлением, так как юзера в данный момент может не оказаться за компьютером. Теперь в базу данных органайзера (или в текстовичек, как у тебя) надо добавить еще одну запись "completed" с данными логического типа: Да (задание выполнено, пользователь подтвердил уведомление), и Нет (задание не выполнено или не подтверждено). А также появятся поля не только даты записи задания, но и даты, когда это задание надо выполнить.

В-третьих, органайзер изначально означает, программу способную "думать" или как помощника пользователя в выполнении рутины. Поэтому в програму можно добавить такую тюльку как периодический запуск определенных программ (чекер эл. почты, дефрагментатор, оптимизатор и т.п.), а при большей фантазии можно сделать, например, запись истории посещения сайтов, или открытия каких нибудь док-тов, или хронология chat'ения, показ прогноза погоды, времени работы, мониторинг инет-трафика и т.д. Это все конечно необязательно, но очень желательно. Так в моем понимании органайзер должен делать за пользователя. 

Предположим, я слежу за новыми темами на каком нибудь сайте, форуме или блоге и там нет возможности подписаться на уведомления об обновлениях - так пусть органайзер и лазит в инет и проверяет не добавилось ли на сайте новых материалов за мое отсутствие! Ну это я так, к слову!

PS: Может я здесь много трепался и не по делу, просто всегда вспоминаю слова одного, еще колледжевского преподавателя: "Никогда, никогда даже не надейтесь что вашими программами будут пользоватся опытные пользователи и профи, ими будут полные ламерюги, не знающие куда бы тыкнуть чтоб работало! И пишите программы так чтоб конечный ее пользователь не смог ввести данную прогу в заблуждение и вызвать ошибку программы!". И еще в какм-то топике, один из участников данного форума, однажды мне написал, что-то вроде: "Sanek123, пишите стихи, поэмы! Программ - не пишите!", что я собственно и делаю... А пример структуры БД можно посмотреть в аттаче во втором посте. Я не заставляю юзать прогу БД, а посмотреть стутуру, стиль, и сделать ее в конечном итоге наиболее удобной для использования.

Я допускаю возражение, что это всего лишь курсовой проект (даже не курсовая работа), и зачем ее так усложнять?. Подумайте, сколько всяких органайзеров есть сейчас в сети? Теперь представьте "свой" среди этой кипы! чем он лучше всех остальных? А может даже хуже? Тогда уменя вопрос "как прогрммист программисту" : зачем писать никому не нужные программы? Или те, которые (заведомо) не смогут выдержать конкуренции среди себе подобных? Насколько я понимаю при защите необходимо доказывать также экономическое положение и востребованность программного продукта. А он востребован, если если имеет минимум возможностей?
Тем более курсовоу проект не редко прерастает в дипломный. Так может стоит позаботиться об этом зараннее?
Я ктому что пока прога не разрослась можно обойтися и без БД. А потом? Даже если тебе так не нравиться Access, используй DBF, по сути такойже текстовичек только с готовой разметкой! Разумеется "готовую разметку" придеться делать самому ручками с нуля - зато уже настоящая база данных.

Фух, устал...