Guardar list2 y leer list1

[corlo]

Hola soy corlo

ahora en pantalla principal hay list1 y list2

en el list2 es donde se va entrando los articulos desde el formulario y en el list1 es donde se guardan los datos del list2 al list1 para poder sumar el contado y tarjeta de credito

A la hora de entrar los datos al list2 desde el formulario lo hace bien, el problema es para guardar todos los datos del list2 a una fila del list1 asi sucesivamente con numero de ticket 1,2,3, etc del list1


a la hora de guardar seria:Command2_click()

N de ticket, fecha y hora, metodo de pago, total en el list1


en el metodo de pago esta en la pantalla principal no desde el formulario




a la hora de leer seria list1_click()
N ticket, Fecha y hora, Producto, Precio Unitario, cantidad, subtotal, total, en el list2



Gracias

[Serapis]

Puedes poner alguna captura (o más de 1 si no queda visible todo en una sola) que sirva para orientarse mejor?. Y explicar desde lo que se ve en ella?

La redacción deja que desear y no termina de entenderse bien que tienes actualmente y a dónde quieres llegar, o sea, cuál es el problema que tienes...   

...pareciera que lo que tratas de hacer es el típico 'carrito de la compra', de ser así, al fnal hay que validar o anular la compra, es decir en ese caso son dos procesos, en un o se realiza la elección de los artículos y cuando se quiera se acepta o anula, si se acepta, se procede al pago (se elige la modalidad de pago (para todas las fácturas en el carrito de la compra), se acuña la fecha de ese momento y se asigna el Id de compra para cada artículo.



...en todo momento se supone un mismo y único usuario, si fueran varios, habría que añadir la identificación del usuario al registro (un id de usuario registrado y mantener también un fichero con el registro de los usuarios, cuyos campos podrían ser (a modo de ejemplo):
Id, nombre y Apellidos (3 campos), Alias, fecha de alta, y opcionalmente teléfono. Datos como: numero de documento de identidad y datos bancarios, no son adecuados si no se establece un sistema de seguridad, como se supone que es un ejercicio de prácticas y no una aplicación real, puede obviarse o crearse ficticiamente y por tanto saltarse las cuestiones relativas a la seguridad.

Debería poderse buscar un registro de usuario desde el fichero partiendo de su Alias e Id. Pueden existir nombres completos idénticos (se da en la realidad), pero no alias, por ello al intentar registrar un usuario debe asegurarse que no existe ya, de suceder debe soliicitarse otro alias, también debiera exigirse que los alias tenga un mínimo de caracteresy un máximo y determinar que caracteres se toleran para el alias (A-Z, a-z, 0-9, rechazando el resto, incluso espacios (son traicioneros al escribirse o al filtrar 'strings') para evitar problemas con determinadas funciones de tratamiento de texto).

Para que la búsqueda de Alias sea rápida los alias únicos deberían ir (también) a un fichero (nuevo). Así este fichero podría tener asociados pares Alias-Id, siendo los alias de tamaño prefijado (se rellena con espacios a su derecha si es más corto).  En el fichero se escriben de forma contínua, pero en memoria deben constar en una tabla hash... Como estás verde con tratamiento simple de ficheros y funciones de búsqueda, las tablas hash de momento quedan fuera de tu alcance, así que puedes obviar este fichero y hacer las búsquedas secuencialmente en el registro de usuarios (anteriormente ya te incluí dos ejemplos de búsqueda secuencial en un fichero de registros).

Lo principal es lo de arriba... al menos hasta que lo soluciones.

[corlo]

Hola

asi es serapis, es para un carrito de la compra, que los datos introducidos desde el formulario, van  al list2, esto sale bien
pongo fecha a la hora de crear nueva factura , lo tengo que poner asi 14-12-2021, con la barra no me lo acepta.
el problema es:
a la hora de guardar los datos vayan a una fila del list1, para luego leer desde el list1 y vayan toda la lista de la compra  los datos al list2
de esta manera tendria todos los dias controlados
con una carpeta por mes


list1

N de ticket     fecha y hora           metodo de pago                                     total








                                                                                    total contado
                                                                      total tarjeta de credito



en el list2



N ticket            fecha y hora           producto        Precio por Unidad      cantidad    subtotal







                                                                    . contado                                 Total

Nuevo            Guardar            Imprimir           . tarjeta de credito




Todo esto es en un formulario

Te lo hago asi porque no se como hacerlo como crear una imagen de fichero y luego subirlo al foro

el tema de sumar el contado y la tarjeta de credito en el list1 , ya esta solucionado

Gracias

[Serapis]

Al lado de la tecla F12, a su derecha, tienes la tecla para capturar la pantalla, luego te va a un programa de imagen y pegas la imagen desde el portapapeles (menú edición -> pegar), luego recortas la imagen si es muy pequeña respecto de la pantalla completa y la guardas en un formato con compresión preferenetemente en jpg (excepto si hay mucho texto que deba ser leído, en ese caso en png, que conserva mejor los detalles del texto), luego lo subes a una página d ealojamiento de imágenes, copias el enlace 'para foros' y lo pegas en tu mensaje, y cuando envíes el mensaje aparecerá la imagen... es algo muy básico y se tarda más en explicar que en hacerlo.


Cuando haces compras de varios artículos a la vez, se introduce el concepto de 'lotes- pedido', es decir una compra de uno o más artículos en el mismo pedido.

La importancia de esto radica en poder asociar todos esos artículos juntos con un único pago y una única transacción.
Esto requiere modificar profundamente el programa... exige un fichero 'pedidos', que se compone de 3 registros (como mínimo)

Código [Seleccionar] Expandir

estructura Lote
    id pedido
    cantidad articulos
    id de la lista de articulos.
fin estructura

Como la lista es una cantidad variable, los registros no son de tamaño uniforme, como siempre pasa, hay varias soluciones, la rápida de programar y lenta de operar porque es recorrida secuencialmente o la lenta de programar pero más eficiente.
Entonces si optas por la opción rápida la estructura previa (type), te vale, si prefieres una más óptima, habrá dos ficheros, uno de pedidos, que aligera la estructura previa y hace los registros de tamaño uniforme:

Código [Seleccionar] Expandir

estructura Lotes
   id pedido
   cantidad articulos
   posicion
fin estructura
El campo posición indica donde s elocaliza en otro fichero el comienzo de los articulos para esa lista...
...y por tanto otro fichero que contiene únicamente ids de artículos... puede optarse por mantener en la cabecera la cantidad de ids que contiene el fichero o simplemente calcularse toda vez que cada campo tiene el mismo tamaño en bytes (2 para vbInteger o 4 para vbLong).
Entonces cuando se lee un lote, se accede al registro en el fichero lotes:

Código [Seleccionar] Expandir

dim lote as lotes
lote = getRegLote(index)
y se crea un array con la cantidad que señala lote.numArticulosLote para acto seguido leer desde el fichero articulos

Código [Seleccionar] Expandir


  dim articulos() as integer ' long?
  redim articulos(0 to lote.NumArticulosLote -1)
  get #canalArticulos, (lote.posicion * 2)+1, articulos   ' x2 porque cada id es un vbInteger? y por tanto ocupa 2 bytes y +1 porque vb6 considera el primer byte del fichero como 1 y no 0).
   ' el tamaño del array instruye a cuantos valores debe leer... por eso hay que dimensionar el array antes.


Finalmente con el array de ids, se pueden localizar en el fichero que guardas los detalles de cada artículo...

Otra opción (la sencilla de implementar y más lenta para considerar lotes), es omitir estos ficheros y a cambio modificar la semántica (signoficado y comportamiento) del campo numTicket (en el único fichero de compras-mes.dat).
Justamente el id compra (numticket que llamas tú), pasa a ser considera el id lotes que sigue siendo único y autoincremental... pero ahora se asocia se asocia con cada artículo que se compra en un mismo lote, es decir todos los artículos comprados en un lote tienen el mismo idLote (numTicket), y conviene añadir un nuevo campo (también único e incremental) así cuando se localiza un pedido se localizan todos los artículos con el mismo idLote, aunque lo habitual es que como estarán contiguos en el fichero se limita a buscar el primero, y luego leer los siguientes registros mientras el idLote sea el mismo.
Es decir el reconocimiento del lote sigue ese patrón.
El idCompra identifica cada compra así se puede discriminar cada artículo de un lote y facilita poder buscar también un solo idCompra en todo el fichero.


La lógica tras un carrito de la compra es la siguiente (a la noche si veo que tengo tiempo suficiente, te hago un breve código de ejemplo, peor en vez de modificar lo actual, creo una nueva ventana, para no tocar lo previo).

En una ventana (como hasta ahora) se puede elegir el artículo a comprar (esa parte depende de tí enteramente poner a disposición dle 'cliente' los productos disponibles, así como su precio). Hay un botón añadir al carrito...
Cuando se pulsa ese botón es cuando ese artículo, la cantidad y el precio por unidad se pasan al listado del carrito de la compra (conviene una ventana flotante y no modal para esto).
En ese momento, no se les asigna ni número de ticket, ni fecha... solo cuando se pulsa 'aceptar' el carrito d ela compra.. es decir esa ventana debería tener al menos estos 3 botones:
Aceptar, Cancelar y eliminar el/los items seleccionados del carrito de la compra
- Si se pulsa cancelar: se pide confirmación y si se confirma se vacía el listado.
- Si se pulsa eliminar items: se pide confirmación para eliminar los 'selectedcount' items... y si se confirma, se borran empezando desde el final del listado hacia el primero cada item seleccionado.
- Si se pulsa aceptar, entonces se fija la fecha de 'ahora' y se toma el idLote, y se envía a guardar los articulos en el listado, cada idCompra se genera al guardar el registro, pero idLote se debe pasar ya el mismo para todos esos artículos.

Lo que resta, es (cuando se solicite) volver a cargar el lote comprado... a decir verdad, interesaría que el listadod e compras, fuera diferenciando cada lote con un color de fondo distinto, algo que un listbox no permite, por eso decía que para listas complejas, es preferible un control tipo 'grid' (flexGrid), que admeás contiene columnas y permite ordenar por columnas automáticamente.
Lo que cambia sobretodo en este listado,  es que el lote al tratarse de una compra 'atómica', y tener todos sus artículos comprados misma fecha, mismo idLote y mismo metodo de compra, no s epermitirá eliminar un solo artículo del lote, o se elimina todo el lote o nada, pero no artículos sueltos del lote.

Con todo es preferible el método para lotes de varios ficheros, pero empieza por modificar solo para usar un fichero único y más adelante haces copia del proyecto y lo modificas para tener varios ficheros...

[corlo]

hola  serapis

es justo lo que necesito, guardar la informacion y leerla, si me pudiese hacer un ejemplo seria lo suyo, porque asi se ve la manera de trabajar con dos end type, el primero seria la entrada de los articulos, osea la grabacion, y el segundo end type seria leer la compra de la informacion, gracias.

[Serapis]

Hola.
Ayer no tuve tiempo de hacer nada, hoy (viernes), si qué el justo para copiar el proyecto y empezar a modificar... es casi empezar desde cero. Mañana en otro ratito lo completo... no estará probado (al menos a fondo, seguramente si pruebe lo esencial), porque me llevaría más tiempo del que le quiero dedicar... así que correrá de tu cuenta corregir los errores que se me hubieren colado. Eso sí, si te surge un problema que no consigues localizar, detalla el problema y reviso la causa del problema.

Es muy, muy importante, antes de meterse en un proyecto (incluso aunque sea un ejercicio), tener una especificación (aunque sea en prosa y no en pseudocódigo) de lo que se va a hacer, precisamente para evitar eso... un cambio tan profundo, que todo lo anterior prácticamente no sirva para nada. Empezar de cero hubiera sido más corto que modificarlo todo, peor he preferido modificarlo para guardar consistencia dentro de lo posible con lo previo (mantener nombres, orden de cosas, etc...), para que sea más aseqible entenderlo conforme a lo ya tratado (la memoria ayudará en eso).

Siempre hay cambios que hacer, cosas de última hora o elecciones particualres por preferencias, conveniencias o inconvenientes, pero cuando los cambios adectan toda la estructura del programa, es más fácil empezar desde cero, y eso, sí hay que tratar de evitarlo, porque entonces es tiempo perdido todo lo que se hizo previamente.

[Serapis]

Ufff.... cuanta pereza me ha dado... Rehacer desde cero las cosas es aburrido cuando pudo evitarse pensando un par de minutos antes de ponerse a escribir ni una sola línea de código, que e slo que quiere hacerse...

No he probado todo, cosas como guardar el carrito a fichero y recuperarlo (ante un cierre inesperado), o eliminar un lote no lo he probado. Los errores que pudiera haber te toca corregirlo.

Descarga del ZIP con todo el proyecto:
https://workupload.com/file/CBPxfcwTLuE (148kb. aprox. el peso se debe sobre todo a las 3 capturas de imagen, que olvidé sacar de la carpeta.. como tampoco sobrna las dejo).

He dejado también el fichero de factura de ejemplo e el zip.
He aprovechado para poner los botones con colores.
Un vistazo de como se ve...


Como se puede apreciar, la ventana de comprar ahora carece de ciertos textbox (como la fecha), que se pasan al carrito de la compra.
En el carrito de la compra se van recofgiendo los artículos comprados, juntos forman un mismo lote que se pagan de una única vez, por ello, campos como a fecha y método de pago y número de lote, se asocian con todos los artículos ahí comprados de una vez.
Puede seleccionarse algún artículo y elimarse de ahí, antes de pagar (no está probado ese botón).


La ventana principal, ahora dispone de más posiibilidades de sumar totales... puede solicitarse para todos los pedidos o solo para un pedido (el seleccionado), cuya suma se muestra a la derecha.
La suma total, además de mostrar las sumas de 'al contado' y 'con tarjeta de crédito', tambien suma el total de ambos.
Además se ha provisto una función para formatear los valores y así poder proporcionar más vistosidad...


Tendrás que mirar a fondo el proyecto, modificar lo que quieras. Igualmente la opción de imprimir factura queda a tu esfuerzo, así como porbar o corregir cualquier detalle que no funcione como se espere... no me apetece repasar a fondo que todo funciona bien... algo tendrás que hacer tú también. Si me he asegurado al menos que  comprar artículos, añadirlos al carrito, y guardarloa fichero y leerlo de fichero, esté correcto.

[corlo]

Hola Serapis

lo mirare mas a fondo ya te digo que es lo que necesitaba muchisimas gracias

con aplicaciones asin , visual basic 6.0 no esta caido todavia, se pueden hacer muchas cosas.


muchas gracias

[Serapis]

...es el 'patito feo' de la programación. El caso es que es el lenguaje que más adeptos ha tenido en el mundo... allá por el 200 eran muchos millones... probablemente pase mucho tiempo antes que otro lenguaje adquiera esas cifras (y que no sea metido con martillo en la Universidad, sino basado en el boca a boca entre sus usuarios).

Yo lo adoro con la misma intensidad que lo odio.
A favor tiene la virtud de lo rápido que puedes desarrollar casi cualquier cosa...
En contra tiene, las severas limitaciones que posee en determinadas áreas (muchos suelen suplirlas tirando de APIs, pero a mi me gusta usar solo cuando es imprescindible o cuando la solución en vb6 es enormemente más trabajosa).

Muchos lo han criticado incluso por cuestiones que son falsas (como que es un lenguaje interpretado, mal informados supongo que por la herencia del BASIC (de los 80 reflejado en los ordenadores Spectrum, Commodore, etc...), que en versiones previas si lo fue y al principio fue también compilado). Esos mismos que veían una enorme desventaja en los lenguajes interpretados y la lentitud asociada, ahora no lo tienen en cuenta cuando hablan de Python (por ejemplo).

En cualquier caso, un lenguaje muere cuando el último programador (que lo usaba) deja de usarlo...

[corlo]

Hola serapis

se que me vas ha enviar al carajo

faltaria arreglar lo de buscar articulo y eliminar registro por lote.  he probado varias cosas y no me ha funcionado

gracias