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.

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

Einhhh?

Con pythoadictos, me refiero a los programadores que les escanta python,no a que exista un foro con ese nombre...
https://foro.elhacker.net/scripting-b64.0/

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.

De venir, viene en la BIOS.

No necesariamente más tiempo, si al menos más complejo, que esto luego redunde en más tiempo o no es otra cosa, aunque puede asumirse que suele ser así.

Lo que en realidad incide es en la incapacidad de recuperación exhaustiva en el sentido de completitud, es decir no será un rescate tan riguroso, y por tanto quedarán más lagunas sin poder ser resueltas (independientemente del tiempo empleado, pero en efecto a más tiempo se le dedique más probable que se rescaten datos).

Debes imaginar que no eres ni el primero ni el último que hace esa pregunta y que por tanto debe estar respondida muchas veces, basta buscar en Google o Youtube: "IDE para Go en Windows"

Por otro lado, si no recuerdo mal, 'creo' que está prohibido usar ciertos tipos de alias, el tuyo posiblemente encaja en ello, porque sin ser un insulto, puede ser usado de forma despectiva.

La grabación de datos en soportes regrabables, deja físicamente un pequeño rastro de lo que anteriormente había debajo.
Imagina un pizarra del cole, sí hecha de piedra de pizarra o símil... en la que escribes con tiza.
Cuando te piden que la borres, según la fuerza que apliques se borra del todo, solo se desdibuja un poco o un punto intermedio entre esos extremos.
Si escribes encima, dificulta leer lo que había debajo...
Sucede lo mismo en casi cualquier otro soporte físico (caso típico de los soportes magnéticos). De hecho en los discos duros, hay una opción (típicamente no dispoonible/accesible al usuario), que permite indicar 'la fuerza' con que el disco duro escribe los datos. Cuanto más fuerte, más dificulta la lectura bajo él, pero también más fácil deja esa impresión para ser leída posteriormente, además, cuanto más fuerza se aplique con cada escritura, más se deteriora el disco, luego elegir un valor adecuado es un tema que los fabricantes deben estudiar y elegir con delicadeza...

Naturalmente no es asequible a cualquiera acceder al contenido previo, pero con paciencia (mucha paciencia) y la tecnología adecuada (un osciloscopio sería suficiente), pueden leerse varias copias previas (dicen que hasta 5), aunque asumo que esto último depende mucho de la tecnología empleada. Si no tienes registradas chorrocientas patentes, o eres multimillonario, ten por seguro que nadie va a perder tiempo en revisar lo que tenías escrito en tu disco duro, primeor porque no hay tanta gente que tenga la tecnología adecuada y segundo porque quienes la tienen la dedican a casos donde sea menester (que los contraten o ellos se autoempleen legal o ilegalmente).

No. No tiene por qué.
De hecho si revisas el log que das al final, verás que en cada pasada ha escrito valores distintos, en unos ha colocado valores aleatorios (random), también hace una escitura con 0 y una con valor 255 (byte).
Sería preferible que todas las pasadas fuera con valores aleatorios.

La escritura aleatoria adolece de la lentitud... pues crear valores aleatorios es un proceso 'caro' y al final puede no ser tan aleatorio, según el sistema. De hecho es preferible al caso no confiar en el sistema aleatorio que provee el S.O. y tirar de uno propio.
Más aun, yo lo que elegiría aleatorio serían sectores entre los que se van a borar datos... y haría un xor entre dos sectores para escribir el resultado en un tercer sector.


Yo tengo un programa que utilizo para borar ficheros, es decir hace casi esto mismo, solo que como se trata habitualmente de 1 solo fichero en cada ocasión y suele ser a menudo pequeño, en vez de operar con sectores opera con arrays de x kb. dentro del mismo fichero, y por tanto divide el fichero en y búferes, dado el tamaño de cada uno, y el resto es lo mismo.
La operación con xor es muy rápido, y o lento del random, es solo para 'barajar' los bloques, es decir una lista corta, no para cada byte.
A éste respecto, muchos programas no aclaran cuando habland de valores aleatorios, si cada byte es aleatorio y si crean un único buffer aleatroio y luego dicho buffer lo escriben a diestro y siniestro hasta completar la escritura. Esto es más rápido que elegir aleatoriamente cada byte cada vez, pero obviamente deja un patrón repetitivo.

El número de pasadas, jamás debiera ser menos de 2. Cualquier 'discrepancia' con el algoritmo y los datos previamente existentes, podrían hacer fracasar el intento. Con dos pasadas al menos asegurar haber reescrito cada contenido con casi un valor distinto al previamwente existente.


La salida que te ofrece, señala claramente en cada pasada el tipo de patrón utilizado...
luego lo que hace también es cambiar el nombre del fichero varias veces, antes de borrarlo de la tabla de ficheros (eliminación software), así también intenta que ni el nombre del mismo sea fácil de recuperar... para ser honestos, el nombre debiera ser remplazado primero por otro con la misma longitud que tiene el nombre actual... ahí me parece que empieza por uno mucho mas corto a la vista del nombre original (me edito, los '0' seguidos ocupan menos espacio y seguramente haya la misma cantidad de ceros que caracteres tiene el fichero.log).
Fíjate que en cada ocasión va acortando el nombre en un caracter menos.

Si no he entendido mal, lo que te señala StringManolo no es correcto (no lo he leído entero). Lo que dice solo es cierto si alguien escribe un nuevo fichero. Carece de utilidad práctica escribir un fichero nuevo con un contenido distinto así tenga ese nuevo fichero el mismo tamaño que el original.
El fichero queda rescrito desde el momento en que lees y escribes al mismo lugar donde yace el fichero y solo cuando terminas las pasadas es cuando le dices al software elimínalo...
Si yo abro un canal de lectura y otro de escritura en el mismo fichero y primero leo desde la primera posición y luego escribo en esa misma posición, ese contendio queda reescrito (borrado), en los mismos sectores físicos que donde yacía el contenido previo.

Estoy de acuerdo en que hay que tener cierto cuidado e informarse bien sobre una empresa antes de contratar nada que requiera un desembolso previo o un envío de valor... incluso antes de facilitar tus datos identificativos...

...pero basar solamente que una empresa no es fiable en el mero hecho de que han creado su página web con una antigüedad de 1 año o menos, es lo mismo que decir que jamás ninguna empresa pueda nacer... porque al nacer tiene 1 día (cuando pase) y no es fiable (porque tiene menos de 1 año de vida) ...si nadie se fía, como entonces va a sobrevivir siquiera 1 año y llegar a tener una madurez?.

Ninguna empresa nació jamás con una 'antigüedad web' de x años, todas emprezaron con 0 días... excepto esas que deciden comprar un sitio ya maduro, y que en realidad, esas si que son de dudar y desconfiar (pero es probable que ni te enteres).

Has respondido a un tema de hace 14 años. Debes de haber utilizado el buscador, porque estaría sepultado por páginas y páginas de hilos.

Recuerda que no deben revivirse hilos tan antiguos. Si tienes alguna pregunta, abre un nuevo hilo y en todo caso cita el enlace a este hilo (no le veo la ventaja, pero es lo que dictan las normas del foro).

Y no puede ser que simplemente esté hecha con cualquier plantilla y luego modificada a mano... realmente uno cree que siempre todo sitio debe usar forzosamente una plantilla (y solo una y además sin modificar)?.

Cualquiera con los conocimientos adecuados puede usar una plantilla (cualquiera), simplemente para adelantar-ahorrar trabajo y luego ponerse a modificar a su antojo, donde al final no quede rastro de su origen o parezca proceder de diferentes plantillas.