Guardar list2 y leer list1

[Serapis]

Bueno... tengo vacaciones ya hasta después de año nuevo, aunque ya me han buscado tareas en casa  para mantenerme 'ocupado'... miraré de echarle un ojo mañana, hoy ya lo tengo cubierto.

[BlackZeroX]

Esto quedaría mejor usando una capa de persistencia que implementara SQL Lite...

https://github.com/RobbiNespu/VB6-Sqlite3

Me suena a mucho usar el patrón Command (Cada operación a SQLLite una entidad Command esto para ejecutar SQL y convertir los datos a Estructuras o viceversa) junto al Chain of responsibility [Opcional]...

Te recomiendo usar patrones de desarrollo para que este tipo de adaptaciones te resulten a futuro de fácil mantenimiento.

https://profile.es/blog/patrones-de-diseno-de-software/

Las operaciones para guardar datos en archivos es siempre mejor SQL-Lite que usar archivos en formatos planos... a la larga es tedioso e imaginate antes cuando no existía el SSD la latencia era peor.

Saludos.

[Serapis]

Esto quedaría mejor usando una capa de persistencia que implementara SQL Lite...

Por supuesto...

Pero es un usuario que esta empezando, aprendiendo. Si no sabe usar ficheros, me temo que una base de datos mucho menos.
Antes de aprender a correr, debe uno aprender a andar (tropezarse, caer y levantarse)...

Más que nada, busca aprender, no tener un código optimizado. Pasar de un código espagueti a uno estructurado, es un paso que debe dar, fijándose, repitiendo y cuando adquiera un poco de soltura ya profundizará.

[Serapis]

He sacado un rato hoy para completar lo que faltaba...
...eran pequeños detalles, por ejemplo al buscar artículos, requería eliminar los espacios al ser una cadena de longitud fija los caracteres faltantes son espacios, y al ingresar el texto de búsqueda, uno nunca añade tales espacios... etc, etc...

He añadido de paso la posibilidad de búsqueda parcial usando patrones. En el código  como comentario he dejado algún ejemplo (si mal no recuerdo).

Y pequeños cambios, como añadir un 0 más a los decimales cuando totaliza (para que no redondeee a solo 2 decimales), etc...

Descarga (esta vez me acordé de apartar las imagenes):
https://workupload.com/file/mg4XLfn97CN  (aprox. 27kb)

[corlo]

muchas gracias serapis

ahora solo faltaria hacer el formulario de venta con list1 y con numero de factura, solo te pido si me pudieses hacer el control de numero de factura consecutivo desde 1 hasta  infinito con archivo guadar  ya seria mucho.

muchas gracias


feliz navidad y un prospero año nuevo 2022


javascript:void(0);

[BlackZeroX]

Por supuesto...

Pero es un usuario que esta empezando, aprendiendo. Si no sabe usar ficheros, me temo que una base de datos mucho menos.
Antes de aprender a correr, debe uno aprender a andar (tropezarse, caer y levantarse)...

Más que nada, busca aprender, no tener un código optimizado. Pasar de un código espagueti a uno estructurado, es un paso que debe dar, fijándose, repitiendo y cuando adquiera un poco de soltura ya profundizará.

He sacado un rato hoy para completar lo que faltaba...

solo te pido si me pudieses hacer el control de numero de factura consecutivo desde 1 hasta  infinito con archivo guadar  ya seria mucho.

@Serapis
mmm... sin comentarios, yo antes hacia lo mismo que tu.

Solo algo que llegue ver de forma profesional:

Sea el lenguaje que sea note que mas del 80% de los desarrolladores con los que conocí (chavos/jóvenes/señores ya sea que tengan MAESTRIA/DOCTORADO o solo licenciatura), tienen en su mayoría bastante tiempo (Yo era uno de ellos) y no usan patrones es mas cuando tienen que cambiar una regla de negocio afectan a varios elementos pues no existe un patrón del mismo, sus pruebas unitarias son repetitivas, muchos de ellos le corren (detestan) a los patrones pues no los comprenden o no los conocen.

Si hay que Gatear/Pararse/Caminar/Correr que sea guiado.

Saludos.

[Serapis]

@Serapis
mmm... sin comentarios, yo antes hacia lo mismo que tu.

No sé a qué te refieres exactamente... Si es por poner algo de código, no acostumbro a hacerlo, casi siempre pongo las explicaciones pertienentes y pseudocódigo. Peor cuando veo código espagueti, entiendo que el interesado no tiene la ayuda necesaria para avanzar...

Nadie discute que para viajar lejos, el avión el barco o un tren, lo hacen más barato.
Y para desplazamientos cercanos, un autobús o el metro también lo son.
...pero a pesar de todo eso, la gente sigue prefiriendo usar su propio vehículo, cuando puede incluso a pesar de que le salga algo más caro (viajar y manetener el vehículo), porque al final esos medios de transporte tienen 'paradas' y con tu vehículo, vas exactamente al punto donde necesitas (aunque luego en la práctica hay que aparcar donde haya espacio y por tanto toque andar lo mismo que si se hubiere usado el bus), y sobretodo con los horarios que quieras, sin depender de si, ya no hay buses o si el siguiente tardará 30 minutos en pasar...
Mira a tu alrededor y verás que al final sea con bici, monopatín, ciclomotor o coche (carro), la gente prefiere su propio vehículo casi siempre a un medio colectivo.

Hay un orden en las cosas... las bases de datos están al final del aprendizaje (de hecho jamás recomendaría SQLLite, sino SQLServer)... al comienzo los ficheros de texto, e incluso en ese punto, los de acceso secuencial y acceso aleatorio.
Cuando tenga la experiencia necesaria, es de esperar que avance. Saltar de la nada a las bases de datos, solo sirve para tener una nebulosa de como las cosas se hacen por debajo...

Me parece que lo interesante para Corlo, más incluso que resolver su problema con este ejercicio, es que acabe de entender la diferencia entre el código espagueti y un código organizado (ni siquiera le propongo utilizar clases), suele conseguirse con algo de paciencia, cuando comparan, acabarán por notar una diferencia por el contraste. Justo cuando hay un contraste entre el modo de hacer hasta ahora y el modo en que se ve algo (reciente o no), es cuando la gente tiene la oportunidad de avanzar (más rápido).

En cualquier caso, el hilo no va sobre filosofía del aprendizaje. Que cada cual se remita a lo que su interior le dicte, incluso creyendose en posesión de la verdad o del error, pues al final es sólo su tiempo (y no el de otro) lo que hay en juego.

[corlo]

Hola serapis

solo seria un codigo para controlar el numero de factura para guardarlo en archivo

en un text1.text numero de factura y un list1 y guardarlo, solo el numero de factura

como toda la informacion esta guardado en un archivo, yo antes lo hacia en dos archivos, uno en guardar el indice y el otro guardaba los demas items.


Gracias

[Serapis]

ahora solo faltaria hacer el formulario de venta con list1 y con numero de factura, solo te pido si me pudieses hacer el control de numero de factura consecutivo desde 1 hasta  infinito con archivo guadar  ya seria mucho.

Venía a decirte que como ejercició está bien y hasta ahí, y que resolverte cada addedum solicitado, al final, acaba pareciendo más una tarea que un ejercicio.

Nota que, una vez más la asuencia de una especificación inicila y clara, obliga a cambiar cosas que se daban por 'definitivas', más aún se observa en la nueva petición que hay cosas en el aire, detalles ambiguos que al resolverlos uno debe decidirse por un lado, sin saber si luego será por el otro, y por tanto trabajo en vano.

Te comento por encima para que entiendas la diferencia de cosas y el problema de tirar al vuelo código sin una especificación.
Como mínimo esta debe estar perfectamente clara en tu mente (pero es algo que solo se adquiere con el tiempo), si no te entretienes a detallarla en papel o en un fichero... La ventaja del papel es que puedes mezclar texto y garabatos de forma rápida, guardaro en el bolsillo y llevártelo donde sea, que al momento que surja otra idea, puedes añadirla o modificar la previa. Así y todo al final procede pasarlo a un fichero, dejándolo libre de polvo y paja (tachones e ideas rechazadas)...
Antes de ponerte a escribir una sola línea de código, debes tener clara la especificación del problema a atacar. Si es simple, como digo puedes mantenerlo completamente en tu mente y hacer un esqueleto del mismo (en pseudocódigo), analizar alternativas y decidir según los objetivos perseguidos...


Añadir una ventana de ventas, implica todo esto:
- Añadir artículos a la venta. La que ahora es la 'ventana de compra', pasaría a ser esa de 'ventana de entrada de artículos'.
- Comprar artículos. Ahora la ventana de compra en vez de la actual de compra, sería la 'ventana de ventas', donde el vendedor expone todos sus artículos a la venta. Que igualmente con cada compra se pasarían al 'carrito de la compra' donde finalmente se acepta o se rechazan.
- Comprar un artículo definitivamente, debería reducir el 'stock' en venta. Por lo que esa 'ventana de artículos', debe al mismo tiempo añadir un campo con el concepto de 'stock disponible', y la 'ventana de entrada de artículos', debe modificarse, la cantidad (que antes implicaba la cantidad comprada), ahora indicaría la cantidad en stock disponible... El subtotal en este caso también cambiaría pues vendría a indicar el precio total del coste al proveedor. Además en esa misma ventana habría que poner otro precio, el de 'precio al cliente', pués el precio que ahí consta podría bien reflejar el precio al que el vendedor lo compró al proveedor.
- Si hay una ventana de ventas, es claro que habrá más de un cliente, pues el proyecto ahora mismo se aproxima más a uno para llevar control de sus propias compras, es decir un solo comprador (tú), administrando tus compras de aquí y allá. Una ventana de ventas, se aproxima más a la vista dle vendedor. En este caso hay más de una opción... ----- Se trata de (por ejemplo) una tienda de ropa?. Donde aunque solo hay un único vendedor (la tienda en sí), se personifica en cada empleado que atiende en la caja registradora... luego pueden considerarse varios vendedores. si miras tus tickets de compra de supermercados típicamente al final en la  impresión de la factura verás el típico: "Le atendió Patricia".
----- Se trata de una plataforma de ventas (por ejemplo amazon, eBay). Donde cada venddor no tiene nada que ver con otro vendedor.
En ambos casos, interesa hacer constar la referencia del vendedor (el nombre o Id del vendedor en el caso del primeor y el Id o alias en e l caso del segundo). Sin embargo una diferencia entre ambos, modos es que el el primero no requiere una identificación (login) de usuario, ni por tanto una cuenta registrada a su nombre. El usuario accede a la tienda, compra, paga y se va con sus artículos comprados. En el segundo caso, el usuario para poder comprar debe estar registrado (aunque puede comprar y añadir compras al carrito, a la hora de pagar, se le exigirán las credenciales.

También una ventana de ventas, supone una factura por (lote), por cada comprador. Antes la ventana de compras, acuñaba el id de compras y artículo a medida que estos eran comprados... (por que es una facturación de 'compras' es decir para uso privado del comprador), ahora esos ids, cambian el momento de ser creados. El de artículo debe acuñarse cuando el vendedor añade sus artículos al stock y el de lote, cuando el comrador lo adquiere y deben acompañar.

Luego una 'ventana de ventas' (ventana de artículos en venta), exige otra 'ventana de artículos vendidos' para poder despachar las ventas. Si se trata del segundo caso, debe llevar el campo id o alias del comprador, que además estará asociado con un registor en otro fichero con sus datos (para el envio). Aquí además entra en conflicto la concurrencia de eventos... del tipo: qué pasa si mientras un comprador mete un artículo en su carrito, y le pulsa pagar pasa el tiempo suficiente tal que otro comprador haya adquirido el mismo artículo y por tanto ya no esté en stock, o lo esté pero no en la cantidad solicitada por el comprador?. Exige implementar un sistema eficaz de algún tipo de bloqueo, o bien comprobar en el momento exacto del pago artículo por artículo si aún están en stock. Sea el método elegido que sea, debe ser lo más flexible posible para que la experiencia del comprador no sea 'desagradable' y descarte comprar de nuevo en 'ese sitio' por su mala gestión del stock'.

Igualmente la que ahora es la ventana de compras, lo sería para cada comprador, pero debería adaptarse al caso concreto de cada tipo de 'venta' comentado (hay más opciones pero son los dos casos generales).

En segun que condiciones, puede interesar que cada lote comprado sea un fichero señalando en tal caso como nombre de fichero el id del lote. Al caso tales ficheros tendrían dos registros distintos. el primero es un resumen de la compra: Cantidad de artículos comprados, fecha, numero de lote (que coincidirá con el nombre dle fichero), e id o alias del comprador (si procede) y el monto total de la compra. Y le siguen los registros de compra de cada artículo.
Esto simplificaría enormemente la 'ventana de articulos vendidos', pues la lista, contendría (imprescindible tan solo) los IdLote y puede que cualquier otro campo más, como montototal de la venta del lote, o la fecha, etc.. y si es extenso, contendría justamente la linea completa del registor dle lote que ecabeza cada fichero (aunque lo veo excesivo)... al pulsar en una línea de esa lista, se leería el lote y se presentarían sus detalles debajo de esa lista o en una ventana aparte.

Hablando de ventas, también procede una búsqueda por 'comprador' (dando su Id, o alias). Igualmente si se trata de una plataforma de ventas, donde cada comprador puede hacer compras a distintos vendedores, procede hacer búsquedas por id o alias de vendedor. No en cambio si el tipo de ventas es de un solo vendedor y los 'vendedores' son solo los empelados capacitdo para manejar la terminal de ventas. Aunque incluso así, el propio vendedor (la tiemda), podría querer consultar la ventas que ha realizado al cabo del mes cada uno de sus empleados, en defintiva... con ventas las posibilidades se disparan y deben quedar previamente  definidas y acotadas.

Otra cuestión menor es por ejemplo, tratándose solamente de un facturación personal de compras (loq eu creía que tenías entre manos hasta ahora), usar Ids de tipo integer satisfacen la aplicación. Las compras en un mes para una persona a lo sumo serán unos pocos cientos...  pero para ventas, la cosa cambia... el número de compradores puede ser desconocido, luego un tipo 'integer' (2^15 en vb6), no es válido, debe ser al menos de tipo 'long' (2^31 en vb6).

Cuando el número de registors en un fichero es elevado (con compras por mes, no creo que suceda, peor sí con ventas por mes), los métodos de búsqueda secuencial, pierden todo interés por su ineficiencia (para unos cientos son válidos y más que aceptables a cambio de su simplicidad, pués una búsqueda representará en tiempo apenas un parpadeo), para más cantidades procede tirar de tablas hash, o ciertos tipos de árboles, pero son un tema más avanzado, para el que se precisa tener ciertos conocimientos mucho más sólidos en el lenguaje con que se opera.

En fin, tienes detalles suficientes para avanzar en cualquier dirección que quieras el proyecto (te aconsejo que lo guardes, copies y pegues y hagas las modificaciones en la nueva copia) y código en el que fijarte para construir lo que te falte y requieras. Como puedes leer son tantos detalles (solo he tomado algunos al vuelo, al pormenor son muchos más), que es inaceptable proceder sin una especificación bien detallada. El abanico de posibilidades se abre demasiado.

Cuando tomas un taxi, tu le dices a dónde vas, el taxista ya conoce la ruta más óptima sea en km. o en tiempo según el día de la semana, hora del día, etc... ahora si le dices... vamos al campo de fútbol y cuando llegas... ahora esa calle al final, luego cuando llega.. ahora gira a la izquierda y avanza hasta la segunda calle y luego... el taxista va a ciegas... a un taxista le dará igual si al final recorres 20km. o si tardas 30 minutos más, pues cobra por el tiempo, pero si desde un principio le explicas voy a tal sitio que está dentro de tal ciudad/barrio... a buen seguro sale más barato. Aquí pasa lo mismo, se va 'conduciendo a ciegas', pareces ir a un sitio, peor al llegar dices, 'No, ahora vamos a ese otro sitio'...

Lo que pretendo decirte, es que ...al final, no es la complejidad, pues se desgrana todo en un árbol de decisión y cada cosa con sus detalles queda recogida y puede ser adecuada y convenientemente implementada y además no se tarda tanto, es la falta de una especificación completa del sistema desde el punto uno... lo que impide dar una solución definitiva al tema.

Si un día llegas a vivir profesionalmente de esto, te darás cuenta que: los peores clientes, los que hay que evitar a toda costa, los que hay que reconocer desde un principio para decirles no o dejar claro todo desde un principio, es justamente el que opera de este modo, cambiando contínuamente cosas, que hacen que el tiempo empleado en parte de lo previo no sirva para nada, que los plazos se alargan y nunca se termina el proyecto y que en muchos casos intentarán mantener el precio inicial sin cambios, basado en su punto de vista porque 'son solo unos pequeños cambios'. Incluso aunque el presupuesto inicial fuera más que generoso, es fácil al final acabar perdiendo dinero, tiempo y puede que hasta la paciencia 

[corlo]

Hola serapis

muchas gracias por todo he aprendido mucho contigo , gracias por la explicacion pero no quiero tantas cosas, ya iré avanzando poco a poco


de verdad muchas gracias