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

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в 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
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Вопрос по тредам и отрисовке VCL из потока.
 
Вот в этом тестовом коде
 
Если Image и Label лежат непосредственно на Form2,  

 
то все замечательно отрисовывается

 
А вот если проложить между формой и контроллами Panel (нужна, чтоб форма была "выпуклой", когда у нее BorderStyle = bsNone), то ничегошеньки не отрисовывается.
 
Можно как-то справиться с проблемой?

Всего записей: 328 | Зарегистр. 25-11-2007 | Отправлено: 20:41 11-08-2012 | Исправлено: eddoc, 22:32 11-08-2012
Frodo_Torbins

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
eddoc
Цитата:
А разве отображаемая там консолька не есть cmd.exe?
Нет. Это окошко автоматически создает винда, для каждого консольного приложения, если оно не наследует родительские пайпы. По крайней мере, если это обычное консольное приложение.
 
По поводу потоков: из потока вообще нельзя обращаться к VCL, а у вас там нормальная синхронизация только в одном месте организована.

Всего записей: 2319 | Зарегистр. 24-05-2007 | Отправлено: 13:11 13-08-2012 | Исправлено: Frodo_Torbins, 13:18 13-08-2012
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 запросов на клиенте

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

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

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

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

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

Всего записей: 2596 | Зарегистр. 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

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

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

Всего записей: 474 | Зарегистр. 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

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

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

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

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

Всего записей: 474 | Зарегистр. 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
А и много ли в серьезном проекте списочных форм, не связанных друг с другом и другими документами, для которых не нужна специализированная форма редактирования? не настолько, чтобы возводить их в правило

Всего записей: 2567 | Зарегистр. 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
то есть на сервере прописывать какие комбобоксы должны быть и прочие вложенные гриды?

Всего записей: 2567 | Зарегистр. 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
Формулировка "можно" навевает на мысли о том, что очень многое можно сделать... вопрос - нужно ли тратить на это время? у меня лично все заказчики хотят, чтобы быстро и качественно. Если такой движок написан и отлажен (как правило, речь о команде разработчиков), то конечно, буду его использовать. Но писать движок, чтобы вынести формы на сервер (причем заказчик этот подвиг не только оценит и не заплатит, но даже и не заметит) - искусство ради искусства...

Всего записей: 2567 | Зарегистр. 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
Открыть новую тему     Написать ответ в эту тему

Страницы: 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