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.

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)
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:
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:
y se crea un array con la cantidad que señala lote.numArticulosLote para acto seguido leer desde el fichero articulos

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...

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.

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

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