Club Delphi  
    FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Principal > Varios
Registrarse FAQ Miembros Calendario Guía de estilo Temas de Hoy

Coloboración Paypal con ClubDelphi

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo 17-08-2008
Forest Forest is offline
Miembro
 
Registrado: may 2007
Posts: 30
Poder: 0
Forest Va por buen camino
Contrastando mi forma de trabajar con el tuto de Caral

Bueno, soy semi-nuevo en Delphi jaja, se oye feo... pero el caso jaja es que estaba leyendo el mini-tutorial de Caral (http://www.clubdelphi.com/foros/showthread.php?t=44763) y descubrí una forma muy distinta de trabajar a la mía, y quisiera que me dijeran cual es mejor.

Primero que nada yo he usado paradox con el database desktop del delphi 6, y Firebird con Interbase Manager Lite con turbo delphi. Digo esto para explicar como me conecté a mi BD en ambos casos.

Con Delphi 6 solo cree el alias, y en el datamodule puse componentes "Ttable" y "Tdatasource".
Con Turbo Delphi batallé un poco más y tuve que crear un ODBC y pegar ademas de los componentes "Ttable" y "Tdatasource" un componente "Tdatabase" que es con la que hice la conexión.

1. Hasta aquí, ¿es mejor esa forma de conexión o es mejor con ADOconnection? ¿qué diferencias o que utilidad tiene ADOconnection?

Luego, yo nunca he usado Querys, de hecho mi conocimiento de SQL es bastante básico, si no es que menos que eso.
Mi forma de guardar en la base de datos es algo así:
Código Delphi [-]
Datamodule.Tabla.Insert //o .Edit según se requiera insertar o editar el registro
Datamodule.TablaCampo1.value:= Edit1.text;
Datamodule.TablaCampo2.value:= Edit2.text;
Datamodule.Tabla.Post;


A diferencia de en el tuto de Caral en el que se hace referencia a los campos (o eso creo) de la siguiente forma:

Tabla.Fields[numero].Tipo¿? ... la verdad no se, no conozco estos comandos. No se si alguien me pueda aclarar por qué se hace referencia a los campos de esa forma.
Y otra cosa, cuando yo comencé me dijeron que no usara los DBEdit y DBLabel, no se por qué, pero me lo dijo alguien con más experiencia y le hice caso, y es por eso que trabajo de esa manera en vez de accesar directamente a la BD.

Igual para mostrar algún registro primero lo localizo utilizando:
Código Delphi [-]
DataModule.Tabla.FindKey([valor])

y después hago lo inverso a lo que describí arriba:
Código Delphi [-]
Edit1.text:= Datamodule.TablaCampo1.value;
Edit2.text:= Datamodule.TablaCampo2.value;
2. ¿Tiene alguien idea de que de malo pueda tener usar los DBEdit o DBLabel? ¿se puede corromper la BD por un mal uso de estos o algo así?

3. Creen que se pueda combinar el estilo que yo uso con este otro para lo que son las Querys por ejemplo, ya que los ADOQuerys que veo en ese tutorial ahorran mucho trabajo (que yo hacía usando ciclos y cosas así x_X)



PD. Como un extra, y que tal vez debí postear en el tema del tutorial, alguien sería tan amable de explicarme detalladamente esta query?:
Código SQL [-]
SELECT DISTINCTROW Sum([Banco].[Depósitos]) AS [Suma De Depósitos]
FROM Banco;
que es DistinctRow?
Sum es un método para sumar todos los registros en el que se pone [Tabla].[Campo] ???
en la parte:
Código SQL [-]
AS [Suma De Depósitos]

Suma De Depósitos, qué es? una variable? un especie de nombre?
...

Bueno, espero me puedan ayudar a sacar esas dudas. Gracias.
Responder Con Cita
  #2  
Antiguo 17-08-2008
[coso] coso is offline
Miembro Premium
 
Registrado: may 2008
Ubicación: Girona
Posts: 1.678
Poder: 0
coso Va por buen camino
Hola,
1.- Adoconnection se conecta a bases de datos usando tansolo connectionstring, y pudiendose cambiar esta en tiempo de ejecución.

Código Delphi [-]
function Tdm.ConnectString(s : string) : string;
begin
     ConnectString := 'Provider=Microsoft.Jet.OLEDB.4.0;' +   // creem una conection sring standard
          'Password="";User ID=Admin;Data Source=' + s + ';' +
          'Mode=Share Deny None;Extended Properties="";' +
          'Jet OLEDB: System database="";' +
          'Jet OLEDB: Registry Path="";' +
          'Jet OLEDB: Database Password="";' +
          'Jet OLEDB: Engine Type=5;' +
          'Jet OLEDB: Database Locking Mode=1;' +
          'Jet OLEDB: Global Partial Bulk Ops=2;' +
          'Jet OLEDB: Global Bulk Transactions=1;' +
          'Jet OLEDB: New Database Password="";' +
          'Jet OLEDB: Create System Database=False;' +
          'Jet OLEDB: Encrypt Database=False;' +
          'Jet OLEDB: Don''t Copy Locale on Compact=False;' +
          'Jet OLEDB: Compact Without Replica Repair=False;' +
          'Jet OLEDB: SFP=False';
end;

...

ADOConnection1.ConnectionString := Connectstring('Mi archivo.mdb');
ADOConnection1.Connected := true;

lo que significa que te olvidas de los alias y del ODBC

Cita:
Edit2.text:= Datamodule.TablaCampo2.value;
yo lo haria como

Cita:
Edit2.Text := Datamodule.Tabla.FieldByName('CAMPO2').Asstring;
2. ¿Tiene alguien idea de que de malo pueda tener usar los DBEdit o
DBLabel? ¿se puede corromper la BD por un mal uso de estos o algo así?

No tienen nada malo...lo unico que si no los controlas, pues es quiza mas facil trabajar con los edits y luego postear los cambios.


3. Creen que se pueda combinar el estilo que yo uso con este otro para
lo que son las Querys por ejemplo, ya que los ADOQuerys que veo en ese
tutorial ahorran mucho trabajo (que yo hacía usando ciclos y cosas así
x_X)

Puedes asignarle a un datasource una query, incluso, sin tener que trabajar con tablas ya

Prueba de hacer, siendo q una TAdoQuery,
Código Delphi [-]
...
q.Active := false;
q.SQL.Text := 'SELECT Sum(Depositos) AS suma, Count(*) as numero_registros from BANCO';
q.Active := true;
ShowMessage(FormatFloat('0.00',q.FieldByName('suma').Asfloat));
ShowMessage(q.FieldByName('numero_registros').Asstring);
...

Estos campos quedaran en la query hasta que se haga una nueva consulta: al seleccionar, estas seleccionando esos 2 campos (suma y numero_registros) y ninguno mas en ese momento,por lo que seria como tener una tabla con solo dos campos creados a partir de BANCOS.

en ese contexto, distinctrow estaria mal. Aqui un tutorial SQL basico

Última edición por coso fecha: 17-08-2008 a las 17:13:43.
Responder Con Cita
  #3  
Antiguo 17-08-2008
Avatar de Delphius
[Delphius] Delphius is offline
Miembro Premium
 
Registrado: jul 2004
Ubicación: Salta, Argentina
Posts: 5.582
Poder: 26
Delphius Va camino a la fama
Cita:
Empezado por Forest Ver Mensaje
Bueno, soy semi-nuevo en Delphi jaja, se oye feo... pero el caso jaja es que estaba leyendo el mini-tutorial de Caral (http://www.clubdelphi.com/foros/showthread.php?t=44763) y descubrí una forma muy distinta de trabajar a la mía, y quisiera que me dijeran cual es mejor.

Primero que nada yo he usado paradox con el database desktop del delphi 6, y Firebird con Interbase Manager Lite con turbo delphi. Digo esto para explicar como me conecté a mi BD en ambos casos.

Con Delphi 6 solo cree el alias, y en el datamodule puse componentes "Ttable" y "Tdatasource".
Con Turbo Delphi batallé un poco más y tuve que crear un ODBC y pegar ademas de los componentes "Ttable" y "Tdatasource" un componente "Tdatabase" que es con la que hice la conexión.

1. Hasta aquí, ¿es mejor esa forma de conexión o es mejor con ADOconnection? ¿qué diferencias o que utilidad tiene ADOconnection?
Por empezar, son dos tecnologías de acceso a base de datos. El uso de TTable, TQuery o cualquier componente que esté en la paleta DBE te obliga a hacer uso del BDE. De este modo estás interponiendo una "capa" más de acceso entre tu base de datos y el aplicativo.

Con ADO puedes armar una conexión con mucha facilidad y conectarse a muchas bases de datos. Necesitarás un proveedor de acceso, un ODBC. Y esta manera de acceder a tus bases de datos suele ser más "lenta" que una directa o nativa.

No se como explicarte mejor el tema... no me salen mucho las palabras.
A ver si alguien más puede ser más detallista en este aspecto.

Cita:
Empezado por Forest Ver Mensaje
Luego, yo nunca he usado Querys, de hecho mi conocimiento de SQL es bastante básico, si no es que menos que eso.
Mi forma de guardar en la base de datos es algo así:
Código Delphi [-]Datamodule.Tabla.Insert //o .Edit según se requiera insertar o editar el registro Datamodule.TablaCampo1.value:= Edit1.text; Datamodule.TablaCampo2.value:= Edit2.text; Datamodule.Tabla.Post;


A diferencia de en el tuto de Caral en el que se hace referencia a los campos (o eso creo) de la siguiente forma:

Tabla.Fields[numero].Tipo¿? ... la verdad no se, no conozco estos comandos. No se si alguien me pueda aclarar por qué se hace referencia a los campos de esa forma.
Y otra cosa, cuando yo comencé me dijeron que no usara los DBEdit y DBLabel, no se por qué, pero me lo dijo alguien con más experiencia y le hice caso, y es por eso que trabajo de esa manera en vez de accesar directamente a la BD.

Igual para mostrar algún registro primero lo localizo utilizando:Código Delphi [-]DataModule.Tabla.FindKey([valor])


y después hago lo inverso a lo que describí arriba:Código Delphi [-]Edit1.text:= Datamodule.TablaCampo1.value; Edit2.text:= Datamodule.TablaCampo2.value;
El uso de una tabla nos obliga a traer todos los registros a memoria.
A diferencia de una query solo traemos los datos necesarios.

Por el tema de que diferencia hay entre esos modos de acceder
a los campos, creo que este hilo puede ser de ayuda.

Cita:
Empezado por Forest Ver Mensaje


2. ¿Tiene alguien idea de que de malo pueda tener usar los DBEdit o DBLabel? ¿se puede corromper la BD por un mal uso de estos o algo así?

No uso los componentes data-ware por lo que mucho no diré.
Me arriesgo al decir que el problema (mejor dicho, riesgo) que corremos al
usar estos componentes es que es posible modificar el cursor y
posicionarnos en un registro distinto con el que estamos operando.
El uso de data-ware puede hacernos más fácil el realizar las operaciones
contra las tabla de nuestras bases de datos, pero puede que esa libertad
de acceder tan fácil a los datos y modificarlos puede ser contraproducente
si no se controla adecuadamente la situación.
Cita:
Empezado por Forest Ver Mensaje
3. Creen que se pueda combinar el estilo que yo uso con este otro para lo que son las Querys por ejemplo, ya que los ADOQuerys que veo en ese tutorial ahorran mucho trabajo (que yo hacía usando ciclos y cosas así x_X)
La cuestión no está en combinar, sino en saber de que modo facilitarnos
el trabajo y ofrecer al mismo tiempo los controles adecuados para
ofrecer las medidas que garanticen la integridad de información, y no olvidar el criterio de la perfomance.

De cualquier modo, no soy un buen crítico para decirte que esta bien o mal, por lo que si esta bien combinar las cosas es correcto o no, mejor dejarlo a criterio de uno. Mientras mantengas el orden en tu código está bien.

Saludos,
__________________
Delphius
[Guia de estilo][Buscar]
Responder Con Cita
  #4  
Antiguo 17-08-2008
Avatar de Caral
[Caral] Caral is offline
Miembro Premium
 
Registrado: ago 2006
Posts: 7.659
Poder: 26
Caral Va por buen camino
Hola
Lo único que podría agregar a lo dicho es:
ADO es mas sencillo que BDE, la conexión es directa y fácil de hacer.
Los Query son básicos en una buena aplicación.
DISTINCTROW es usado (que yo sepa) únicamente por access, en tal caso se puede usar DISTINCT en cualquier base de datos.
Los corchetes también son usados en access, en otras no los necesita.
El tutorial esta hecho para access, pero se puede trasladar a otras bases de datos, haciendo ciertas modificaciones.
Que yo sepa no se puede combinar ADO con BDE, si es a eso a lo que te refieres.
Si lo que pides es una recomendación yo te diría que uses ADO (tambien hay otro que no me acuerdo como se llama) y te olvides de BDE.
Saludos
__________________
Siempre Novato
Responder Con Cita
  #5  
Antiguo 17-08-2008
Avatar de Lepe
[Lepe] Lepe is offline
Miembro Premium
 
Registrado: may 2003
Posts: 7.424
Poder: 29
Lepe Va por buen camino
No estoy de acuerdo con todo lo que se dice por aquí y como esto es un foro, doy mi opinión.

La verdad es que todos llevan razón, incluso tu amigo que dijo que no usaras DBEdits, pero hay que explicar el por qué no usarlos y también cuando sí usarlos.

Cita:
Empezado por Forest Ver Mensaje
Tabla.Fields[numero].Tipo¿? ... la verdad no se, no conozco estos comandos. No se si alguien me pueda aclarar por qué se hace referencia a los campos de esa forma.
...Porque le da la gana .

Tienes varios métodos para acceder a los campos:
1- campos persistentes (doble clic al TTable y después en el Field editor boton derecho y Add All Fileds). Así accedes al campo:

NombreTablaNombreCampo.AsXXX

Ésta si cabe, es la forma más rápida y eficiente de acceder al campo. Fíjate que no hay un punto entre el nombre de la tabla y el nombre del campo, el nombre es todo uno (es la forma de delphi de nombrar los campos).

2- Por el índice de la lista de campos, es casi igual de rápido que el método anterior, solo ha de accederse a la lista Fields, ver que el índice (en este caso el cuarto campo) es válido, y se accede a él:
Fields[3].AsXXX

3- Por el nombre del campo, aquí primero se ha de buscar si ese campo existe y después se accede a él:

Tabla.Fields['NombreCampo'].Asxxxx

Y por último, otro que se usa mucho:

4- tabla.FieldByName('NombreCampo').Asxxx que también implica hacer una búsqueda para ver si ese campo existe en tiempo de ejecución.

Puedes usar el que te sea más cómodo.

Cita:
Empezado por Forest Ver Mensaje
Y otra cosa, cuando yo comencé me dijeron que no usara los DBEdit y DBLabel, no se por qué, pero me lo dijo alguien con más experiencia y le hice caso, y es por eso que trabajo de esa manera en vez de accesar directamente a la BD.
Si usas Paradox y la aplicación es pequeña o mediana, te conviene usar DBEdits, ahorran mucho trabajo. Cuando la aplicación crece en tamaño, necesitas hacer operaciones en memoria con los datos, mostrar la información de otra forma en que está almacenada, etc, entonces es el momento de olvidar los DBEdits y trabajar con Edits. Un ejemplo típico:

Tienes una agenda y en la base de datos lo guardas así:
Código:
fecha		hora	tarea
01/01/2008	15:00	Ver la novela :-P
01/01/2008	17:00	Ver Barrio Sésamo :-P
02/01/2008	15:00	leer el periodico
y quieres mostrarlo al usuario así:
Código:
	01/01/2008			02/01/2008			03/01/2008
15:00	Ver la novela :-P		leer el periodico
17:00	Ver Barrio Sésamo :-P
Esto no puedes hacerlo con un DBGrid porque los días están en filas y quieres mostrarlo en columnas, así que te olvidas de los controles de DBAware y lo haces con un StringGrid.

Dentro de un programa, puedes tener una ventana donde usas DBEdits y en otra ventana no usarlos. No hay ningún problema en mezclar las filosofías de trabajo.

2. ¿Tiene alguien idea de que de malo pueda tener usar los DBEdit o DBLabel? ¿se puede corromper la BD por un mal uso de estos o algo así?

No usar DBEdits supone más trabajo. Estas 4 líneas lo hace automáticamente los DBEdits junto con un TDBNavigator:
Código Delphi [-]
Datamodule.Tabla.Insert //o .Edit según se requiera insertar o editar el registro
Datamodule.TablaCampo1.value:= Edit1.text;
Datamodule.TablaCampo2.value:= Edit2.text;
Datamodule.Tabla.Post;

Pones los DBEdits en el form, configuras su propiedad Datasource y Field, pones un TDBNavigator en el form, configuras su propiedad DataSource. Listo. Abres la tabla en el formCreate y ya puedes:
- añadir registros
- modificar registros
- borrar registros
- moverte entre registros
¡¡ sin escribir ni una sola línea de código !!

Desventajas de usar DBEdits:
- Todo lo que haces se graba directamente en la Base de datos, puede que en algún caso no te interese, quizás puedas usar Cache Updates (busca en el foro por ApplyUpdates) es un método intermedio entre usar DBEdits y usar Edits.


3. Creen que se pueda combinar el estilo que yo uso con este otro para lo que son las Querys por ejemplo, ya que los ADOQuerys que veo en ese tutorial ahorran mucho trabajo (que yo hacía usando ciclos y cosas así x_X)

[/quote]
Por supuesto, Todo los ciclos que haces en paradox puedes sustituirlo por un TQuery. Busca en internet un manual de SQL, en menos de 2 horas verás que son muy potentes y flexibles.


PD. Como un extra, y que tal vez debí postear en el tema del tutorial, alguien sería tan amable de explicarme detalladamente esta query?:

Código SQL [-]
SELECT DISTINCTROW Sum([Banco].[Depósitos]) AS [Suma De Depósitos]
FROM Banco;
Como ya te han dicho, eso equivale a recorrer todos los registros de la tabla Banco, sumar el campo deposito de todos ellos (para saber el monto total) y por último devuelve el total en un campo que se llama "Suma De Depósitos" como bien dices es un "nombre", un Alias que se le da a la suma total.

Cuando un campo lleva espacios en su nombre, se debe agregar los corchetes para que el SQL sepa donde empieza el nombre del campo y donde termina. Access usa corchetes, el SQL estandard usa dobles comillas por lo que puedes escribir ese campo de diversas formas, según el motor de bases de datos que uses.


La palabra "Sum" es una función del lenguaje SQL, también puedes hacer promedios, medias, contar registros, etc con el mismo campo de todos los registros de la tabla. El TQuery es una forma de filtrar registros de una forma más flexible que la propiedad Filter del TTable.
__________________
Si usted entendió mi comentario, contácteme y gustosamente,
se lo volveré a explicar hasta que no lo entienda, Gracias.
Responder Con Cita
  #6  
Antiguo 18-08-2008
Avatar de roman
roman roman is offline
Moderador
 
Registrado: may 2003
Ubicación: Ciudad de México
Posts: 20.269
Poder: 10
roman Es un diamante en brutoroman Es un diamante en brutoroman Es un diamante en bruto
Unas precisiones a la estupenda explicación de Lepe en cuanto a la forma de acceder a los campos:

En la primera forma -los campos persistentes- si bien pueden usarse las propiedades AsXXXX, de hecho puede directamente usarse la propiedad Value. En otros casos, Value no sería recomendable porque a nivel de TField, se trata de un tipo genérico Variant, cuyo acceso no es óptimo; pero en el caso de campos persistentes, cada campo se crea del tipo adecuado: TIntegerField, TStringField, TBooleanField, etc.

En la tercera forma:

Tabla.Fields['NombreCampo'].Asxxxx

más bien sería

Tabla['NombreCampo'].Asxxxx

o

Tabla.FieldValues['NombreCampo'].Asxxxx

// Saludos
Responder Con Cita
  #7  
Antiguo 07-10-2008
Kenobi Kenobi is offline
Miembro
 
Registrado: mar 2007
Posts: 191
Poder: 18
Kenobi Va por buen camino
Que tiene de malo o ineficiente hacerlo asi ....pregunto ?

Despues de ver este interesante hilo, me doy cuenta que yo estoy haciendo las cosas distinto a la mayoria (sera por mi pasado foxPro .. no se)a lo cual pregunto ...

yo accedo a los campos asi .

edit.text:=TablaCampo.value;

digo es rapido de escribir menos codigo que ...

edit.text:=TablaCampo.AsTipo


Jajaja es una letra menos ....

no en serio que tiene de malo mi forma para cambiarla ya ....

Gracias ....
Responder Con Cita
  #8  
Antiguo 07-10-2008
[egostar] egostar is offline
Registrado
 
Registrado: feb 2006
Posts: 6.562
Poder: 25
egostar Va camino a la fama
Cita:
Empezado por Kenobi Ver Mensaje
yo accedo a los campos asi .

edit.text:=TablaCampo.value;

digo es rapido de escribir menos codigo que ...

edit.text:=TablaCampo.AsTipo
Hola,

Genéricamente te puedo comentar que un Tedit solo almacenará datos de tipo texto, por tal motivo si tu campo es un entero y asignas con .Value te saltará una hermosa carita de error , en cambio si asignas al Tedit el valor como .AsString, aunque tu campo sea entero esta forma lo 'pasa' a texto.

Salud OS
__________________
"La forma de empezar es dejar de hablar y empezar a hacerlo." - Walt Disney
Responder Con Cita
  #9  
Antiguo 07-10-2008
Kenobi Kenobi is offline
Miembro
 
Registrado: mar 2007
Posts: 191
Poder: 18
Kenobi Va por buen camino
Que tiene de malo o ineficiente hacerlo asi ....pregunto ?

Claro tienes razon egostar, por supuesto que en caso de un numero pues

edit1.text:=InttoStr(TablaCampo.value);

por supuesto que si no lo hago asi pues bummm

ahora entiendo que con .AsXXX no lo haria pues a probar ...

Gracias ...

Última edición por Kenobi fecha: 07-10-2008 a las 17:32:58.
Responder Con Cita
  #10  
Antiguo 09-10-2008
Avatar de Softweb
Softweb Softweb is offline
Miembro
 
Registrado: ago 2008
Posts: 46
Poder: 0
Softweb Va por buen camino
Cita:
Empezado por Kenobi Ver Mensaje
Claro tienes razon egostar, por supuesto que en caso de un numero pues

edit1.text:=InttoStr(TablaCampo.value);

por supuesto que si no lo hago asi pues bummm

ahora entiendo que con .AsXXX no lo haria pues a probar ...

Gracias ...
Hola voy a dar mi opinion ya que e usados todas las formas que nombrais en el hilo de manejar un campo.

No estoy de acuerdo de que sean buenas las formas:
Campo[1]
Campo[nombre]
Campo.value

ya que con esto el peligro es que trabajamos con campos variant los cuales no se comprueban en el copilado si no en ejecucion con lo cual nos podemos encontrar con mas de un problema.

Código Delphi [-]var1: integer; var2: string; CampoEntero1[nombre] := var1; //CampoEntero1 contiene nil CampoEntero1.asinteger := var1; //CampoEntero1 contiene 0 CampoEntero1[nombre] := var2; //Con esto revienta la aplicación CampoEntero1.asinteger := var2; //Con esto no copila la aplicacion

Ademas no es lo mismo escribir

Código Delphi [-]'La fecha es '+DateTimeToStr( CampoFecha[nombre] );


Lo cual ademas si no tiene un valor el campo revienta la aplicacion.

que

Código Delphi [-]'La fecha es '+CampoFecha.AsString;



Espero sea util, Saludos.
Responder Con Cita
  #11  
Antiguo 09-10-2008
Avatar de Lepe
[Lepe] Lepe is offline
Miembro Premium
 
Registrado: may 2003
Posts: 7.424
Poder: 29
Lepe Va por buen camino
A veces, es preferible que la aplicación reviente.

Imagina que el usuario no ha escrito la fecha para un registro. Si usas fecha.AsString, nos devolverá un valor 31/12/1900 y el programa sigue corriendo con "total alegría", si hacemos cálculos con esa fecha, nos dará un error en nuestro código, pero muy alejado del origen (quizás al imprimir el registro, al abrir una consulta que hasta ahora funcionaba correctamente, etc), tendrás que buscar durante mucho tiempo esa "avería".

Si el programa revienta en la linea "DateTimeToStr( CampoFecha[nombre]" inmediatamente le dices al usuario: "ah!!, es que tienes que poner una fecha válida." y no te da dolores de cabeza.

Por cierto, una precisión: Si una variable Variant no tiene asignado un valor, su valor es precisamente "unassigned" que no tiene nada que ver con "nil".

Como siempre, todo depende de qué resultado quieras tener.

Saludos
__________________
Si usted entendió mi comentario, contácteme y gustosamente,
se lo volveré a explicar hasta que no lo entienda, Gracias.
Responder Con Cita
Respuesta



Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro

Temas Similares
Tema Autor Foro Respuestas Último mensaje
Pasar Variables de Forma a Forma con delphi.net ASP ASAPLTDA .NET 5 05-07-2007 21:51:31
Como Pasar Variables de Forma a Forma con delphi.net ASP ASAPLTDA Internet 2 02-07-2007 17:26:41
Tuto en Flash de Windows alex212 PHP 0 07-06-2007 18:07:10
De que forma trabajar con firebird y dbExpress fedelphi Conexión con bases de datos 2 25-11-2006 00:17:01
tuto de Indy? unko! Internet 4 09-02-2005 05:08:57


La franja horaria es GMT +2. Ahora son las 00:52:59.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi