» Вопросы по Delphi (до версии 2009) - часть 6

Самое главное, что задача автора решается ЛУЧШЕ всего просто добавлением метода в форму.
Не универсального, не создающего наследований и т.д.
Просто по событию Firebird Event или таймеру вызывается что-то типа
procedure UpdateEditColors;
begin
if () then
begin
edit1.color := clRed;
dtPicker1.color := clRed;
end
else
begin
edit1.color := clWindew;
dtPicker1.color := clWindow;
end;
end;

DevEx само по себе монстроидальное порождение, лазить туда и переопределять что-то, это беда. У автора же не фреймворк пишется.
Затраты времени здесь, как на разработку, так и на поддержание ОПТИМАЛЬНЫЕ.
Даже если три пикалки-бибикалки позже добавлять.
И не нужно плодить сущности без необходимости.


P.S. С т.з. что использовать - таймер или events:
если события происходят часто - таймер. если редко - events

krapotkin

Цитата:

DevEx само по себе монстроидальное порождение, лазить туда и переопределять что-то, это беда.

лазюю, переопределяю, все ок. ЧЯДНТ? даже справку для этого читать не обязательно, есть нормально написанные сорцы, и не нужно уж так его бояться, особенно когда нужно всего-то немного переопределить поведение/добавить небольшой функционал..

Цитата:

Затраты времени здесь, как на разработку, так и на поддержание ОПТИМАЛЬНЫЕ.

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


Добавлено:
XPerformer

Цитата:

На делфи это можно организовать как некий цикл (типа оконной процедуры), который себе крутится и проверяет, а не свистнул ли рак, а не нажал ли юзер кнопку, а не 13-00, четверг ли сегодня и т.п.
Сервисы - реализовать как классы (синглетоны или нет), отдельные процедуры или как угодно

Это имеет смысл в некоторых ситуациях (например переопределение WndProc), но реализовывать подобное надо очень аккуратно и вдумчиво. и это никак не 'универсальный OnChange'

Цитата:

лазюю, переопределяю, все ок

Знаю нескольких людей. Доопределялись, до сих пор с 3-4-й версии девок уйти не могут, потому что много чего дописано/доделано.

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

Добавлено:
Плохо менять код самих компонентов - мерджить изменения надоест, но когда все на наследниках - апдейт до версий происходит достаточно плавно

A_V

Цитата:

на каждый эдит на ончендж еще надо выставить такой код по условиям задачи.. куда уж там оптимальней.

По условиям задачи как раз извне приходит сообщение и надо вызвать некий метод, который произведет изменения свойств компонентов.
Не делать же наследника TEdit, который сам в базу лазит?

А по поводу гигантизма DevEx достаточно ознакомиться с процедурой установки, не заглядывая в исходники ))

krapotkin
правильно, это внешний момент, он и должен вызываться внешне.
изменение цвета по реакции на ввод данных пользователем в контрол - внутреннее дело контрола. (т.е если это не одиночное поведение, а стандартное для приложения/формы надо и решать его на уровне приложения/формы).
вобщем не надо смешивать эти две задачи - по синхронизации данных между пользователями, и по обработки данных контролами.
мой вариант решения занимает где-то 10 строк кода, с объявлением типа, декларацией метода, begin/end. для всех контролов на форме. если нужны не все, добавляется одно св-во. все. что может быть проще?

насчет гигантизма devex - да, пожалуй, это самая большая сторонняя библиотека для delphi, но это не значит, что нужно бояться написать к какому-то контролу своего наследника. vcl вот тоже не маленький..

krapotkin
Ваше предложение

Цитата:

procedure UpdateEditColors;

это из той же оперы, что и у XPerformer
Только хуже...
A_V предложил вариант, который:
а) легко поддерживаемый
b) легко расширяемый
с) легко тестируемый

Ваши варианты имеют право на жизнь, но для программки на 100 строк и 5 формочек... При увеличении же сложности Вы запаритесь поддерживать свой код.


Ну а по поводу того, что DevEx большие и сложные и лезть туда - ни-ни (привет XPerformer с его предохранителями), то в .net влазят в сборки от Microsoft, меняют и заставляют работать то, что не работало (или работало не верно\не оптимально). А код в Dev достаточно "красивый и лазить по нему - одно удовольствие.

Уважаемые Мастера, поставили мне задачу нарисовать прожку наподобии TeamViewer'а.
Облазил весь инет в поисках каких-либо похожих исходников - результат плачевный.
Ума не приложу, с чего начинать.
Не подскажет ли кто, с чего начинать-то?
Спасибо.

Grande
http://sourceforge.net/projects/ultravnc/develop
посмотри на это для начала. такую программу написать ооочень сложно.

YuriyRR
Мда... Полная ж... Спасибо за наводку, буду пробовать.

salexn1
без выпячивания, просто в порядке объяснения:
учитывая, что сейчас одна из моих программ в реалтайме обрабатывает по 2 гб данных в день, другие тоже работают с нехилой нагрузкой, используя и TCP, и базы данных, и datasnap и андроид, и еще много чего; да и занимаюсь я этим делом скоро как 20 лет, посчитал себя вполне способным высказать мнение "из опыта". Можно не принимать его, но пункты абц в соединении с постановкой задачи абсолютно точно выполняются.
В т.ч. для меня как руководителя бизнеса, важно, что не надо будет для поддержки находить/отвлекать высококлассного специалиста, которые все ох как заняты обычно, а достаточно крепкого середнячка.

Каждому случаю лучше подбирать свой инструмент, иногда и без расчета на "а вдруг через 10 лет"...
Ну да решать вам.

krapotkin
Конечно, выбирать будет каждый сам.
Но Вам, как руководителю, даже скорее как владельцу продукта, должно быть тем более важен, такой фактор, как легкость поддержки.

Тот код, который Вы привели, имеет право на жизнь, но только в том случае, если это код на одной форме, для программы, которая не будет развиваться.

Для той модели, которую предложил A_V, не нужен супер программер. Кода там - 3 строчки. А вот Ваш, если будет не 2, а 10 edit и разные условия разрастется до ужасных размеров, и стоимость с каждым добавленным Edit будет расти просто экспоненциально.

Прошу прощения за, возможно, простой вопрос:
Как в EhLib'е в заголовке сделать две строки? Забыл напрочь

Grande
Нужно Caption через "|" разделять:

"Отчет | С", "Отчет | По"

salexn1
Спасибо огромное, получилось

Доброго времени суток!

Уважаемые, просьба помочь разобраться, у меня прога опрашивает контроллеры(в принципе данные однотипные) и вот во время работы почему то IdTCPClient иногда(от раза в 10 циклов(1-2с) до раза в сутки (это оч дох циклов)) выдает ошибку по тайм ауту, хотя данные приходят, у меня Delphi7. Что данные приходят видел снифером, ещё один момент который смог выявить, если от контроллера идет один пакет с данными, тогда работает нормально(Это один тип контроллеров), а если 2, причём первый пустой(зачем он там мне производители контроллера объяснить не смогли) тогда косяк (Это второй тип контроллера) в первом пакете стоит только Флаг А, второй уже АР, по идее пока не придет флаг Р программа не должна нечего получить. Уже две недели бьюсь с этой проблемой и никакого толку((( Помогите плиз!

sammozg
какая версия Indy? это важно
попробуйте поставить самую последнюю 10ю (качать с ихнего сайта)

ant0ni02004
Спасибо за свет, я пока ен пробывал ставить Indy10.
Я переконвертировал проект в Embarcadero RAD Studio XE3 вроде бы работает, но пришлось немного перелопатить проект, до этого пытался поработать в Embarcadero RAD Studio 2010 выходила ошибка с переполнением float в Kernel32.dll, сейчас пока тестирую, надеясь на лучшее.

sammozg
можна и так. в ХЕ3 уже 10-я версия стоит. но вот последняя ли...
а так обновлять её легко - переписать старые файлы новыми и перекомпилировать

ant0ni02004
Попробую в понедельник, я там изменения вводил в обработчике сервера, да и в клиентской части тоже не хило потрудился, посмотрим что получится...

Можно ли сделать так, чтобы функция, которая определена в одном файле, вызывалась в другой? Подключаю в делфи файл-unit к файлу, в котором нужно вызывать функцию... при попытке вызова выдает ошибку

Termis

Цитата:

при попытке вызова выдает ошибку

если выдает ошибку при попытке вызова - значит вызывается
видать вы ее вызываете с неправильными/неопределёнными параметрами
вот если бы ошибка при компиляции - тогда другое дело, не вызывается.

ant0ni02004
беру тупо копирую функцию из Unit2 в Unit1 - вызывается на ура...
перемещаю в Unit2 - ошибка...
причем ошибка - незадекларированная переменная: имя функции...

Termis
хммм.... а вы в unit1.pas написали uses Unit2 ?

Цитата:

хммм.... а вы в unit1.pas написали uses Unit2 ?

да, даже через File - Use unit подключал чтобы правильнее было...
И проект заново создавал ...

Termis
тогда остаётся только предположить, что функция не объявлена в interface секции unit2

что здесь устраивать секс по телефону, код в студию и все дела...

Цитата:

тогда остаётся только предположить, что функция не объявлена в interface секции unit2

спасибо! описал прототип функции - все заработало! спасибо.

Снова проблема...
Все тех же два Unit-а... В Unit2 имеется функция... тип возвращаемого значения - массив
т.к. явно функция не может возвращать массив в type в unit2 добавлен новый тип

Цитата:

IntArray = array[0..15] of integer;

сама функция:

Цитата:

function strpr(str1: string): IntArray;

В Unit1 в type добавлен точно такой же тип, как выше..
по событию onClick для кнопки выполняет событие, в котором объявляется новая переменная типа IntArray
далее - ab := strpr('aaa');
т.е. в ab должен быть результат выполнения функции strpr.
на стадии компиляции выбивает ошибку -
Несовместимость типов данных Uni1.IntArray и Unit2.IntArray
хотя описание типа в Unit1 и Unit2 абсолютно одинаковое. 200 раз проверял...
Как исправить?

Termis
Создать 3-ий модуль DataTypes и там объявить ваш массив и использовать его по всей программе.

Не смотря на то, что у вас один в один объявлено для компилятора это разные типы ( и это правильно)