» Вопросы по Delphi

vserd
ExactRecordCount показывает правильно, в отличие от RecordCount, но медленно.
Вот отрывок из хелпа: "Используйте свойство ExactRecordCount для определения точного количества записей в текущем наборе данных. Оно включает в себя количество удаленных, отфильтрованных и индексированных записей. Этим оно отличается от свойства RecordCount, которое всегда дает существующую верхнею границу. Заметим, что данное свойство требует сканирования полного набора данных, в то время как свойство RecordCount это просто расчет"

Но вообще то мне это уже не нужно, так как TDBF я заменил на Halcyon. Скорость возрасла в разы! Вот мой пост в соседней ветке: "Ура !!! Кажется решилась трабла по поводу медленной работы с базами dbase с TDBF.
Заменил я этот TDBF на Halcyon.
Результат:
TDBF 6.4.7. пробегает по 185 моим базам с кол-вом записей от 0 до 200 000, с фильтрацией и выборкой нужных строк на локальном компе примерно за 1м 20сек. Если базы на серваке (а сервак мееедленный!!!) ~ за 18мин. Все это без использования индексов.

Halcyon 696 (с русской адаптацией от Кирилла Водоносова) делает тоже самое за 50сек на локале и примерно за 3мин. 10сек на сервере!!!! Нехилый такой прирост производительности!"

reenoip

Цитата:

Нужно сделать локализацию приложения на другой язык, который не поддерживается D6 в принципе. В качестве решения проблемы советуют перейти на D8.NET. Мне лично от технологии .NET ничего не нужно (приложение практически готово), но вот из-за проблемы с кодировками придётся, по ходу, портировать весь написанный и отлаженный материал на D8.NET.

Мне это вообще не понятно. Почему именно надо перейти на дот нет для локализации?
Это не правда. Всего лиш надо перейти на версиюю Д которая потдерживает юникод, насколько мне известно Д2005,2006 его нормально потдерживают. А помоему и 7 его держит.
То есть вам всего лиш надо иметь фаилы текстовых ресурсов в юникоде для разных языков и при загрузке проставлять соотв каптионы и т.д. всем контролам из этого фаила.
Мое мнение вам надо перейти на Д2006 (вин32), ибо она на мой взгляд лучшая на данный момент. Там можно вырезать весь дот нет и остальную не нужную функциональность (как у меня) и тогда она работает не хуже 7 и даже быстрее в некоторых местах.
Д8 это полный сакс, 2005 тоже. Даже не думайте на них переходить.

vshersh

Цитата:

Напиши прямо в твоем файле, где описан логгер

А как сделать, чтобы этот модуль освобождался последним?

ArtemiyUO
RomanTim
Спасибо за инфу. Сегодня уже, если найду на прилавках D2006, буду ставить/переносить проект. Надеюсь, геморроя будет мало...

ArtemiyUO

Цитата:

Мне это вообще не понятно. Почему именно надо перейти на дот нет для локализации?

В общем, D7 как вариант тоже не подходит, поэтому я и сорвался сразу за более старшими версиями. Два года вообще не открывал Delphi, просто несколько потерялся среди обилия версий, а решение по выбору нужно надо было принять срочно
Кстати, да, текстовик сделать можно, НО - даже сами окна не позволяют мне писать на этом языке, только офисный пакет, а в формате *.doc хранить языки... Я понимаю ещё *.ini, *.lng - куда ни шло, но чтобы так... И вообще, я пока сторонник того, когда всё в одном файле (сказывается наличие отсутствия опыта), ибо юзер руками своими иногда просто удаляет "ненужное", а у меня заказ серьёзный (для моего уровня), мне нужно полностью исключить "лишние" файлы на диске, либо юзер исключит их сам )))))))
Глупость, конечно... Шучу.

Ладно, всем ещё раз спасибо, извиняюсь за offtop...

whitewolfs
А Advantage DE не хочешь попробовать? Эти ребятки еще и что-то околосерверное склепали, т.е. разбираются в БД получше, чем Griffin Solutions. Заодно поддержку SQL получишь, а это может еще в разы поднять скорость.

evle
Для этого необходимо его инициализировать первым.
По идее, если его заюзать в файле проекта первым и он не будет юзать других юнитов проекта, то он будет инициализироваться первым, а финализироваться последним.

Выдержка из ртфм:

Код: 1. For units in the interface uses list, the initialization sections of units used by a client are executed in the order in which the units appear in the client's uses clause.
2.Finalization sections are executed in the opposite order from initializations. For example, if your application initializes units A, B, and C, in that order, it will finalize them in the order C, B, and A.

SergeBS
Да я не против попробовать . Вот только бы раздобыть полную версию Advantage Database Server, да подешевле!

evle
vshersh
Чтобы не открывать/закрывать файл каждый раз после записи строчки можно делать
Flush

whitewolfs
А зачем? Однопользовательские движки они бесплатно отдают на сайте. Это и есть Advantage Database Engine (не путать с Advantage Database Server).

RomanTim

Цитата:

Можно попробовать так (если считать, что строки и столбцы нумеруются с 0)

Код:
DBGrid.DataSource.DataSet.RecNo := Row+1;
str := DBGrid.Columns[Col].Field.AsString;

Спасибо, помогло!

Короче, полный финиш... D2006 в моём городе ещё не продают. Более того, во всех точках о ней ещё даже не слышали (!!!), и говорят, что ожидают (!!!) версию 2005 - дескать, "самую последнюю". Не спрашивайте даже, где живу. Условно назовём это Маленьким Городом Больших Тормозов.
Отсюда вытекает крайняя мера: где можно скачать наиболее полную версию Delphi2006 (мне всякие навороты не нужны; главное - чтобы ADO и win32 были)? Размер (чего уж теперь мелочиться) значения не имеет. Если здесь нельзя постить линки, то будьте добры, на pioneer@mail.kz, или в личку. Сразу скажу, что в Сети уже искал самостоятельно - результат нулевой, увы.
Спасибо.

p.s
Поставил только что D8. Хоть краем глаза посмотреть, чего я пропустил...

reenoip
сюда сходи... недавно как раз об этом речь шла...

Люди, подскажите, куда копать... задача: есть класс, с полями и наследником TObjectList внутри... нужно как-то его со всем этим гамузом сохранить в blob поле базы, а потом вычитать... т.е. подобие того, как делфи сохраняет данные в dfm, тока пишем в базу...

Glukodel
Обрати внимание на класс TPropsStorage из RX. Он как раз занимается сохранением пропертей для некоторого объекта. Объект должен быть наследником TPersistent'а и свойства, которые собираешься сохранять должны быть published.

reenoip
урл была тут
и еще можно сходить сюда

Ребята покажите пожалуйста как с помощью TSAXXMLReader прочитать ХМЛ фаил. Ну или есть какойнибудь компоненты простой. Те что я находил во первых старые, а во вторых не разобрался до конца как работают, вообщем мне не понравились.
Мне надо пробежать по ХМЛ фаилу и загрузить данные в свою структуру.
Искал примеры и на сайте и гуглом не нашел не одного.
Нужен имменно сах парсер потому что нужна скорость и мало памяти. Файлы огромные, ДОМ парсер жрет 500 мб рама)

vshersh
посмотрел.... но до этого уже сделал работающий вариант - основной класс наследуется от TComponent, объекты, хранящиеся в TObjectList - тоже... после этого стало возможным
сделать так:
MS := TMemoryStream.Create();
i := flt.InstanceSize;
ms.WriteComponent(flt);
ms.Write(flt.FilterIncl.Count, sizeof(flt.FilterIncl.Count));
for i := 0 to flt.FilterIncl.Count - 1 do
begin
fr := flt.FilterIncl.Records[i];
ms.WriteComponent(fr);
end;
где flt - экземпляр осноного класса, в flt.FilterIncl.Records[i] - экземпляры класса, где есть только поля (текст, инты...) так вот вопрос
при считывании обратно все нормально, когда для последнего класса все поля заполнены... если текстовое поле сохранялось пустым, то при считывании в него попадает предыдущее непустое значение... и так до тех пор, пока не попадется поле со значением... считываю так:
MS := TMemoryStream.Create;
fr := TFilterRec.Create;
ADOQuery1StructData.SaveToStream(ms);
ms.Position := 0;
ms.ReadComponent(filter);
ms.Read(n, sizeof(filter.FilterIncl.Count));
for i := 0 to n - 1 do
begin
ms.ReadComponent(fr); // уже здесь под отладчиком видно, что пустое поле
//содержит значение от предыдущего объекта...
filter.FilterIncl.AddFilterRec(fr); //это запихивание в TObjectList,
//но данные уже не те...
end;
где провтыкал?
P.S. все это пишется и читается в blob поле, но по-моему грабли в работе с потоком...

Glukodel
Может дело в директивах свойств (Storage specifiers)?
Попробуй поставить nodefault

vshersh Спасибо, nodefault посмотрел, о Storage specifiers почитал.... непомогло...
обошел тупо добавляя пробел к зачению строки, а обратно соответственно юзаю trim...
мабуть, похорошему, надо делать полную "сериализацию", используя наследников TCollection и TCollectionItem...........

ArtemiyUO
Посмотри _http://www.simdesign.nl/xml.html

Цитата:

Unique feature: Add XML nodes to a file that exists on disk without reading the complete file! The additional unit XmlAppends will search from the end of the (possibly huge) file on disk and append node data there directly. See Example 4.

Сам не юзал - не знаю. Но говорят штуковина неплохая.
Если хош, могу подсобить с FS (ПМ)

Было бы интересно узнать реальный бенчмарк этих классов на больших объемах

Такая проблема. Я все время программировал на Фортране консольные проги для обработки данных. И вот приперло - надо сделать гуёвую прогу (в смысле с GUI) для интерактивной обработки данных. Как пишут в справке для компиляторов Фортрана, обычный путь - смешанное программирование: вычисления на Фортране, GUI - на С++, Visual Basic, Delphi.

В общем, попробовал я так сделать. C/C++ почему-то у меня вызывает сильнейшую аллергию, Visual Basic - нет, но когда я попытался его осваивать, то понял, что программировать я на этом не буду. Пересел сначала на PowerBasic, но возникли сложности. Вот захотелось мне определенный элемент ActiveX прикрутить для построения графиков, но у PowerBasic с ActiveX большие проблемы. То есть у прог для визуального программирования на PowerBasic таких проблем практически нету, но эти проги не бесплатны и лечилова к ним нет.

А поскольку этот самый ActiveX (DynaPlot3) меня просто потряс своими возможностями (точнее, тем, насколько они совпадают с моими потребностями), подумал я о переходе на Delphi. Фаронова купил. Но вот заковыка: у меня на PowerBasic уже прописана начальная часть проги. И отлажена. А там разные окошки для сбора предварительной инфы, стандартные диалоги открытия обрабатываемых файлов и т.п. С этими диалогами я долго возился, сделал так, что можно использовать два варианта: загружать список обрабатываемых файлов (как у меня было в консольных прогах) или выбирать сами обрабатываемые файлы (много штук) в окне стандартного диалога. Ну и мне не охота это все пускать псу под хвост. PowerBasic позволяет запихать все это в DLL и потом вызвать в виде подпрограммы из какой-нибудь проги, то есть теоретически это можно пустить в дело.

А практически - такая проблема: нужно получить названия файлов (прочитать из списка или получить названия из диалога - не важно). И это я хочу кинуть в DLL, используя уже написанное на PowerBasic. Оформлено это дело у меня как строковый массив, что логично. Размерность этого массива я узнаю только в ходе выполнения подпрограммы. И получается, что я не могу описать этот массив в основной программе, которая вызывает DLL. Во всяком случае, у Фаронова я массивов, которые позволяют с собой работать при неизвестной размерности, не обнаружил. Ну, можно сделать так, как поступает стандартный диалог открытия файлов: прописать все значения в одну строку подряд с какими-нибудь разделителями, и такой вариант прокатит на ура. А нельзя ли все же перекинуть имена файлов через массивы (записи, ...)?

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

Цитата:

А практически - такая проблема: нужно получить названия файлов (прочитать из списка или получить названия из диалога - не важно). И это я хочу кинуть в DLL, используя уже написанное на PowerBasic. Оформлено это дело у меня как строковый массив, что логично. Размерность этого массива я узнаю только в ходе выполнения подпрограммы. И получается, что я не могу описать этот массив в основной программе, которая вызывает DLL. Во всяком случае, у Фаронова я массивов, которые позволяют с собой работать при неизвестной размерности, не обнаружил. Ну, можно сделать так, как поступает

Один ответ - динамические массивы, а именно a:array of type где type - тип массива. В либе реализуй функцию, которая возвращает размерность массива и потом через SetLength(a,lngth) устанавливай его размерность. И далее по хелпу, рахбираться 10 минут. А вообще я бы не мучался с этим, а переписал бы диалог загрузки файлов, ибо лучше день потерять, а потом за час долететь (с) из мультика. Хотя дело хозяйское.

Как я понимаю, динамический массив все же не прокатит. Допустим, я в подпрограмме получил из стандартного диалога открытия файла штук 60 выбранных юзером названий + путь к папке, посчитал, сколько их набралось, сформировал массив нужной размерности и нашинковал их всех туда. Пока я не обратился к подпрограмме, я не знаю, сколько файлов юзер выберет. Может, вообще один. А когда я к ней обращаюсь, я уже в этот момент должен этому динамическому массиву задать размерность. То есть если бы это была обычная подпрограмма, я бы мог к ней обратиться 2 раза, в первый раз узнать число файлов и состряпать массив нужного размера, а во второй раз считать сам массив. Но для этого массив нужно объявить как Static, а для DLL, как я понимаю, это не пройдет. Так что придется передавать строкой.

Ну, случай с чтением списка файлов тривиальный, его можно было бы без проблем переписать, просто на вариант с выбором нескольких файлов я угробил много времени и добился, что все прекрасно работает. А при не очень хорошем знании Delphi опять буду с ним продолжительно кувыркаться.

XPEHOMETP
Сделай передачу списка файлов в виде строки - тогда и вызывать можно не только из делфи, и проблем с менеджерами памяти и тяганием за программой borlandmm.dll не будет.

Опиши в библиотеке глобальную переменную и функцию, возвращающую указатель на нее:

Код: library MyDll;
var
FileList: string;

function GetFileList: PAnsiChar; stdcall;
begin
.....
Result := PAnsiChar(FileList);
end;

exports
GetFileList;

begin
end.

XPEHOMETP

Цитата:

А практически - такая проблема: нужно получить названия файлов (прочитать из списка или получить названия из диалога - не важно). И это я хочу кинуть в DLL, используя уже написанное на PowerBasic. Оформлено это дело у меня как строковый массив, что логично.

Переведи этот массив в строку типа PChar, делай разбор этой строрки уже в DLL.
Почитай по особенностям программирования DLL предназначенных для работы с разными языками программирования.

XPEHOMETP
Tstrings + F1 - то, что тебе нужно. Сколько надо, столько строчек и создашь.
Плюс хинт: максимальная длина названия файла - это константа, характеризующая систему. Названия только не помню .

Спасибо, конечно, только от варианта со строкой я как раз хотел уйти. В общем, это даже проще: кидать на выход строку, полученную из диалога открытия файлов с минимальной подработкой. А вот для варианта с чтением списка файлов - это только лишняя тягомотина. Ладно, этот вариант переписать в основную программу как раз проще всего.

Помогите новичку написать маленькую программку.
Нужно чтобы после выбора пути в OpenDialog в поле Memо записывались имена всех имеющихся в выбранной папке файлов.

С листбоксом:

procedure TForm1.Button1Click(Sender: TObject);
var s:string;
begin
if OPenDialog1.Execute then
begin
s:=ExtractFilePath(OPenDialog1.FileName)+'*.*';
ListBox1.Perform(LB_DIR, DDL_READWRITE {or DDL_DIRECTORY}, Longint(@s[1]));
end;
end;

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