Tal vez en delphi 4 la propiedad tenía un nombre diferente, yo lo he hecho con Delphi 2007, pero afortunadamente el valor por defecto de esa propiedad es el espacio en blanco asi que es cierto, le podemos quitar una linea mas al procedimiento... ¿¿cuantas quedaron???... mi aritmetica ya no es lo que era en la primaria...

hola,

me pudieras ayudar en decirme como empiezo a crear un cubo de desicion con la ficha desicion cube para una base de datos..

Pues en realidad el código si es el que pusiste en un principio, incluyendo hasta la linea que le quitas ya que no especificamente el delimitador es el espacio blanco, y pues casi casi es un empate, con la unica diferencia que si se desea modificar la lista pues adicionalmente se tiene en su propia variable y no hay que copiarla de ningun lado (patadas de ahogado jajaja :D :p)

y el segundo ejemplo, si és el que mencionas, pero la aclaracion ahí mismo presentada es que en cuanto a delphi no hay ningun ahorro, sólo en cuanto a c++
__________________________________

Orale,.... genial la idea, sigan participando, hay que proponer más ejemplos, la idea es que aprendamos todos, supongo que falta hacer lo contrario delphi >>>> vb (es obio que vb va a perder jejeje:D, sobre todo con eso de la herencia jaquemate para un lado, como para el otro por la integracion con el estandar office y no se trata de eso) pero es divertido (hay que darle una muerte digna a VB jajaja)



saludos

¿Cómo harían el mismo ejemplo de ucanneo pero usando coma como separador en lugar de un espacio en blanco? Si usan CommaText, se van a llevar una sorpresa :)

Bye

Bueno, yo lo haría así:

Código Delphi [-]
  Memo1.Lines.StrictDelimiter := True;
  Memo1.Lines.Delimiter := ',';
  Memo1.Lines.CommaText := Edit1.Text;

¿cual es la sorpresa? :eek: :eek:

Hasta luego.

;)

Je, je. Está bien, cambio lo dicho: quienes usen delphi 7 o menor, se llevarán una sorpresa :)

Bye

Asi es, de hecho ya lo habia comentado y xander lo comentó. :)

Salud OS

¡Ah! Pues con mayor razón. Eso prueba que apenas a partir del BDS, Delphi empieza a llegarle a los talones a VB, y del delphi 4 mejor ni hablamos. :p :D (broma, broma, no se sulfuren).

Bye

:D:D:D, y si te dijera que es Delphi4 Standard :eek: no me creerias que lo use por muchos años sin necesitar mas

Todo depende el sector de tu negocio :)

Ahora uso Turbo Delphi y no necesito mas, por el momento...... :cool:

Salud OS

esto ta mas claro que el agua, pues claro esta mejor delphi que visual basic como de 1 a 1000


salud!

Bueno, allí va un código, a ver en cuantas líneas queda en vb:

Código Delphi [-]
  for I := 0 to ControlCount - 1 do
  begin
    Controls[i].Top := Controls[i].Top + 5;
    if (Controls[i] is TButton) then
      TButton(Controls[i]).Caption := TButton(Controls[i]).Caption + '!';
    if (Controls[i] is TEdit) then
      TEdit(Controls[i]).OnChange := NuevoEditChange;
  end;

Hasta luego.

;)

Bueno haciendo honor a nuestro compañero ucanneo, porque no comentas que es lo que hace ese código :) digo, ya sabes que habemos muchos que no tenemos esa capacidad de conceptualización :D:D:D

Salud OS

En VB quedaría exactamente igual solo que no necesitas ni el Begin ni el end; además que si se desea un If de una sola línea debería quedar al frente.

Yo ese código le agregaría un ElseIf en vez de otro If ya que el control ó es un TButton ó es un TEdit y no ambos al mismo tiempo.

Creo que para la versión 6 ó 4 del Delphi no se puede concatenar así tan olimpicamente el primer If, me disculpo si me equivoco.

Otra cosa es que la propiedad OnChange no existe para el TextBox, por cierto deberían de tratar de poner ejemplos para versiones iguales, el VB solo quedo hasta la versión 6, además deberían ser código que no relacionen en si a las propiedades de los objetos ya que el tratamiento de ellos si es abrumador entre ambos lenguajes.

El código de jachguate tampoco necesitaría del begin-end si no hubiera puesto esto:

Código Delphi [-]
Controls[i].Top := Controls[i].Top + 5;

y hubiese usado un else if (en Delphi va separado, pues es lo mismo, y en el ejemplo de jachguate lo único que arregla ponerlo es ahorrarse el escribir el begin-end del bucle for).

¿Por qué no? ¿Acaso no se están comparando? Tu código sería algo más largo si hubieras puesto un ejemplo (aunque sea con otras propiedades de otros tipos de objetos).


Salu2 :)

No, sería exactamente igual ya lo dije solo que no agregue el resto para hacerlo más genérico.

Y en cuanto a lo otro creo que idea era evaluar el lenguaje no los controles como tal, pero bueno creo que el equivalente de la propiedad OnChange del Delphi para el TextBox es Text.

Solo tengo una duda y es para que versión del Delphi es el código????, además que veo que el array de controles es genérico pero puede ser reinstanciado a un control como si fuera una matriz, mmm si es así creo que tendría que agregarle algo más al código que yo trascribí.

Editado

Creo que la primer instrucción sería así en VB

Suponiendo que hacemos uso "TEdit(Controls[i]).OnChange" y lo cambiamos por otro evento, estariamos entrando a cosas que VB no puede hacer (o al menos no tan facilmente), puesto que su orientacion a "eventos" no permitiria tal cosa, pero bueno por ahi dice la etiqueta de "Tag" en cualquier control de vb "Guarda datos adicionales para sus programas", hay quien dice que se hizo para este tipo de situaciones (ya me he topado con este problema en vb antes y sólo s me ha ocurrido solucionarlo así... sigo investigando no se me habia ocurrido ir más allá :p)


saludos

Para todas. En las versiones más recientes, añaden algún nuevo tipo, alguna nueva propiedad... pero por lo general, el código es compatible con versiones anteriores y posteriores. Es otra de las genialidades que tiene Delphi :)

Estas completamente seguro de que sirve en todas las versiones de Delphi, es muy aventado decirlo así tan sobradamente, yo me he visto con problemas de códigos que hechos en la versión 4 en la 6 toca prácticamente recodificarlos :eek::eek::eek::eek: aunque esto no aplica en todos los casos.

Un ejemplo sencillo de concatenación y conversión de datos

Hola
La verdad no se que es lo que se defiende?.
Los números, por lo menos en este debate son claros 94,44% Delphi 5,56% VB.
Que se defiende, Código, ventajas, desventajas.?
Yo creo que depende mucho del programador y del entusiasmo o conocimiento que tenga del lenguaje en especial.
Estoy convencido y nadie me va ha hacer cambiar de opinión en que VB es mucho mas complicado, exigente, tedioso, poco entendible y no se cuantas cosas mas que delphi.
No solo por mi experiencia en esto (autodidacta), si no por la experiencia de las personas que contrate y que programaban en VB, Profesionales ,(Pobrecillos).
Defender lo indefendible es absurdo.
No hay comparación Delphi le da una paliza a VB, por donde lo quieran ver, querer seguir en este debate no tiene lógica, para mi.
Siempre habrá quien quera nadar contra corriente, tarde o temprano lo veremos sacudido por esta, irremediablemente la corriente lo arrastrara, tiempo al tiempo.
Es como seguir con IE, cuando Firefox es mas rápido, efectivo, eficiente, etc, etc.
No he visto, objetivamente, una razón lógica y mucho menos técnica que demuestre que VB es un lenguaje que se acerque por lo menos un poco a Delphi, en esta vida hay que demostrar, no hablar, lo pueden hacer los que se afanan en defender lo indefendible?, lo dudo.
Si pueden hacer de un aprendiz un Novato, hablamos.:D
Saludos

Se que me van querer colgar quienes defiendan VB pero la verdad es que yo también no le veo el sentido a este debate... ¿Que se desea comparar? ¿Algoritmia? ¡Por dios!
¿Desde cuando se ha llegado al extremo de querer comparar un lenguaje por la capacidad de desarrollo de algoritmos?

En parte suena lógico el decir que, por ejemplo, si un determinado algoritmo en Delphi nos lleva 4 LDC y si en VB nos toma 6... entonces podríamos decir entonces que Delphi es 4/6 más eficiente que visual.

Si hay algo que conserva un algoritmo de un lenguaje a otro es su complejidad. Y ésta no depende de lenguaje alguno sino de la información necesaria para llevar a cabo su opración y los pasos lógicos (no de programación). Por ejemplo... implementar un algoritmo de Ordenación requiere complejidades del orden Cuadráticas (si usamos burbuja) ya sea en VB, C, C++, el que sea.... el algoritmo posee una expresión mínima.

La capacidad de abstracción y de escribir ese algoritmo en un lenguaja a otro dependerá en última de las habilidades del programador... pero las condiciones mínimas no variarán.

Si nos basamos en la teoria de Halstead, podríamos decir que un lenguaje es más ventajoso que otro dependiendo, debido a la abstracción y otros factores.

Lo que he descripto es un resumen de la toería de Halstead.

¿Cuál es el error aquí?
Pensar que las simples LDC son una medida de la verdadera eficiencia de un lenguaje.... amigos... si deseamos hacer una comparación justa y objetiva olvidemos condiciones subjetivas.

Los diversos estudios de Halstead han demostrado que si bien los lenguajes han evolucionado a la par del grado de abstracción, existe y existirá una fuerte correlación entre la expresión de una solución y la habilidad de programación.

Propongo que se evalue al lenguaje con la "habilidad técnica" que ofrece para expresar un problema.

Veamos, en Delphi, como buen lenguaje POO dividiríamos el problema en clases, las clases están en "módulos" (o mejor dicho units)... y esto nos lleva a expresar la complejidad en función de los módulos y clases.

Supongamos que tenemos k clases repartidas en n módulos. Podríamos decir que la complejidad del problema es de k/n. El problema ha sido repartido k veces a lo largo de los módulos... Entonces quedamos en que:

C = k/n

En visual basic podemos contar con esas pseudo-clases. y como sabemos... no son verdaderas representantes de la teoria POO... Estimativamente podríamos decir que en promedio k/2 clases están un un módulo de clases. (recordemos que las clases en VB no permiten la herencia, y es necesario repetir el código...) Podríamos decir que el resultado es:

C = k/2 + n/2

Teniendo esto en cuenta, yo me animaría a decir que conviene usar Delphi que Visual Basic....

Técnicamente hablando y suponiendo que empleamos lo mejor de cada lenguaje... es lógico pensar que Delphi es superior.

¿Que sentido tiene comparar LDC si al final la relación entre el esfuerzo en programar en cada lenguaje con sus capacidades técnicas es casi la misma?

De hecho... el esfuerzo por mantener el código en POO es cuadráticamente a k, mientras que en entornos como VB es a n.... Al final los resultados se tienden a "nivelar"... Más o menos el esfuerzo viene así:

E = d(k^2); para Delphi
E = d(n^2); para VB

La explicación es simple, minetras que en Delphi el esfuerzo se centra en las clases, en VB se centra en los módulos. Por lo general las clases tienden a aumentar más rápido que los módulos.

d es una constante de proporción que depende del lenguaje.

Ojo, no digo que el costo de desarrollar en VB sea el mismo que en Delphi. Sino que la ecuación E/C entre ambos tiende a ser la misma.

Si lo pudieramos ver gráficamente, el diseño de sistemas en VB sería a lo largo de n para S funcionalides, mientras que en Delphi para esas S funcionalidades tenemos k clases. Mientras uno se mueve verticalmente, otro lo hace horizontalmente.

No se si me explico.

Considero que debemos evaluar hacer un estricto debate entre Delphi y VB saquemos el factor humano de la ecuación y quedemonos con lo técnico. Si bien k y n dependen del valor subjetivo, la distribución de C y E se mantiene para cada uno con dichas fórmula.

¿A ver diganme ahora que lenguaje usarían? ¿Delphi o VB?

Debatamos ahora otro factor técnico... el factor reutilización. Mientras que en Delphi las clases tienen a ser más independientes unas a otras... en VB es más dificil conseguir esta independencia.

¿Punto a Delphi?;):rolleyes:
Hasta ahora si... al menos para mi.

Y si deseamos hacer una pequeña prueba de lo que dije... Aquí tengo una:

Se tiene una Clase (Módulo, en VB) X que está siendo usada en varios aplicativos que están en desarollo... En el sistema que te han encargado notas que que esta clase X (Módulo) tiene elementos que te son de mucha utilidad, pero que no obedecen totalmente a la interfaz o requisitos que tu tienes.
Pregunta: ¿Cómo harías en Delphi (Visual Basic) para conseguir implementar los añadidos sin que se vieran perjudicados los otros proyectos de modo que se aprovechen al máximo los beneficios de reutilización?

A ver... ahora si está lindo el debate... no se trata del algoritmia... sino de algo técnico. Espero respuestas.

Saludos,