Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » Вопросы по Delphi (версии 2009, 2010 Weaver, 2011 Fulcrum)

Модерирует : ShIvADeSt

 Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111

Открыть новую тему     Написать ответ в эту тему

data man



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Обсуждаем новые возможности и баги
Просьба писать только про Delphi 2009 и выше - по остальным версиям есть соответствующая тема.
Вопросы вареза здесь не обсуждаются !!!
См. также:
Известные важные баги Delphi 2010:

Описание________________________________________________ Исправлено Решение/Альтернатива_____________________
  1. Внимание !  Деинсталляция D2010 нарушает работу D2007 и D2009 !  
При деинсталляции удаляются CC3280MT.DLL и CC3290MT.DLL из Windows\System32,   необходимые для работы D2007 и D2009 соответственно.
Сделайте резервные копии
  2. Code Formatter не работает, если не инсталлирован пакет моделирования.   В нем также присутствует множество багов. Используйте с осторожностью.   1.   JEDI CodeFormat 2.44 SVN Snapshot (~750Kb)   Требуются JCL и JVCL  
2.GExperts with Formatter
  3. Не работает F1 в Object Inspector Update 2   IDEFixPack 2.9 от Andreas Hausladen
(dev. snapshots)
  4. Если IDE начинает падать с сообщением "Out of resources", возможно, что поврежден .res файл проекта. Удалить его, запустить IDE, открыть проект - новый .res файл будет создан автоматически.
  5. В редакторе не работает Class Completion, если в декларируемом классе есть поля с шаблонами. Перед декларированием поля добавить public или private и т.д.
  6. TTrayIcon.ShowBalloonHint() не работает на ОС ниже Vista [QC 77561] Update 2 * Установить Update 2   * ИЛИ почитать о причинах и решении проблемы на форуме embarcadero и в QC   * ИЛИ воспользоваться альтернативой, например Cooltray 4.4.0
  ...      


Всего записей: 1696 | Зарегистр. 13-10-2005 | Отправлено: 14:28 26-08-2009 | Исправлено: data man, 18:27 06-08-2010
eddoc



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Frodo_Torbins

Цитата:
По поводу потоков: из потока вообще нельзя обращаться к VCL

а если сильно нужно?
 
Вообщем, я тут поэкспериментировал. Для начала переопределил свойство окна в методе CreateParams
 
Получилось с рамкой, зато не сливается с подлежащей формой
 

 
Также попробовал убрать рамку. Получилось примерно так
 
 
 
ну, или так (если Flags:= BF_BOTTOMRIGHT or BF_TOPLEFT;)
 

 
Первый вариант мне показался более эстетичным, решил остановиться на нем.
 

Всего записей: 328 | Зарегистр. 25-11-2007 | Отправлено: 16:51 13-08-2012 | Исправлено: eddoc, 17:11 13-08-2012
neznayka3

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
недавно прочитал мнение, что нельзя хранить тексты sql запросов на клиенте. где тогда хранить, в ресурсах?

Всего записей: 385 | Зарегистр. 07-06-2007 | Отправлено: 12:53 14-08-2012
Frodo_Torbins

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
eddoc
Цитата:
а если сильно нужно?
Если сильно нужно, то юзаем Synchronize. У вас он используется далеко не всюду, где должен.
 
neznayka3
Мне кажется для этого вюхи предназначены: Представления (VIEW) в MySQL.

Всего записей: 2319 | Зарегистр. 24-05-2007 | Отправлено: 13:07 14-08-2012
JAPWork

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
neznayka3

Цитата:
нельзя хранить тексты sql запросов на клиенте

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

Всего записей: 470 | Зарегистр. 12-02-2003 | Отправлено: 14:11 14-08-2012
Samotek

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Frodo_Torbins

Цитата:
Мне кажется для этого вюхи предназначены:

а если запрос с разными колонками? Например нужны только розничные цены или остатки только из определенного подразделения? То есть запрос создается динамически. Столько вьюх не напишешь.

Всего записей: 2468 | Зарегистр. 18-05-2005 | Отправлено: 14:20 14-08-2012
eddoc



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Frodo_Torbins

Цитата:
Если сильно нужно, то юзаем Synchronize. У вас он используется далеко не всюду, где должен.  

А как по-вашему выглядел бы идеальный код в моем случае?

Всего записей: 328 | Зарегистр. 25-11-2007 | Отправлено: 14:45 14-08-2012
neznayka3

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Frodo_Torbins
выборки напрямую из таблиц у меня нет, только view & functions.
JAPWork
на sqlru тема зашла, за что руки разработчикам отрывать) начали с with, правда не понял, почему им лучше не пользоваться, только во время отладки разве что неудобно бывает. тему сходу сейчас не нашел.

Цитата:
 И что означает "нельзя на клиенте"

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

Всего записей: 385 | Зарегистр. 07-06-2007 | Отправлено: 14:45 14-08-2012
A_V

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
neznayka3
JAPWork
возможно имелись ввиду трехзвенки (DataSnap), но даже если брать clinet-server, то бывает удобнее держать запросы во вьюхах, хранимках (mssql), объектах (oracle) или даже в своих таблицах.
 
удобнее например тем, что для изменения запроса (напр. добавление поля в список) не нужно пересобирать и раскладывать клиент (есть например реализации, в которых даже клиентские формы строятся на сервере). также удобно то, что в случае изменения схемы данных объект на сервере сразу станет инвалидным (oracle), а не отвалится в момент использования (вобщем классическое раннее/позднее связывание).  
могут быть и варианты с использованием нескольких субд, когда клиент знает наименования процедур и полей, но то что внутри - его не касается.
еще из минусов хранения текстов запросов на клиенте в dfm - их неудобно мерджить в системах контроля версий. если же тексты писать в коде, то постоянная конкатенация строк тоже выглядит не очень. еще ORM реализации есть, живьем на delphi их правда не встречал...
 
но случаи разные, для большинства мелких/средних задач запросы на клиенте хранить вполне подходит.
 
Добавлено:
neznayka3
ну вот, опередил пока набирал, именно что
'текст запроса не изменить, без перекомпиляции. иногда имя колонки/функции/кол-во параметров/итд изменилось или еще чего'

Всего записей: 770 | Зарегистр. 07-04-2002 | Отправлено: 14:47 14-08-2012 | Исправлено: A_V, 14:52 14-08-2012
JAPWork

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
neznayka3
A_V

Цитата:
текст запроса не изменить, без перекомпиляции.

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

Всего записей: 470 | Зарегистр. 12-02-2003 | Отправлено: 15:45 14-08-2012 | Исправлено: JAPWork, 15:58 14-08-2012
A_V

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
JAPWork

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

 
не настолько уж и редки, в типичных КИС, почти половина форм - это списочные, т.е нужно получить список (грид) каких-то сущностей, предварительно его отфильтровав. (аотом эл-ты этого списка редактируются в отдельной форме). при хранении запросов на сервере, такая универсальная списочная форма на клиенте программируется всего один раз.
 

Цитата:
В самом же общем случае (типовой пример - пользователь попросил обеспечить указание периода за который следует получить отчет) - никуда не денетесь, будете втискивать на форму поле с датой, а то и с диапазоном дат.  

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

Цитата:
Хранение на сервере - лучше, но панацеей от перекомпиляции вовсе не является

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

Всего записей: 770 | Зарегистр. 07-04-2002 | Отправлено: 16:08 14-08-2012
JAPWork

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
A_V

Цитата:
иногда является самой что ни на есть панацеей. ... другой вопрос, нужно ли это такой ценой..  

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

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

Ага... Остается поверить, что любая программа теперь - это одна пустая форма. Все остальное вполне по силам возложить на десяток таблиц в БД. На мой взгляд, это тот самый случай, когда из самых общих соображений даже не хочется считать варианты. Просто - не верю.
 
Наиболее полная аналогия - это запросы с параметрами. Можно долго говорить о том, что хорошо проработав предметную часть можно все запросы снабдить десятком параметров, чтобы исключить необходимость какого-либо внесения изменений в запросы в дальнейшем. Увы... Через год эксплуатации с неизбежностью выяснится.. Ну - Вы поняли...

Всего записей: 470 | Зарегистр. 12-02-2003 | Отправлено: 16:39 14-08-2012
A_V

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
JAPWork

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

Не одна пустая форма, но отчеты и списочные формы держать на сервере вполне реально. Просто п(р)оверьте

Всего записей: 770 | Зарегистр. 07-04-2002 | Отправлено: 16:44 14-08-2012 | Исправлено: A_V, 16:45 14-08-2012
XPerformer



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
A_V
А и много ли в серьезном проекте списочных форм, не связанных друг с другом и другими документами, для которых не нужна специализированная форма редактирования? не настолько, чтобы возводить их в правило

Всего записей: 2545 | Зарегистр. 20-06-2011 | Отправлено: 17:11 14-08-2012
A_V

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
форму редактирования, да, лучше делать в дельфе, но ее привязка к списочной форме может настраиваться на сервере

Всего записей: 770 | Зарегистр. 07-04-2002 | Отправлено: 17:21 14-08-2012
XPerformer



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
A_V
то есть на сервере прописывать какие комбобоксы должны быть и прочие вложенные гриды?

Всего записей: 2545 | Зарегистр. 20-06-2011 | Отправлено: 17:22 14-08-2012
A_V

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
XPerformer
речь о гриде списочной формы? если да, то комбобокы тоже могут настраиваться на сервере (в списке 'имя поля -- имя view').  
вложенные гриды= master-detail в cxGride или подобном? тоже можно описать.
более того, можно сделать такое описание удобным

Всего записей: 770 | Зарегистр. 07-04-2002 | Отправлено: 17:45 14-08-2012 | Исправлено: A_V, 17:46 14-08-2012
XPerformer



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
A_V
Формулировка "можно" навевает на мысли о том, что очень многое можно сделать... вопрос - нужно ли тратить на это время? у меня лично все заказчики хотят, чтобы быстро и качественно. Если такой движок написан и отлажен (как правило, речь о команде разработчиков), то конечно, буду его использовать. Но писать движок, чтобы вынести формы на сервер (причем заказчик этот подвиг не только оценит и не заплатит, но даже и не заметит) - искусство ради искусства...

Всего записей: 2545 | Зарегистр. 20-06-2011 | Отправлено: 19:24 14-08-2012
A_V

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
XPerformer
Ядро текущей системы, с которой я работаю, включает по-мимо прочего как-раз
подобную технологию. Проекту больше 10 лет, затрат около 100 человеко-лет.
Время показало, что это довольно удобно.
 
Новую версию системы разрабатываю тоже с похожим подходом - весь код на сервере
в oracle objects, запросы и лукапы во вьюхах.
 
Меня в коде на сервере привлекает даже не уменьшение кол-ва пересборок, а
раннее связывание, удобство написания запросов без копипасты и собственно
разделение логики - серверу серверное )
 
Вобщем переходить на написание CRUD в дельфе совсем не тянет. разве что на ORM
 
C другой стороны видел систему, в которой формы (dfm'ки + FastScript) описывались строками в коде хранимых процедур(!!) - вот такое сопровождать врагу не пожелаешь
 
Добавлено:
так что
Цитата:
нужно ли тратить на это время?

тут каждый сам отвечает )

Всего записей: 770 | Зарегистр. 07-04-2002 | Отправлено: 20:45 14-08-2012 | Исправлено: A_V, 20:46 14-08-2012
ant0ni02004

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
neznayka3

Цитата:
нельзя хранить тексты sql запросов на клиенте

ну не то чтобы совсем нельзя. есть такая схема, когда некоторые запросы (как правило - отчеты, хотя и не только они) хранятся в таблице вида "имя отчета";"запрос" и таким образом во многих случаях при изменении запроса не нужно заново компилировать программу
 
конечно, если под "нельзя хранить" имелись в виду вопросы безопасности (типа никому не показывать структуру БД) - это уже на усмотрение заказчика/разработчика

Всего записей: 442 | Зарегистр. 26-10-2004 | Отправлено: 12:12 15-08-2012
Frodo_Torbins

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Samotek
Цитата:
а если запрос с разными колонками? Например нужны только розничные цены или остатки только из определенного подразделения? То есть запрос создается динамически. Столько вьюх не напишешь.
Чуть выше neznayka3 уже упомянул функции.
 
neznayka3
Цитата:
выборки напрямую из таблиц у меня нет, только view & functions.
В таком случае не стоит парится. В том топике не про ваш случай говорилось.
 
eddoc
Цитата:
А как по-вашему выглядел бы идеальный код в моем случае?
Я бы вынес из потока всю инициализацию в конструктор/деструктор потока. В этом случае она будет отрабатывать в основном потоке и синхронизация ввобще не понадобится. Как то так. Ну а в Execute все остальное. Только "Form1.BtnStopClick(Self);" заменить на "Synchronize(StopClick)".

Всего записей: 2319 | Зарегистр. 24-05-2007 | Отправлено: 12:34 15-08-2012 | Исправлено: Frodo_Torbins, 12:36 15-08-2012
Открыть новую тему     Написать ответ в эту тему

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111

Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » Вопросы по Delphi (версии 2009, 2010 Weaver, 2011 Fulcrum)


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru