Mensajes

[antes]

windows no quiere reconocer mi celular cuando lo conecto solamente carga y ya descarto de que sea el cable por que con otro dispositivo si funciona el gran problema es que nisiquira lo reconoce el administrador de dispositivos simplemente no aparece ni windows tampoco hace el sonido tipico cuando lo conecto a la pc no se que podra ser ayuda por favor

No indicas si antes, lo reconocía y ahora no, o si es la primera vez que lo conectas.

- Si antes si lo reconocía, las causas pueden ser:
---- Lo más sencillo intentar conectarlo a otro puerto USB (probablemente exija ser un puerto USB 2.0 ó 2.1 ...). En cualquier caso el puerto debe poder suministrar el mínimo de energía que requiera la conexión.
---- El sistema 'cree' que sigue conectado... esto es culpa de haber desconectado tirando del mismo en vez de utlizar la acción: "Safely remove hardware". La solución a esto es 'desinstalar' los drivers de USB desde el administrador de dispositivos y luego apagar el pc y volverlo a encender (no hibernar, ni suspender energía, apagar 'limpiamente'). A encenderlo de nuevo, reconocerá los drivers desintalados, pero habrá vaciado los datos asociados.
---- El cable o el conector en el propio tf. están dañados. Si dices que el mismo cable funciona con otro dispositivo (en el mismo puerto), entonces habrá que asumir que o bien el conector hembra dle tf. está dañado.
- Si nunca antes lo han conectado:
---- Puede que requiera ciertos drivers. Deberías mirar la web del fabricante a ver si ofrece drivers para tu S.O. y versión. O bien ver de actualizar el S.O. (quizás buscando los drivers específicos (para los puesrtos USB)).

Antes que nada y para descartar todo tipo de problemas, prueba a conectar ese mismo tf. a otro PC (de un familiar o amigo)... Si allí tampoco funciona, va a ser problema de tu tf. ...Si funciona en otro pc, será una de las causas anteriores.

Tengo un xiaomi Redmi 6 con MIUI 12.5.3

La forma de procedimiento y ubicación de tales opciones depende fuertemente del S.O. y la versión que incorpora tu tf., pero en general debiera buscarse entre: 'Ajustes ---> Almacenamiento ---> ...'.
Si no localizas, lo admita o no... es algo que entonces debes informarte, localiza (google it's your friend) las especificaciones para el S.O. y versión que calza tu tf.

Me falta mirar de dejar virgen la usb y metersela vigen, pero no tengo medios.

...uno daba por hecho, que la unidad estaba vacía. En caso de que el El S.O. lo permita, necesita 'formatear' la tarjeta de memoria, para ser establecida de ese modo. Si no está vacía 'entiende' que el usuario ha decidido mantener su contenido intacto.

En Android, cuando apareció esta posibilidad, era un fastidio que al hacer dicha operación formateaba la unidad, sin siquiera avisarte, por lo que perdías su contenido... supongo que ante las quejas de los usuarios cambiarion su comportamiento a algo menos 'intrusivo y fatídico'.

Vuelca su contenido en otra unidad (un PC, por ejemplo), luego formatéala y cuando la introduzcas en el tf. de nuevo, es probable que el S.O. viendo que la tabla de ficheros está vacía te pregunte, o bien en las opciones, permita formatear y luego aparezca la opción de establecerla como ("ubicación predeterminada --> Tarjeta SD"), unidad para instalar las aplicaciones (cambiando el valor ahí presente).

[tener una especificación (aunque sea en prosa y no en pseudocódigo) de lo que se va a hacer]

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.

[compras de varios artículos a la vez, se introduce el concepto de 'lotes- pedido']

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

¿Puedes pasarme el enlace del foro pythoadictos, por favor? Lo he buscado en google y no lo encuentro. Gracias.

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.

Esto te refieres a los discos HDD, y como se puede acceder a esta opción no disponible por el usuario? En linux

De venir, viene en la BIOS.

En pocas palabrás, dices que cuando más sobreescrituras haces, más tiempo la persona interesada en sacar la informacion del HDD/SDD tardará en sacar la información e incluso este puede venir deformado.....Es así?

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 pregunta del millon..... ¿Porque tantas pasadas?
Se dice que (o lo he leido/oido) que cuando más pasadas más seguro es y...¿menos posible de recuperar? eso me suena, pero de donde.
En caso de que se pueda recuperar,¿no es imposible auque sea una unica pasada (sobrescrito una iteracion)?
No acabo de entender porque tantas iteraciones...
Es por mera curiosidad...para entender más sobre su funcionamiento auque no he visto ningún sitio que explicara la razon de las iteraciones....

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

Cuando hablamos de un disco duro, estamos hablando de

Yo lo entiendo así, y es que, el -z convierte los bits 1 a 0, haciendo que este no se pueda recuperar con alguna herramienta foranea (ejemplo: foremost).

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.

Código [Seleccionar] Expandir


Por cada pasada solicitada
   desordenar lista de sectores (implicados)
   s1 = listasectores(ultimoº)
   s2 = listasectores(penultimoº)
   for cada sector a borrar desde el antepenultimoº hasta el 1º
       s3 = sector
       bucle para k desde 0 a  tamañosector -1
           s1(k) = s2(k) xor s3(k)
       siguiente
       s1 = s2
       s2= s3
   siguiente
   // al llegar aquí, quedan s2 y s3 originales, sin rescribir
   s3= random entre listasectores que no sea s1 ni s2 ni el s3 previo
   bucle desde 0 a  tamañosector -1
       s1(byte) = s2(byte) xor s3(byte)
   siguiente
   s1 = s2
   s2= s3

   s3= random entre listasectores que no sea s1 ni s2 ni el s3 previo
   bucle desde 0 a  tamañosector -1
       s1(byte) = s2(byte) xor s3(byte)
   siguiente
   s1 = s2
   s2= s3
siguiente pasada

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.

Además la salida que este imprime en pantalla....como lo interpreto??
Si alguíen me lo puede explicar, para entender....se lo agradeceria.

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