Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Libro de Ruben Iglesias

2 views
Skip to first unread message

Juan Antonio Buerba V.

unread,
Sep 22, 1997, 3:00:00 AM9/22/97
to

Oye Ruben logre adquirir tu libro me lo trajeron desde la bella españa,
pero tengo una queja muy grande contigo, desde que termine de leerlo he
tenido que hacer veinte mil correcciones a mis aplicaciones, realmente la
tecnologia que utilizas esta de lujo.
Una pregunta crees que esta tecnologia pueda ser aplicada a pantallas en
las que tengo todos mis campos como variables de memoria. Es que realmente
creo que es mas rigido este concepto en cuanto a las pantallas se refiere
ya que no estan directamente localizados en los registros, puesto que los
usuarios a los que les desarrollo el software son unas piedras en cuanto a
utilizacion de las computadoras, y con esto restrinjo un poco los
movimientos, es decir para que hagan una modificacion en un campo necesitan
forzosamente presionar un boton de 'editar' para poder entrar directamente
a los campos, y se desactivan los botones de movimiento dentro de la tabla.
Cual es tu opinion al respecto?
--
Juan Antonio Buerba V.
jbu...@saitel.com.mx

Rubén Iglesias

unread,
Sep 23, 1997, 3:00:00 AM9/23/97
to

Hola Juan Antonio:

Primeramente, me alegro que te guste la forma en la que está programado y
por otra parte siento que tengas que trabajar más por mi culpa ;-)

En cuanto a lo que comentas de las variables de memoria y un botón para
editar, en Foxpro 2.6 tenía aplicaciones que funcionaban así y la verdad
es
que no quedaba nada mal. La razón principal de utilizar variables era
controlar si cancelaba o guardaba los datos. Sin embargo, con VFP esto ya
no hay que hacerlo gracias al Sistema de Almacenamiento en Buffer (es
genial!!) y ello me llevó a asociar todos los objetos del Form
directamente
a campos de las tablas. Te aconsejo que aunque te cueste un poco vayas
cambiando esto, por lo menos en las aplicaciones nuevas.

Por otra parte, me parece perfecto que desactives los botones que no deba
ni pueda utilizar el usuario. Así evitas problemas. Yo lo hago así, aunque
en la clase Barra del libro no está implementado. No dudes ni un momento
en
añadir estos controles. Ten en cuenta que nuestras aplicaciones deben
intentar cumpliar las reglas GUI (Graphic User Interface) y una de ellas
habla precisamente de la desactivación y activación de las opciones según
convenga.

No dudes en preguntarme todo lo que no comprendas o aportar ideas
distintas
a las que expongo en el libro. Precisamente esa es mi intención. No todos
vamos
a programar igual!!.

Saludos.


Juan Antonio Buerba V.

unread,
Sep 24, 1997, 3:00:00 AM9/24/97
to

Ok me parece correcto tu cometario tratare de irlo haciendo con mis nuevas
ventanas.
Tengo otra duda; en tus ejemplos del libro el sistema esta basado en
opciones distintas aplicables desde tu menu (menuprin) estoy de acuerdo con
esto pero no se si el tener todos mis enlaces a las ventanas dentro de un
form principal el cual contiene en principio una imagen grafica de fondo
(para darle presencia a mi aplicacion en este caso es un grafico BMP), y
dentro de este form tengo diversos botones para poder hacer todo lo
necesario de mi aplicacion, creo que es mas intuitivo para el usuario, pero
mi pregunta concreta es: ESTO AFECTA AL PERFORMANCE DE MI APLICACION, o sea
que tengo por ejemplo un boton que dice reportes, este a su vez me lleva a
una ventana en la que me aparecen todos los reportes del sistema, otro
boton que dice catalogos el cual me aparece otra ventana que me muestra las
diferentes tablas de datos que contienen mi sistema, etc., etc..
esto lo hice con la finalidad de tener una aplicacion mas grafica crees que
siminuya la velocidad de mi programa?

Por ultimo no se si tendras por hay entre tus curiosidades algun ejemplo de
una pantalla muestra como de facturacion que es lo que me aplica
principalmente a mi, claro si esto no te causa ningun inconveniente.

de antemano gracias...

Antonio Muñoz de Burgos

unread,
Sep 24, 1997, 3:00:00 AM9/24/97
to

Hola Juan :

Con respecto a la pregunta si "Esto afecta al rendimiento de la
aplicación"

En principio se puede decir que si, ten encuenta que cuanto más objetos
tengas más serán los recursos, sobre todo comparandolos con lo que puede
estar en un "menu", pero realmente no creo que eso sea algo que tengas que
preocuparte, porque no será mucho lo que necesite.

Lo que si es cierto y el que más recursos puede quitarte a la aplicación es
el gráfico de fondo que utilizas, todo dependerá del tamaño, colores, etc.

Lo único que debes cuidar con el gráfico es la paleta utilizada, ya que fox
solo mantiene una paleta por vez, lo cual conlleva a que si utilizas o se
visualiza otro grafico con una paleta distinta podrás perder los colores de
la imagen que no sea la actual.

Saludos. Antonio Muñoz

--
ma...@arrakis.es
www.arrakis.es/~mans
Sevilla - España

Rubén Iglesias

unread,
Sep 26, 1997, 3:00:00 AM9/26/97
to

Hola Juan Antonio:
--
Saludos

>Tengo otra duda; en tus ejemplos del libro el sistema esta basado en
>opciones distintas aplicables desde tu menu (menuprin) estoy de acuerdo
con
>esto pero no se si el tener todos mis enlaces a las ventanas dentro de
un
>form principal el cual contiene en principio una imagen grafica de fondo
>(para darle presencia a mi aplicacion en este caso es un grafico BMP), y
>dentro de este form tengo diversos botones para poder hacer todo lo
>necesario de mi aplicacion, creo que es mas intuitivo para el usuario,
pero
>mi pregunta concreta es: ESTO AFECTA AL PERFORMANCE DE MI APLICACION, o
sea
>que tengo por ejemplo un boton que dice reportes, este a su vez me lleva
a
>una ventana en la que me aparecen todos los reportes del sistema, otro
>boton que dice catalogos el cual me aparece otra ventana que me muestra
las
>diferentes tablas de datos que contienen mi sistema, etc., etc..
>esto lo hice con la finalidad de tener una aplicacion mas grafica crees
que
>siminuya la velocidad de mi programa?

Sencillamente es otra forma de hacer aplicaciones Windows. Lo que puedes
perder en rápidez vendrá dado por los gráficos en sí. Este estilo aunque tu
comentas que es más intuitivo para el usuario, para mi tiene demasiadas
reminiscencias al pasado, al clásico menú de entrada. El estándar GUI habla
del tipo de menús desplegables y no de ese. De todas formas, para gustos
están hechos los colores.

>Por ultimo no se si tendras por hay entre tus curiosidades algun ejemplo
de
>una pantalla muestra como de facturacion que es lo que me aplica
>principalmente a mi, claro si esto no te causa ningun inconveniente.

Puedes perfectamente tomar como referencia el Form de Curriculms del libro.
En vez de tener varias páginas, lo pondrías todo en uno, cabecera y líneas.
El mantenimiento de ambas es similar al que explico.

Saludos.

Juan Antonio Buerba V.

unread,
Sep 27, 1997, 3:00:00 AM9/27/97
to

No es realmente el despliegue de un menu como me comentas sino una serie de
botones para seleccionar lo que se quiere hacer en el sistema, ej.(un
botono de Clientes que automaticamente te trae la ventana del catalogo de
clientes, otra para pedidos que hace lo mismo unicamente que para los
pedidos, otro boton para facturas y asi sucesivamente) lo que ayuda con
esto es que en lugar de que tengan que ir al menu y seleccionar su opcion
(o aprenderse las teclas rapidas) unicamente aprieten el boton que
soliciten.
Crees que valga la pena, o realmente el desempeño del sistema mejorara si
quito estas opciones de botones, por cierto en mi aplicacion tengo como
fondo un collage de fotos que tuve que bajar a resolucion de 16 colores
porque como comenta Antonio Muñoz me hacia unas pachangas con los colores
que pa que te cuento.

Rubén Iglesias

unread,
Sep 29, 1997, 3:00:00 AM9/29/97
to

Hola Juan Antonio:

Si te gusta esa forma de hacer las aplicaciones no creo que haya razones de
peso para cambiarla. Soy partidario de que cada programador, cada empresa
tenga su estilo. Que el cliente diga: "este programa me suena, es de Juan
Antonio".

Saludos.


0 new messages