» Вопросы по Ehlib

landy

Цитата:

Непонятно только - в чем смысл такого решения?

Цитата:

{$IFDEF VER140} { Borland Delphi 6.0 or CPP Builder 6.0}
{$DEFINE EH_LIB_5}
{$DEFINE EH_LIB_6}
{$ENDIF}

Здесь говорится, что если компилятор Delphi6, то он поддерживает и компилятор Delphi5. А вот если бы компилятор был Delphi5, то директива для Delphi6 была бы не определена. По традиции компилятор определяет только одну директиву VERXXX - версия текущего компилятора, а о совместимости с предыдущими версиями, компилятор не знает. По этому, все библиотеки компонентов, которые я знаю, - определяют свои директивы типа COMPILER17_UP - означает - компилятор 17 или выше.

А переменная CompilerVersion, которую можно сравнивать на больше/меньше - не для этого разве?

landy

Цитата:

А переменная CompilerVersion, которую можно сравнивать на больше/меньше - не для этого разве?

1) Сравнение переменных директив появилось сравнительно недавно, то есть если вы хотите компилировать в Delphi6 и Delphi7 то эти условные директивы их компилятор не пропустит.
2) ver200 и ver210 мне не говорит, что это XE6 и XE7, трудно бывает все цыфры запомнить.
3) гораздо легче писать ifdef delphiXE6_up, чем везде втыкать условные выражения которые читаются гораздо хуже.
4) ну и просто уже сложилось так.


Цитата:

А переменная CompilerVersion, которую можно сравнивать на больше/меньше - не для этого разве?

Моё мнение - когда она появилась - это мёртвому припарка, спасибо конечно, но уже оно не надо.

Добавлено:
Скорее всего
Цитата:

CompilerVersion

для того чтобы скрывать от непросвящённых детали реализации - это не всем надо.

Цитата:

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

Мне кажется, директивы не понадобятся. Ибо все нужные методы наверняка будут неизменными от версии к версии.

rrromano

Цитата:

Мне кажется, директивы не понадобятся.

Пример. На D2010 у меня старый EhLib, на XE7 новый:

Код: [no]type
TMyDBGridEhStyle = class(TDBGridEhStyle)
...
initialization
{$IFDEF COMPILER17_UP}
SetDBGridEhDefaultStyle(TMyDBGridEhStyle.Create(nil)).Free;
InplaceSearchTimeOut := 77;
{$ELSE}
SetDBGridEhDefaultStyle(TMyDBGridEhStyle.Create).Free;
{$ENDIF}
end.[/no]

Цитата:

Delphi7 DB это только Ansi, я бы уже отказался от любой поддержки Delphi7. Так что пора избавляться от лишних директив

Рано еще отказываться, на 7 версии еще поддерживается огромное количество корпоративного софта.

landy

Цитата:

Рано еще отказываться, на 7 версии еще поддерживается огромное количество корпоративного софта.

Не рано. Если у них используются EhLib пусть даже текущей версии, вот пусть эти компоненты и используют. И пусть не думают об новых компонентах на "гнилом менеджере памяти". У Delphi7 старый менеджер памяти, он не понимает, что у компьютера 2 GB памяти - свободной оперативки 500мб, его просят выделить 3.5мб , вру, его просят выделить 350мб и если он даже выделит, то любых перераспределениях памяти выдаст OutOfMemory, хотя все версии Delphi, которые выше - делают это легко. Дело не в свободной оперативке, всё равно приложение работает с виртуальной памятью, которой гораздо больше. На данный момент Delphi7 самый не безопасный софт для целостности данных, при мягко сказать маленьких, на сегодняшний день объемах - 350мб. В 1997 году моя фотка в BMP со сканнера столько занимала. Ну решил юзер загрузить свою фотку не JPEG а BMP в базу? База стерпит, может просто откажет, а вот софт Delphi7 рухнет. Так что пока Вы провоцируете пользователей ничего не предпринимать и сидеть на рухляти так и будет. А вот BMPшки перегнать в JPEги - это дело программиста, и он может это сделать потом - когда заметит объёмы. Вперёд надо двигаться, сейчас уже пользователи вообще не понимают, что такое 350мб - чих.

Добавлено:
Блин, много букав

Цитата:

Рано еще отказываться, на 7 версии еще поддерживается огромное количество корпоративного софта.

Скажу больше. Про корпоративный софт на Delphi7 знаю не понаслышке. 2 года назад перевёл весь комплекс ПО на Delphi2010. Софт на Delphi7, как правило существует давно, он оброс очень сложными и запутанными техниками, мягко сказать "чуда программистов" техниками, которые работали один за другим на этом ПО. Такой софт как правило очень непредсказуем и пилить его приходится весьма осторожно. Он оброс миллионами мелких хотелок пользователей, а обижать их нельзя. Так представь - буду ли я думать об том, чтобы обновить например EhLib??? Ни за что и никогда! Мне в таком софте абсолютно не нужны новые компоненты. Бывают конечно безрассудные дровосеки, которые сидят на мине и мечтают о том чтобы произошли неожиданности - это их дело и их беда. Факт тот что большинству софта на Delphi7 плевать на новые компоненты....

Цитата:

у них используются EhLib пусть даже текущей версии, вот пусть эти компоненты и используют. И пусть не думают об новых компонентах на "гнилом менеджере памяти". У Delphi7 старый менеджер памяти

На семерку вполне нормально встает FastMM, ограничения по памяти диктуются только 32 бит платформой.

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

landy

Цитата:

На семерку вполне нормально встает FastMM

То есть Вы из "благих" побуждений, безвозмездно и самостоятельно, будете всем клиентам нашей необъятной родины, тем которые на Delphi7, именно Вы будете им пропихивать и устанавливать FastMM? Я думаю многие из них даже не знают что это.


Цитата:

Обновление же версии грида - проблема гораздо меньшая, чем

Это Вы поспорить хотите или знаете о чём говорите? Может Вы мне расскажете как подружить TdxGrid (DevExpress до cxGrid-ов) в гридемоде с FIBPlus? Так я Вам скажу - без знаний нескольких (больше пяти) протектных (в секции protected) методов обоих компонентов это у Вас не получится. Так что при переводе с Delphi7 на Delphi2010 проблем оказалось меньше с затачиванием имеющихся компонентов, а не переделыванием на новые.

Добавлено:
Кстати с удивлением обнаружил в Delphi 2005 TWideStringField так же не работает. Видимо "они" ещё тогда не проснулись от Delphi8 .NET. Так что между Delphi7 и Delphi2005 похоже нет разницы, кроме возможности дополнительно компилировать дотнет.

Цитата:

То есть Вы из "благих" побуждений, безвозмездно и самостоятельно, будете всем клиентам нашей необъятной родины, тем которые на Delphi7, именно Вы будете им пропихивать и устанавливать FastMM? Я думаю многие из них даже не знают что это.

Честно говоря, не понял вопроса. Те, кто испытывал проблемы с родным ММ из семерки - прекрасно знают о FastMM и много лет его используют.

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

Цитата:

Я лишь за то, чтобы совместимость крупных сторонних библиотек с семеркой не отрезали без веских причин.

Ну причина одна и та же. Я тоже пишу компонентики которые до сих пор поддерживают D7. Два дня убил на восстановление этой поддержки - в коде появилось много "морщин" (я так директивы называю), гораздо больше чем от всех остальных Delphi которые выше. Работая с D7 я ощущаю лишь убогость, ни капли ностальгии. Прикрутил я свои TWideStringField, они да позволяют работать - из корректного файла я получаю корректный WideString, но в процессе попадания строки в контролы, где-то Delphi их конвертирует и реальные ценные данные о нестандартных для рус-енгл буквах теряются. Такой софтиной легко похоронить трудом добытые, адекватные данные на отличных языках. (добавлено, кстати Delphi2006 тоже гробит юникод, думаю нормально только начиная с 2010)

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


Цитата:

Честно говоря, не понял вопроса. Те, кто испытывал проблемы с родным ММ из семерки - прекрасно знают о FastMM и много лет его используют.

Ну и наивный Вы человек. На старые проекты нанимают программистов со стажем 1 год. Вы что с луны чтоли? Не обижайтесь, но они не знают никакой FastMM, не знают что такое менеджер памяти, не понимают почему загрузив 350мб, потом освободив память, потом через 5 минут отладки не известно где ловят OutOfMemory. Сомневаюсь что у всех клиентов D7 сейчас сидят программисты хотя бы с 15летним стажем. Не будут они использовать FastMM если Вы не возьмёте на себя обязанность донести им своё решение проблем каменного века. Я так и думал - поспорить хотите, простите за резкость.


Добавлено:
landy
Ещё
1) За что люблю EhLib, - так или иначе использую его протектные методы тоже. Но потом нахожу для EhLib адекватное решение, которое позволяет избавиться от протектных методов.

2) Я добавил в наш комплекс ПО много EhLib гридов, и прикрутил много приятных плюшек. И всегда выкладываю дистрибутив 30-и библиотек компонентов, которые используем. А Вы не думали, что после меня придёт молодой активный программист, который обновит компоненты? А все плюшки слетят - это точно, да и не воспроизведёт он их. С одной стороны будет злорадство, с другой стороны труд то всё равно был загроблен.

Цитата:

Прикрутил я свои TWideStringField, они да позволяют работать - из корректного файла я получаю корректный WideString, но в процессе попадания строки в контролы, где-то Delphi их конвертирует и реальные ценные данные о нестандартных для рус-енгл буквах теряются

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

Добавлено:

Цитата:

На старые проекты нанимают программистов со стажем 1 год. Вы что с луны чтоли? Не обижайтесь, но они не знают никакой FastMM, не знают что такое менеджер памяти

Не уверен, что сейчас "программисты Delphi со стажем 1 год" - массовое явление. Сейчас всем преподают C#...

landy

Цитата:

Не уверен

То-то и оно. В нашей конторе проект стали делать когда ещё D7 не было. А портал делали на веб-сервисах C#. Так что я и то и другое делал, но за всё время нанимали программистов в помощь. Повидал много, уверяю, программисты Delphi со стажем 1 год - массовое явление. Лучший, кого я оценил, когда увидел, что я в файле директив начинаю что-то писать закричал на мена - "нельзя этого делать это они объявили переменные...". У меня был двойной ступор, почему нельзя и как бы этот файл я своими ручками создавал, библиотека просто моя. А если сейчас это лучшие?

Добавлено:
ps
Хочется подытожить. Первый раз когда я решился отказаться от поддержки - это была Delphi3. Это полное убожество. Помню, сколько времени потратил вычищая директивы, в результате получил весьма красивый текст. 2 года назад на работе переехал с D7 на D2010. Заметил что D7 пол года не запускал, а там ещё и компонентов куча. Решил что запускаю на работе последний раз, по этому последний раз сделал поддержку D7. Планирую скоро покинуть D2010. Одному как то скучно говорить гудбай D7, вот за компанию и предлагаю D7 помахать ручкой. Мне всё равно, а "клиентов" с D7 мне жалко, вдруг им кто ни будь новые компоненты начнёт устанавливать. Я понимаю молодое желание идеального мира, но благими намерениями устлана дорога в ад. Ничего положительного в поддержке D7 новыми компонентами я не вижу, только горе нанимателям.

HotTrack Не работает VCL Style Ligth? Как исправить? В остальных vcl style работает но только Light не работает
Заранее благодарен

Приветствую.
Есть старая программа, всё на BDE + Paradox + TTable + Ehlib, D2007.
Открыл, проект нормально компилируется, и даже работает.

Проблема заключается в том, что DBGridEh теперь при сортировке выдаёт исключение:

Цитата:

Exception
TSQLDatasetFeaturesEh can not sort data in dataset in local mode

Проверил в EhLib версии 5 и 7. В более старых версиях Ehlib локальная сортировка работала.

EhLibBDE в USES присутствует.

Переделывать всё не хочется на TQuery или на другую сетку.
Или Ehlib уже не хочет нормально работать с TTable? Автор поломал?

Здравствуйте!
У меня такая проблема: На форме 2 грида с checkbox'ами "Группа товаров" и "Товары", нужно, чтобы при смене статуса чекбокса "группы товаров" менялся статус чекбоксов у товаров этой всей группы. Как можно это организовать так, чтобы это было моментально, при использовании количества записей >2000. Дело в том что у меня сейчас жуткие тормоза.

tarakan19831

Цитата:

Дело в том что у меня сейчас жуткие тормоза.

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

Использую Delphi XE2 + Firebird.
Использую Master - Detail

Код:
procedure TFmTov.DBGridEh1SelectionChanged(Sender: TObject);
begin
DBGridEh2.SelectedRows.SelectAll;
end;

tarakan19831
А если тот запрос, который в DBGridEh2.DataSource.DataSet, выполнить в IBExpert на том же сервере в той же базе в режиме «Execute and fetch all», то сколько времени он (запрос) выполняется?

Цитата:

«Execute and fetch all»

А не подскажете как его выполнить?

Цитата:

А не подскажете как его выполнить?

Shift+F9

Цитата:

Shift+F9

Извените, сразу с просони не понял, что имеется ввиду.
У меня конечно не IB Expert, но на том же сервере в той же базе в режиме «Execute and fetch all» получилось 1,086 сек.

tarakan19831
У вас тормоза потому что вы идете в цикле по мастер-датасету, а в детейл-датасете при этом каждый раз происходит переоткрытие датасета. Соответственно выполняется куча запросов SELECT, UPDATE.
Если хотите сделать быстро - сделайте UPDATE одним отдельным запросом, так же можете одним отдельным запросом вытащить нужные вам ID-шники. 2 больших запроса всяко быстрее выполнятся чем куча мелких.

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

procedure TForm1.drvTest1ReadRecord(DataDriver: TDataDriverEh;
MemTableData: TMemTableDataEh; MemRec: TMemoryRecordEh; var ProviderEOF: Boolean);
begin
MemRec.DataValues['ID', dvvValueEh] := 1;
MemRec.DataValues['State', dvvValueEh] := 'state';
ProviderEOF := (MemRec.HashCode >= 10);
end;

отображаются олько пустые строки

[more] Добрый день. Использую EHLib 8.
На XE5 как-то криво работает Multiselect в DBGridEh.
DBGrid подключен к SQLDirect DataSet. При загрузке данных в DataSet, данные отображаюся нормально, не одна запись не выбрана. Но как только кликаю мышкой на любой ячейке грида сразу выделяется весь грид (визуально ячейки закрашены как выбеленные). Помогите разобратся в чем дело. На Delphi 2007 все работает корректно, и позволяет выделять записи как угодно, параметры грида:

AllowedSelections = [gstRecordBookmarks]

IndicatorOptions = [gioShowRowIndicatorEh]

Options = [dgTitles, dgIndicator, dgColumnResize, dgColLines, dgRowLines, dgTabs, dgAlwaysShowSelection, dgConfirmDelete, dgCancelOnExit, dgMultiSelect]

OptionsEh = [dghFixed3D, dghHighlightFocus, dghClearSelection, dghIncSearch, dghPreferIncSearch, dghRowHighlight, dghDialogFind, dghColumnResize, dghColumnMove, dghExtendVertLines]

Еще такой глюк. Если визуально все строки грида и выделены, то количество выбранных строк все равно = 0: DBGridEh1.SelectedRows.Count = 0



[/more]

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

Цитата:

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

DBGridEh1.RowDetailPanel.Visible := true;

Кто-нибудь встречал реализацию DataDriverEh-a под SDAC от DevArt?

Как сделать так,чтобы в SearchPanel поиск работал не по всему DBGridEh, а только по определённому столбцу?

zealotfan
Можно по столбцу, на котором стоит курсор -
DBGridEh.SearchPanel.SearchScope:=gssCurrentColumnEh