Gran lío con el stringlist y el TstringList

[sac]

Hola gente, tengo un problema que debería ser sencillo de resolver.
estoy trabajando por primera vez con un stringgrid.
Me dijeron que tengo que usar la clase TstringList que es donde se puede usar el loadfromfile y el savetofile ya que el stringgrid no cuenta con esas opciones.
Ahora ¿como hago para abrir desde el Tstringgrid hacia el Stringgrid y guardar desde el Stringgrid al Tstringlist todo con la extension txt? porque yo quiero hacer un XXX.savetofile(savedialog1.filename) o un XXX.loadfromfile(opendialog1.filename) pero no abre ni guarda nada de lo que hago en el stringlist. (XXX sería el Tstringgrid que cree y declaré en el private).

Ojala puedan ayudarme.

[[poliburro]]

Empezado por sac

Me dijeron que tengo que usar la clase TstringList que es donde se puede usar el loadfromfile y el savetofile ya que el stringgrid no cuenta con esas

Pero por supuesto que las tiene incorporadas, aunque el enfoque es más orientado a un arreglo multidimencional.

Un stringgrid posee los miembros Columns y rows que son de tipo TStringGrid.
Cada Rows implemente por consecuenta el método LoadFromFile y SaveToFile.

Saludos,

[*Caro*]

Hola sac, tienes que recorrer todo tu StringGrid e ir almacenando lo que tienes de alguna forma.

Ejemplo:

Código Delphi [-]
var
 i,j      :Integer;
 Linea  : String;
 slFile  : TStringList;
begin
 slFile := TStringList.Create;
 for i:=0 to StringGrid1.RowCount-1 DO
  begin
   Linea:='';
   for j:=0 to StringGrid1.ColCount-1 DO
    begin
     Linea:=Linea+' '+StringGrid1.Cells[i,j];
    end;
    slFile.Add(Linea);
  end;
 slFile.SaveToFile('C:\Archivo.txt');

tu lo mejoras.

Saluditos

[juanelo]

Creo que si lo que quieres es salvar en un archivo de texto y luego recuperarlo en un dbgrid, una buena alternativa y mucho menos liada es hacerlo mediante un ClientDataSet. Este tiene metodos para salvar como XML y para cargar desde XML.

[Neftali [Germán.Estévez]]

En mi página web, en la sección de ejemplos, también tienes uno titulado: "Color y alineación en celdas de un StringGrid"; A parte de lo que comenta el título, tiene el código para leer datos de un fichero de disco; Está con código fuente, así que puedes descargarlo, verlo y probarlo con detalle.

[sac]

Gracias a todos por sus respuestas. Estoy probando con algunas sugerencias que me dieron. Cuando encuentre la respuesta correcta les aviso desde ya gracias de nuevo.

[[poliburro]]

Empezado por juanelo

Creo que si lo que quieres es salvar en un archivo de texto y luego recuperarlo en un dbgrid, una buena alternativa y mucho menos liada es hacerlo mediante un ClientDataSet. Este tiene metodos para salvar como XML y para cargar desde XML.

Esa opción si me gusta, Pero con ADO, por que si mal no recuerdo con el ClientDataSet debes cargar el Xtd o me equivoco?

[juanelo]

Empezado por poliburro

Esa opción si me gusta, Pero con ADO, por que si mal no recuerdo con el ClientDataSet debes cargar el Xtd o me equivoco?

No, el ClientDataSet es indpendiente de la base de datos que uses (de hecho puede ser inclusive XML la fuente de datos). Para usarlo como "contenedor" de datos basta crearle los campos al ClientDataSet y posteriormente en tiempo de ejecucion (se puede en tiempo de diseño) se crea con CreateDataSet, y ya de ahí lo tenemos como un dataset con toda su funcionalidad (insert, delete, update, etc ..). Pero si los datos los obtienes de una fuente de datos como un BD, entonces para eso está el DataSetProvider que es el encargado de "resolver" de donde vienen los datos (y tambien a donde se graban), en pocas palabras, es un capa que te independiza de la fuente de los datos.

[[poliburro]]

Empezado por juanelo

No, el ClientDataSet es indpendiente de la base de datos que uses (de hecho puede ser inclusive XML la fuente de datos). Para usarlo como "contenedor" de datos basta crearle los campos al ClientDataSet y posteriormente en tiempo de ejecucion (se puede en tiempo de diseño) se crea con CreateDataSet, y ya de ahí lo tenemos como un dataset con toda su funcionalidad (insert, delete, update, etc ..). Pero si los datos los obtienes de una fuente de datos como un BD, entonces para eso está el DataSetProvider que es el encargado de "resolver" de donde vienen los datos (y tambien a donde se graban), en pocas palabras, es un capa que te independiza de la fuente de los datos.

Igual que ADO. :P, puedes cargar Xml como un Dataset sin estar conectado necesariamente a una base de datos.

[juanelo]

Empezado por poliburro

Igual que ADO. :P, puedes cargar Xml como un Dataset sin estar conectado necesariamente a una base de datos.

La verdad es que nunca he usado ADO asi que si tu dices que se puede, pues magnifico, otra alternativa.

[[poliburro]]

Empezado por juanelo

La verdad es que nunca he usado ADO asi que si tu dices que se puede, pues magnifico, otra alternativa.

De hecho no solo puedes cargar Xml como Datasets sin conexión, sino que puedes ir más allá, puedes mantener un Dataset devuelto por la base de datos aún despúes de haber cerrado la conexión (Permitiendote ahorrar recursos). Te permite además obtener más de un Dataset a la vez.

Una chulada ADO pues :P.

[juanelo]

Empezado por poliburro

De hecho no solo puedes cargar Xml como Datasets sin conexión, sino que puedes ir más allá, puedes mantener un Dataset devuelto por la base de datos aún despúes de haber cerrado la conexión (Permitiendote ahorrar recursos). Te permite además obtener más de un Dataset a la vez.

Una chulada ADO pues :P.

Se me hace que ADO le copió a MIDAS , además de poder hacer eso que mencionas, los ClientDataSet manejan tipos de campo "especiales" como los agregados, que pueden ser usados para llevar la sumatoria (por ejemplo) de determinada columna, y se van actualizando automaticamente, de hecho pueden ser usados por niveles, es decir, puedes manterner las sumatorias de todos los registros de manera categorizada. Esto sin contar por supuesto con el imprecindible ApplyUpdates, que aplica cambios a la base de datos de manera "atomica". Puedes mantener relaciones mestro detalle y pueden ademas tener campos de tipo DataSet, es decir, dataset anidados. Espectacular.

[[poliburro]]

Empezado por juanelo

Se me hace que ADO le copió a MIDAS , además de poder hacer eso que mencionas, los ClientDataSet manejan tipos de campo "especiales" como los agregados, que pueden ser usados para llevar la sumatoria (por ejemplo) de determinada columna, y se van actualizando automaticamente, de hecho pueden ser usados por niveles, es decir, puedes manterner las sumatorias de todos los registros de manera categorizada. Esto sin contar por supuesto con el imprecindible ApplyUpdates, que aplica cambios a la base de datos de manera "atomica". Puedes mantener relaciones mestro detalle y pueden ademas tener campos de tipo DataSet, es decir, dataset anidados. Espectacular.

jajaja Quién le copió a quien? jajajajja

Exactamente eso puede hacer ADO, Ejemplo, La base de datos te devuelve un Dataset, Lo mantienenes en memoria despúes de cerrar la conexión agregas valores o realizas modificaciones y puedes entonces replicar las operacipones contra la base de datos estableciendo nuevamente la conexión.

Los campos calculados, por supuesto que los soporta ADO, los campos de tipo DAtaset por igual, aunque pierden sentido al poder manejar múltiples datasets sin necesidad de que sean campos. Sino instancias de ADo datasets.

A que origenes puedes conectar ADO?, pues imagina, va desde un csv hasta un Db2 corriendo en AS/400 (Ahora ISeries), pasando por muchos motores como Oracle, Mysql, MsSql, DataFlex, Access, Dbase, FoxPro, PostGress, Interbase, Etc, Incluyendo archivos de tipo Xml, Xls, xlsx.

En fin, cuando de establecer conexión con motores de bases de datos se trata, yo me quedo con ADO. (Para arquitecturas de más de dos capas, pues, dependerá de la tecnología a usar (SOAP, COM, DCOM, COM+, ETC). No me cierro a midas :P)

[juanelo]

Empezado por poliburro

jajaja Quién le copió a quien? jajajajja

Exactamente eso puede hacer ADO, Ejemplo, La base de datos te devuelve un Dataset, Lo mantienenes en memoria despúes de cerrar la conexión agregas valores o realizas modificaciones y puedes entonces replicar las operacipones contra la base de datos estableciendo nuevamente la conexión.

Los campos calculados, por supuesto que los soporta ADO, los campos de tipo DAtaset por igual, aunque pierden sentido al poder manejar múltiples datasets sin necesidad de que sean campos. Sino instancias de ADo datasets.

A que origenes puedes conectar ADO?, pues imagina, va desde un csv hasta un Db2 corriendo en AS/400 (Ahora ISeries), pasando por muchos motores como Oracle, Mysql, MsSql, DataFlex, Access, Dbase, FoxPro, PostGress, Interbase, Etc, Incluyendo archivos de tipo Xml, Xls, xlsx.

En fin, cuando de establecer conexión con motores de bases de datos se trata, yo me quedo con ADO. (Para arquitecturas de más de dos capas, pues, dependerá de la tecnología a usar (SOAP, COM, DCOM, COM+, ETC). No me cierro a midas :P)

No te habrás equivocado y estarás usando MIDAS? ...