• B правой части каждого сообщения есть стрелки и . Не стесняйтесь оценивать ответы. Чтобы автору вопроса закрыть свой тикет, надо выбрать лучший ответ. Просто нажмите значок в правой части сообщения.

Delphi + Excel

  • Автор темы GriffinSC
  • Дата начала
Статус
Закрыто для дальнейших ответов.
G

GriffinSC

Здравствуйте!
Я начинаю только писать на D7. Первая моя задача такова: Есть Excel файл 97-2003 мне в нём забита инфа с A1 до J18. В первой строке наименования столбцов, в каждой строке инфа об одном человеке. Мне необходимо просматривать каждого человека по-очереди и если необходимо изменять одно из этих полей. Допустим ячейку из столбца I.
Т.к. не имею инфы о всех компонентах попытался в поле мемо что-то выгрузить, но D7 сразу ругнулся на несоответствие типов.
Помогите пожалуйста.
Код:
unit Unit1;

interface

uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, ComObj, StdCtrls, Buttons;

type
TForm1 = class(TForm)
btnClose: TBitBtn;
mmo1: TMemo;
procedure FormCreate(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;

var
Excel: Variant;
Form1: TForm1;

implementation

{$R *.dfm}


procedure TForm1.FormCreate(Sender: TObject);
begin
Excel:=CreateOleObject('Excel.Application');
Excel.Workbooks.open['F:\Delphi\Projects\Excel\1.xls'];
Excel.visible:=False;
mmo1:=Excel.Range['A5:J5'];
Excel.ActiveWorkbook.Close;
Excel.Application.Quit;
end;

end.
 
G

GriffinSC

Пойду искать что такое АДО... А то до этого встречал получается только ОЛЕ.
 
B

BVS

А ведь действительно несоответствие типа :).
Почитай пожалуйста инфу по работе с TMemo.
А насчет Excel.Range['A5:J5'] уж лучше Range['A1'].Value (если конечно у тебя ячейки не объедены).
Насчет ADO почитать не вредно. Однако с Ole понятней и к тому же если редактировать книгу с помощью Excel-я доступ через Ado может и пропасть :-(. ADO хорошо когда надо создать побыстрому книгу и скинуть в нее таблицы.
 
B

BVS

С какого перепугу? И почему при оле не пропадает?
ADO работает с книгой как с базой данных. Иногда при сохранении книги меняется структура листа и к нему становиться невозможно обратиться как к таблице. (По крайней мере в 2003 офисе это точно было, в 2007 может и исправили (хотя я сомневаюсь: все таки excel дает гораздо больше возможности чем просто таблица в БД, и соответственно обычных методов работы с таблицами через SQL запросов для него недостаточно).
А почему при OLE должно пропадать? Ведь OLE использует специальные интерфейсы для работы с excel`ем. И его функциональности вполне достаточно для полной работы с excel`ем (а не только на уровне БД).
Опять таки доступ к полю при адо осуществляется по имени этого самого поля (т.е. датасетю.ФилдБайНэйм('Имя'))
С какой это стати?
Доступ через ADO идет только через SQL запросы, а датасетю.ФилдБайНэйм('Имя'), это всего лишь компонента которая в конечно счете все твои действия с БД переводить на SQL запросы. А как ты осуществишь SQL запрос к объеденным ячейкам (а если объедены и строки)?
 
B

BVS

Что такое иногда? Не встречал.

А я к сожалению встречал. Стоило нажать на кнопку сохранить в 2003 excele и все... Доступа через ADO нет :(


Это уже запрос объеденных ячеек (т.е. из заданной задачки можно предположить: что они есть).

И это +, тут и компоненты есть, а при оле все руками.

TExcelApplication - тоже есть компонента.

Но автор сам в задачке выбрал OLE. И в место того чтобы подсказать ты его запутываешь каким то ADO (может он впервые еще сталкивается с SQL). Да к тому же еще не зная подойдет ли его файлик (а судя из задачки он у него уже есть) для подключения через ADO.


В этом то ит мощь. Зачем мне тыкатся по листу если я написал select * from t where name like '%' и все, как в сказке.
Действительно сказка - при отсутствующем подключении.

Его там даже много чем требуется, в том то и вопрос а нафига? можно проще и эфективнее.
Сдесь полностью согласен: вносить данные в новую книгу очень удобно и быстро. А вот извлекать запаришься - особенно если пользователь что то изменил в книге (для этих случаев существуют БД и СУБД (excel к ним не относиться)).

Мы не рассматриваем excel, мы смотрим только как работать с данными.
которые находятся в excele (как не рассматривая оного этого добиться) ;)
 
B

BVS

АДО вот и не надо думать что там за ексель.
А может OLE DB (Зачем мелочиться).

Судя по этой строчке автор не знает как обращаться с TMemo. А ты его хочешь приобщить к SQL.

битву экстрасенсов

Я пользуюсь своим опытом, а вот ты кажется точно телепатией обладаешь - раз уверен в своей ADO по отношению к формату которой даже БД не является.
 
B

BVS

Всеже по ссылке то сходите.
Вижу что мы с тобой разговариваем на разных языках. У нас с тобой разный уровень (опыт) в программировании.
Зря только сходил на этот скудный источник информации.
Я прекрасно знаю что ADO это всего лишь надстройка для OLE DB (поэтому и написал зачем мелочиться).
Хвать относиться к вопросам как к лабораторным (так никогда не напишешь полностью рабочую версию программы). Надо все таки рассматривать все возможные аспекты и предполагаемые трудности. А то что пользователь прекрасно умеет править Excel файлы всем известно.
Тут надо смотреть как "жали".
Как ты думаешь они (пользователи) нажимают эту кнопку?
 
B

BVS

Ну так и чего вы хотите? А они сам файл удаляют? соединение тоже теряется? оч. интересно...
Они из тьмы редактирования и сохранения действительно могут один раз удалить файл. Но вот сохранение обычная процедура поэтому ее как раз надо рассмотреть (и вам уважаемыйsax_ol тоже).

везде доводить до полной универсальности - тупиковый путь.
Видно кто то привык на лабораторных "дурить" преподавателей (сдавая программы которые могут работать только при определенных условиях). А потом пользователи ваши программ начинают повсеместно вспоминать Била Гейтся и глючную винду :).

Замечу что тема называется [Delphi + Excel], а не [ADO+ Excel] .
 
B

BVS

При чем тут процедура сохранения к конекшену?
если редактировать книгу с помощью Excel-я доступ через Ado может и пропасть :-(
А сохранение как раз и завершает редактирование.

АДО это одна из технологий которую поддерживает делфи, ну и она умеет работать с Excel. Опять таки про что вы?
ADO работает с книгой как с базой данных. Иногда при сохранении книги меняется структура листа и к нему становиться невозможно обратиться как к таблице. (По крайней мере в 2003 офисе это точно было, в 2007 может и исправили (хотя я сомневаюсь: все таки excel дает гораздо больше возможности чем просто таблица в БД, и соответственно обычных методов работы с таблицами через SQL запросов для него недостаточно).
Добавлено: Про Била нашего Гейтса тоже не понятно к чему. При чем тут лабораторные, при чем тут дурить. вощем какойто поток сознания.
А затем что пользователь вашей чудо программы которая считывает данные с excel листа посредством SQL запросов в один прекрасный день (когда пользователь наплюя на вашу программулину отредактирует этот файл в офисе (на что он имеет полное право)и сохраня изменения) выдаст что доступ к файлу (который продолжает нормально читаться в офисе) невозможен. Интересно что он в этот момент подумает, будет делать, что и кого вспоминать, и какие инструкции разработчик данного продукта ему даст?

так сразу отбросить АДО? кошмар...
ADO хорошо когда надо создать побыстрому книгу и скинуть в нее таблицы.


Насчет ссылки на темы я имел ввиду что для автора желательно рассмотреть все возможные способы работы с Excelем а не только с ado.

PS: Преимущество ADO над OLE ты так еще и не показал. :-(. И к тому же заставляешь меня повторяться - что говорит о невнимательности (мне достаточно уже отвечать своими же цитатами).
Преимущество же OLE над ADO (в рамках Excelя) я уже показывал
Ведь OLE использует специальные интерфейсы для работы с excel`ем. И его функциональности вполне достаточно для полной работы с excel`ем (а не только на уровне БД).
И вы с этим согласились
Цитата:

(BVS @ 19:11:2010 - 07:18) *



И его функциональности вполне достаточно для полной работы с excel`ем (а не только на уровне БД).


Его там даже много чем требуется


А некоторые фразы мне вообще не понятны
Мы не рассматриваем excel, мы смотрим только как работать с данными.
-как она соотноситься с данной темой?
везде доводить до полной универсальности - тупиковый путь.
- тупик может образоваться если использовать ADO и excel, а Ole - выход из этого тупика. Только некоторые его и видеть не хотят.
 
B

BVS

в один момент могут вдруг взять и открыть базу в любом соотв. редакторе, отредактировать, сохранить и потом наморщить лоб и с изумлением спрашивать у разработчиков - "а какого собственно все перестало работать?".
Если открыть БД в соответствующем редакторе (и именно в соответствующем для данной БД) то все будет работать как и прежде. Вопросы же взаимосвязоности таблиц (который может нарушить редактор) я не рассматриваю т.к. для этого обычно используется СУБД с определенным доступом к файлам с данными, и к этим файлам трудно добраться (если ты конечно не системный администратор на сервере, но с них спрос совсем другой).
Что касается Excelя то для него соответствующий редактор это офис.

Если пользователь полез туда куда не следует то это его личная проблемма и к проблеммам разработки не имеет никакого отношения.
Отредактировать xls файл в офисе никак нельзя назвать "не следует". К тому же этот файл уже есть (следует из задачи) интересно откуда он взялся :facepalm:. Отсранение от проблемы путем фразы "проблеммам разработки не имеет никакого отношения." характеризует программиста в глазах у клиента не очень хорошо.

В данном случае, имея ту информацию, которую имеем, я считаю что это АДО. С адо я это решу в пол дня, с оле раза в 2 дольше. Просто тупо на писанину.
Мне хватило пол часа (и то только потому что давно не работал с Ole) на написание этого кода:
Код:
unit Unit1;

interface

uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, ComObj, StdCtrls, Buttons, Mask;

type
TForm1 = class(TForm)
mmo1: TMemo;
Button1: TButton;
Button2: TButton;
Button3: TButton;
meStroka: TMaskEdit; //номер редактируемой строки
procedure FormCreate(Sender: TObject);
procedure Button1Click(Sender: TObject);
procedure Button3Click(Sender: TObject);
procedure Button2Click(Sender: TObject);
private
{ Private declarations }
procedure GetStroka(i: integer);
procedure SetStroka(i: integer);
public
{ Public declarations }
Excel: Variant;
sh, w: Variant;
end;

var
Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.FormCreate(Sender: TObject);
begin
Excel:=CreateOleObject('Excel.Application');
w:= Excel.Workbooks.open['d:\temp\1.xls'];
Excel.visible:= true;
sh:= w.sheets[1];

end;

procedure TForm1.GetStroka(i: integer);
var
j: integer;
begin
with mmo1.Lines do begin
BeginUpdate;
Clear;
for j:= 1 to 10 do
Add(VarToStr(sh.Cells[i, j]));
EndUpdate;
end;

end;

procedure TForm1.SetStroka(i: integer);
var
j: integer;
s: string;
begin

with mmo1.Lines do begin
for j:= 1 to 10 do
sh.Cells[i, j]:= Strings[j-1];
end;

end;

procedure TForm1.Button1Click(Sender: TObject);
begin //чтение инф. с xls файла
GetStroka(StrToInt(meStroka.Text));
end;

procedure TForm1.Button3Click(Sender: TObject);
begin //Закрытие xls файла
Excel.ActiveWorkbook.Close;
Excel.Application.Quit;

end;

procedure TForm1.Button2Click(Sender: TObject);
begin	//Для внесения отредактированной инф в xsl файл.
SetStroka(StrToInt(meStroka.Text));
end;

end.
При этом я решил след. задачи:
Мне необходимо просматривать каждого человека по-очереди
если необходимо изменять одно из этих полей
попытался в поле мемо

Плюс адо мне дает тучу возможноствей запростотак, это и поис и быстрое позиционирование на нужные данные, и унифицированный интерфейс пользователя, использование транзакций, и тыпы
- А зачем (разве автор собрался писать БД)
Есть Excel файл 97-2003 мне в нём забита инфа с A1 до J18
- всего то 18 строк.
 
B

BVS

С какого перепугу? можно не только данные, можно и структуру похерить, да что там структура, данные тоже не абы как туда занесены. Так что мимо.
читаете не внимательно (может хватит).
Вопросы же взаимосвязоности таблиц (который может нарушить редактор) я не рассматриваю т.к. для этого обычно используется СУБД с определенным доступом к файлам с данными, и к этим файлам трудно добраться (если ты конечно не системный администратор на сервере, но с них спрос совсем другой).
Для тех кто в танке объясню на примере. Для БД в формате mdb существует специализированный редактор под названием Microsoft Access, как вы думает что будет с этим файлом если его там отредактировать. А какая ситуация с xls?
Как раз таки оно и есть. Человек вмешивается в логику программы. А тут уж как повезет. если он с пониманием, то никаких потерь если без мозгов то это засада. Не важно каой это файл офиса или еще чего, вот к примеру ини файлы, xml файлы и т.п. легко можно редактировать блокнотом, но а там как повезет.
Что было раньше "курица или яйцо"? В нашем случае файл появился раньше программы (и наша задача написать программу для этого файла (а никак не наоборот). А если структура файла нам не подойдет? Что поотрывать руки заказчику? А если у заказчика нет мозгов - то пусть платит больше подберем любой вариант (даже самый трудоемкий). Мне интересно xml файлы вы тоже через ado запускаете? Я лично предпочитаю пользоваться парсерами ;). Особенно мне интересно как ini файла с ado сочетаются?.
И что оно делает? на такое с адо ваще ничего писать не надо и делать при этом будет гораздо больше, нежели то что вы перечислили. андерстенд? smile.gif
Я уже отвечал что она делает :) Будте внимательней. То что с ado писать ничего не надо я заметил - ведь вашего варианта еще не было :)

А не все ли равно? хоть с луны, еще раз, что это меняет?
Скоко раз напоминать прописную истину что EXCEL может хранить таблицы БД но необязательно в виде таблицы БД, т.е. он не относится к формату БД и поэтому к нему не всегда можно обратиться через SQL (разве это для ADO нечиго не меняет?)

Вот мы лет эдак 6+ назад делали систему, которая закачивала данные из филиалов в консолидированную бд. ДАнные шли разного формата, и эксель и пдф и csv и ... так вот всем были спущены указания как формировать эти самые данные, по вашей логике, всяк мог накосячить чего угодно, а мы должны угадать чего накосячили?
-несколько форматов + можно предугадать что есть и множество вариантов одного формата. Т. е. совсем другой уровень сложность чем то что запросил автор (существует один вариант (к сожалению незвестный) одного известного формата (excel)). В твоем случае однозначно приводит к одному стандарту и никаких отклонений от оного. В случае с автором тратить время на разработку стандартов и инструкций к ним - просто глупо.


Ешкин кот... ужеж говорили, атору надо работать с данными
- это ты говоришь. А автор попросил помочь ему разобраться как работать с Excelем через delphi. Будь пожалуйста повнимательней и обращай внимание хотябы на название темы.


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

фигачте чыста по формату
-бессмысленный подход. Например: у клиента поменяется версия офиса, а вместе с ней и формат файла. Если для Ole это будет по боку то для самостоятельного разбора файла придется переписывать программу (а для этого придется изучить еще и новую структуру xls файла).
доводить до полной универсальности - тупиковый путь
универсальности нет предела. оле и не снилось.
Уважаемый Вас не понять. (Вы уже не помните что и сами писали :) ).
 
B

BVS

Да плевать на файлы
Достойный ответ на поставленную задачу.

Прицепились к офису шмофису. да чхать на офисы
Еще раз как называется тема?. Или excel у Вас вышел из состава этого продукта?

Важно что есть логика программы и вмешиватся туда пользователь не имеет право
логики программы (так как программа еще не написана) еще у автора нет, а вот вмешиваться уже есть куда ;). И как это можно объяснить?

устал реально... smile.gif
я тоже :)

слово эффективно вам что нить говорит
ваш код в студию (посмотрю насколько он эффективный)

форматы, РАЗНЫЕ, но четко формализованные
я не говорил что формат один. (Внимательность) Я сказал что стандарт один. А форматов подчеркивал что несколько. (Хотя для Вас это наверно одно и тоже :).

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

автор просит

Цитата:

(Роман1Сергеевич @ 18:11:2010 - 11:30) *



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


, и далее
Цитата:

(sax_ol @ 18:11:2010 - 11:44) *



А то до этого встречал получается только ОЛЕ.


, для тех кто на танке - автор говорит лишь о том что он не знает как и находил только с оле. Все больше переводчиком не буду.
ado выбирает сразу все строки заданные в SQL запросе, а автор просить пройтись (остановившись на каждой (т. е. выбрав человека)) по строкам (Ole это позволяет). Или предлагаеш на каждую строку (человека) писать отдельный запрос?

Она ваще нихрена не делает
Уважаемый не умеет читать код?

В топике автор указал чего там есть а чего нет, про то что что то меняется ничего не сказанно. Еще раз спрашиваю, у вас с авторам астрал?
Автор указывал форматы хранения данных, как они расположены (по центру ячейки, справа, слева), какого шрифта; какова разметка листа. Какой у него вид? и многое другое. Был бы астрал было гораздо проще :(

Или вы настолько внимательный что не всем доступно?
судя по вашим ответам да.

Да неужели? вы ваще с офисным оле дело то имели?
имел. И могу смело утверждать что Excel.Application будет работать со всеми версиями микрософт офиса
Да плевать что там может быть, хоть сферический конь.
Вам - да. ADO - нет :). Что и пытаюсь вам многоуважаемый доказать.
 
B

BVS

Ну хорошо, если так уж не в терпеж, делайте следующее, открываете делфи, новый проект, на форму бросаете:
TADOConnection, TADOTable, TDBDataGrid, TDBNavigator, TDataSource
Вижу что мне здесь больше делать нечего. Задача в рамках которые указал автор - Вами не решена. Я в Экселе проще смогу обработать данные. Зачем мне еще писать программу которая будет выводить табличку :).
Автор же просил хотябы использовать tmemo. А где выбор по Человеку?

без комментариев...
А зря. Назови хотя бы одну версию офиса где он не заработает?

Где он указывал про центры?
Прошу у Вас многоуважаемый прощение - забыл поставить знак "?". Именно что автор вскользь прошелся по файлику.


даже видеть не хочу
тем более в нем разбираться. Теперь мне Ваша невнимательность понятна. Насчет русского языка я лучше промолчу :)
 
B

BVS

Любая, тут не от офиса зависит а от версии сом-а
- Вот именно. А версии COMа ставиться вместе с офисом. И соответственно какое дело Excel.Application становиться до версии (ведь в любом случае будет стоять нужная). Или Вы многоуважаемый плохо понимаете принцип работы OLE.
Это вы про свой код
- нет это я про редактор :)
Что до моего кода то это набросок (притом польностью удовл. автора в рамках его задачи (будем надеется что он правильно ее написал))

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

В чем разбираться? одного этого:
Цитата:

(BVS @ 22:11:2010 - 08:46) *



Excel.visible:= true;


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

BVS

все - оле... оле оле оле. smile.gif
Учи принципы работы с COM объектами. От перстановки офиса программу переписывать не нужно. Хотя пока Многоуважаемый не узнает как работают COM объекты он про это и знать не будет. :)

10 там колонок или нет
- у автора 10 внимательно прочитайте задачу :).

а с адо мне в принципе может быть фиалетово
я это заметил :(. (ты все еще не ответил к xml и ini файлам тоже обращаеся через ADO?).

и будет у вас строго по очереди
- автору это скажи (задачу он иначе ставил) :(.

Открываешь в редакторе - тоже грид только писать ничего не надо и функциональности поболее :(.
 
G

GriffinSC

Ничего себе вы тут расписали :fuckyou:
Я в четверг начал делать через АДО, пока что-то получается. Почему так долго? - спросите вы. Потому как тяжело дается (SQL чтобы вспомнить что такое пришлось конспект перечиты :( Как упрусь во что-либо покажу что не получается. Вот что у меня на данный момент:
Код:
unit Unit1;

interface

uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, DB, ADODB, Grids, DBGrids, StdCtrls;

type
TForm1 = class(TForm)
DataSource1: TDataSource;
DBGrid1: TDBGrid;
ADOConnection1: TADOConnection;
ADOQuery1: TADOQuery;
Button1: TButton;
Button2: TButton;
Button3: TButton;
procedure FormCreate(Sender: TObject);
procedure Button1Click(Sender: TObject);
procedure DBGrid1CellClick(Column: TColumn);
procedure Button3Click(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;

var
Form1: TForm1;
id_count,id:integer;

implementation

{$R *.dfm}

procedure TForm1.FormCreate(Sender: TObject);
begin
try
id:=1;
ADOQuery1.SQL.Clear;
ADOQuery1.SQL.Add('SELECT * FROM [Лист1$]');
ADOQuery1.Active:=True;
id_count:=ADOQuery1.RecordCount+1;
except
on e:Exception do
end;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
try
ADOQuery1.SQL.Clear;
ADOQuery1.SQL.Add('INSERT INTO [Лист1$] (ФИО,Адрес,id) VALUES(''Иванов Иван Иванович'',5,'+IntToStr(id_count)+')');
id_count:=id_count+1;
ADOQuery1.ExecSQL;
ADOQuery1.SQL.Clear;
ADOQuery1.SQL.Add('SELECT * FROM [Лист1$]');
ADOQuery1.Active:=True;
except
on e:Exception do
end;
end;

procedure TForm1.DBGrid1CellClick(Column: TColumn);
begin
id:=ADOQuery1.Fields.Fields[1].AsInteger;
end;

procedure TForm1.Button3Click(Sender: TObject);
begin
try
ADOQuery1.SQL.Clear;
ADOQuery1.SQL.Add('SELECT * FROM [Лист1$] WHERE ФИО LIKE ''%Иванов%''');
ADOQuery1.Active:=True;
except
on e:Exception do
end;
end;

end.
 
Статус
Закрыто для дальнейших ответов.
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!