Mensajes

No es eso lo que pide...
Lo que quiere es reunir el contenido de cada ítem el listbox concatenado al del ítem del segundo listbox...

en un bucle...
l3.additem (l1.item(k) & l2.item(k))

Pero eso no merece ni comentarlo, uno debe leerse como mínimo algo de documentación de aquello que quiere usar, con que un listbox de compone de 'items' es elemental como elemental es concatenar cadenas.
...para eso no hace falta ayuda ninguna, solo documentarse, es un problema típico de vagos, no de información compleja...

No deis de comer a los vagos, vendrán en masa...

[síndrome NIH*]

La verdad es que padeces el síndrome NIH* (tranquilo, no es ninguna enfermedad ni ningún insulto, incluso cierta dosis del mismo es sana, solo que tú lo llevas al extremo máximo, despreciando todo).

Jamás nadie habla en términos de cantidad de variables ni parámetros ni estados, al hablar de algún determinado problema, básicamente porque en ese punto se asume como desconocido, incluso aunque sea específico, de entrada no ayuda en nada.

Se habla de problemas y su resolución, sin importar en principio ningún detalle, estos surgen de forma natural al ahondar en el problema.
De hecho llevándolo al extremo, se considera que todo problema de x parámetros equivale a otro problema idéntico de x-1 parámetros al que se despejado ya un parámetro, así puede entender y verificarse que pueden construirse soluciones con 1 único parámetro donde se encadenan para completar la solución completa... sin embargo en la práctica no es eficiente en el tiempo, por lo que se restrinje a determinadas soluciones.

Hay varios métodologías de resolución de problemas:
Los más útiles suelen ser el 'Divide y vencerás', que básicamente viene a determinar en identificar partes distintas y que por tanto tienen un enfoque distinto. Luego cada parte se vuelve a analizar y se determinan nuevas partes... la fase de análisis termina cuando la parte puede ser ya codificada (aplicarse la solución) porque se conoce la solución, esto es, cuando ya el problema no plantea dudas al modo de resolverlo de forma eficiente.
En fin son dos fases: análisis y síntesis. Durante análisis vas identificando partes y separándolas, durante la fase de síntesis vas aplicando las soluciones a miniproblema (porque ya es tratable, porque es ahí cuando y donde acaba la fase de análisis).

Tu pasas directamente a la síntesis e intentas un análisis en medio de ello en puntos triviales, además lo haces de una forma horizontal cuando ni siquiera esté demostrado que una solución sirva para todos los sistemas, porque ni siquiera está demostrado que ese problema sea aplicable a todos los problemas, tu asumes que sí, así por las buenas porque no descompones en la fase de análisis apropiadamente...
...y ya ni hablar de la propia jerga que te has inventado y que solo tu conoces e interpretas despreciando por completo TODA la historia de la Humanidad. El resultado es que es prácticamente imposible ayudarte, por varias razones, la primera porque es difícil entender donde quieres ir a parar y la última porque aún dando por claro el problema y dándote la solución adecuada, luego no la aplicas, la desprecias y "sigues a lo tuyo"...

Ya te he sugerido en alguna que otra ocasión que te olvides de Postscript. Casi cualquier otro lenguaje que elijas será mejor y más completo que 'eso'. Postscript no es un lenguaje de programación de propósito general, sino específico y muy limitado... Si solo tienes una cuchara y una taza de metal y con ello tienes que hacer una pila con ingenio uno se puede apañar, pero que uno crea que eso es suficiente para hacer cualquier cosa, pués acaba así... en tener que reinventar soluciones absurdas para circundar las altas restricciones del lenguaje... y de camino dar nombres a métodologías y soluciones altamente parciales a los pasos dados en un contexto aislado (como si no existiera cultura más allá de tu mente).

Aún así, te pongo algo de lectura que espero que como mínimo te tomes la molestia de leer (si quieres salir un momento de tu burbuja), con la advertencia seria de que no te excuses en lo que no entiendas, si no que te centres en lo que si entiendas:
https://es.wikipedia.org/wiki/Algoritmo_divide_y_vencer%C3%A1s
https://es.wikipedia.org/wiki/Algoritmo_voraz

La mayoría de las cuestiones por las que preguntas tienes casi siempre algo que ver con algoritmos de grafos que resuelven complejos sistemas de combinatoria:
https://es.wikipedia.org/wiki/Categor%C3%ADa:Algoritmos_de_grafos
...aquí un índice genérico desde el que saltar a otras secciones:
https://es.wikipedia.org/wiki/Categor%C3%ADa:Algoritmos

Los artículos en español de wikipedia (me refiero a los artículos que tratan las mismas cuestiones que este foro) a menudo pecan de dos problemas:
- O excesivamente tecnificados: Caso de cuando lo edita un matemático, y el artículo ya solo resulta inteligible para otros matemáticos y nadie más.
- O excesivamente vulgar: Caso de cuando lo edita alguien con un conocimiento poco profundo del tema y entonces es una especie de colección de datos incoherentes y entremezclados, confusos o inexactos.
Pero en general es apto para todo el mundo (y es un buen principio antes de navegar por la web para seguir indagando si no se termina de encontrar lo que se buscaba o no queda satisfecho con lo hallado).



*NIH: "Not Invented Here"

Es el típico problema de 'postes y vallas'.

El problema básico es que hay que 'precalcular' el ancho efectivo a repartir...
Antes de indicar el reparto del 33%, debes contar los 'postes' y descontar el ancho que 'ocupan todos' del 'width', entonces ahora ese a ese 'nuevowidth' si puedes aplicarle el 33%, dará el reparto de 'valla' igual para todos (reusa el valor en vez de calcularlo cada vez), y ahora cada 'valla'  tiene un 'poste' (se desplaza la 'valla') 5px...

[puedes reusar una para varias cosas]

Solo una puntualización acotada...

- Tienes un montón de variables que sobran, puedes reusar una para varias cosas o incluir en el cout la operación cuando no vayas a reusar una variable más.

Es muy mala práctica reusar variables, salvo ciertos casos.
Si se tiene una función con varios bucles uno tras otro, no hay problema alguno en reusar la variable que actúa de contador, pués ese es su propósito.

En cambio si tienes una variable como 'mes' definida por ejemplo como entero, que más adelante no la precises y la reutilices, solo enfanga el código... si tiempo más tarde tienes que revisarlo, podrías encontrarte con que 'mes = -3147', cuando su nombre sugiere que esté acotado en un valor 1-12 (por ejemplo).

En fin, ahorrar algunos bytes de memoria (hace 30-40 años tenía cierta validez, por la escasez de memoria, y aún así se desaconsejaba), lo más probable es que a futuro te malgaste tiempo (que es mucho más preciosos que algunos bytes sueltos) si se convierte en una práctica habitual, tratando de comprender que hace tal o cual variable aquí o allá y porque tiene valores dispares. Si cada variable es nombrada conforme a su propósito y no reutilizada fuera de dicho propósito, el código será siempre fácil de seguir o por lo menos no inducirá a errores, aunque pasen algunos años sin tocarlo...

Lo que complica las fechas son los años bisiestos. Anulado dicho efecto, es un problema mucho más sencillo de tratar...

Yo tendría una enumeración en la forma:

Código [Seleccionar] Expandir


enumeracion DiasHastaMes
 dEnero = 1
 dFebrero = dEnero + 31
 dMarzo = dFebrero + 28
 dAbril = dMarzo + 31
 ...
 dDiciembre = dNoviembre + 30
 dAño = dDiciembre + 31
Fin enum
Es decir cada mes valdría el día absoluto del año. Y equivaldría al día 1 de dicho mes (nótese que puede considerarse el día 1 consumido o sin consumir, bastando cambiar para enero el valor 1 ó 0 según convenga cuando se adelante el bosquejo y se pase al código).

Por supuesto se mantiene la enumeración de meses... y pasaría los datos a un array. Nótese igualmente el 'AÑO'...

Código [Seleccionar] Expandir


Enumeracion MesesDelAño
 ENERO = 1
 FEBRERO = 2
 ...
 DICIEMBRE = 12
 AÑO = 13
fin enumeracion

array DiasHastaMes Mes(1 a 13)  
  Mes(ENERO) = dEnero
  Mes(FEBRERO) = dFebrero
  ...
  Mes(DICIEMBRE) = dDiciembre
  Mes(AÑO) = dAño


Me 'inventaría el mes 13' que es el 'año completo' que tendrá 365.

Desde esta perspectiva basta:
 1 - Contar el año inicial incompleto (si lo es)
 2 - Contar años completos (si los hay).
 3 - Contar el año final incompleto (si lo es).
Ahora el problema se fragmentado en 3 partes, la más sencilla de calcular es la segunda...

Código [Seleccionar] Expandir


Funcion CalcularIntervalosEntre2Fechas(fecha-string FechaInicial, FechaFinal)
   entero DiaInicial, DiaFinal, AñoInicial, AñoFinal
   MesesDelAño MesInicial, MesFinal
   entero dias, meses, años

   // La fecha inicial recibida se separa en año, mes y dia
   llamada a la funcion SepararFecha(FechaInicial, AñoInicial, MesInicial, DiaInicial)

   // Idem con la fecha final.
   llamada a la funcion SepararFecha(FechaFinal, AñoFinal, MesFinal, DiaFinal)

   // 1 --- contar año inicial incompleto:
   Si ((MesInicial> 1) o (DiaInicial >1) )  // Esto es si: (fechaInicial > "1 de enero")
       dias = dAño - (mes(MesInicial+1) - DiaInicial))
       meses = (12 - MesInicial)
       // años = 0
       AñoInicial + = 1
   fin si

   // 3 ---- contar año final incompleto.
   si ((MesFinal < 12) o (Dia < 31))    // Esto es si: (Fechafinal < "31 diciembre")
      dias += mes(MesFinal) + diaFinal
      meses += Mesfinal
      añoFinal -=1
   fin si

   // 2 ---- Contar años completos.
    Si añoFinal <= añoInicial)
        años = (añoFinal - añoInicial)
    sino
        años = 0
    fin si

   meses + = (años * 12)
   dias += (años * dAño)  // * 365
 
   imprimir dias, meses, años
Fin funcion

La función 'SepararFecha', es una función que separa la fecha según el formato de entrada en sendos parametros que devuelve por referencia... es superfluo definir una función así, queda a tu esfuerzo.

Nótese que en meses y años solo se cuentan como tales los que sean completos...
y noteses que como está hecho al vuelo, puede precisar algún ajuste del tipo +1, -1 en alguna parte...

Sería una limitación inútil, impráctico e imperdonable que un lenguaje restringiera los tipos que puedan usarse para programar un método.

...de todos modos este tipo de cuestiones, las resuelve uno mismo precisamente 'probando'... no se requiere preguntar, no va a explotar tu PC, por probar...

[revistas de informatica]

Ummm, posiblemente en la actualidad debas comprarte un libro, pero en otro tiempo no fue así, en los 80 los libros llegaban tarde, si llegaban y los lenguajes que usabamos en aquella época solo podias aprenderlos y practicarlos mediante revistas de informatica, cada semana en el quiosco, las revistas estaban al dia, los libros no.

Muchos libros y revistas tecnicas teniamos que ir a Londres a buscarlos para saber como eran las tripas de un Z 80......

Bueno, todo era cuestión de tirar del hilo.
Yo pedí a un amigo que se iba de vacaciones con su padre que trabajaba en Inglaterra (allá por el 70ytantos), que me trajera media docena (hasta donde llegara el presupuesto que le dí) de buenos libros... y a partir de ahí, fuí tirando de otros títulos de la editorial, de las referencias...
...y no en vano (por ejemplo hablando del ZX) tengo más de 100 libros dedicados solo al ZX-Spectrum. Amén de otros muchos de diversidad temática.
Más adelante logré encontrar alguna que otra librería técnica (al preguntar directamente a la editorial Anaya).

Si coincido que la publicación (de autores locales) de material técnico de calidad, no abundaba. Pero todavía había traducciones y por supuesto las sempiternas revistas. Lo difícil de las revistas es que salvo que te suscribieras, era (según donde vivieras), imposible que llegaran todas. Era muy típico que el contenido de una no era del todo satisfactorio y solo comprabas algunas no todas, en cambio de otras si que compraba uno todas... aún conservo la mayoría d elas que compré aunque con diferentes traslados siempre si pierde alguna caja, me duele haber perdido varias de "Microhobby" que era una que sí tenía completa... o las "Hack & Crack", que fueron muy poquitas...

Con internet todo cambió......

Ahí, sí...

Aunque siento que la gente joven de hoy, no sabe aprovecharlo bien.
Un libro físico, se puede perder, coger humedad, soltar páginas... pero si se tiene x libros en un disco, se pueden perder todos de un plumazo y como rara vez la gente suele hacer inventario de lo que ha descargado, no sabrá ni la décima parte de lo que haya perdido.
...y definitivamente el placer de leerlo en papel, no es igualable a leerlo en una pantalla.

Yo creo en el conocimiento libre. De igual forma que hoy leo gratis algún día escribiré y publicaré gratis si la vida me lo permite. Prefiero esa rueda que la de comprar cosas que no sé ni si están bien hechas

Bueno, creo que el conocimiento libre es una cosa y tener que comer es otra.
Yo no voy a un pintor y le digo que tengo que pintar la casa y me 'sale gratis', ni a un taxista si tengo que ir al aeropuerto, ni a un mecánico si tengo que arreglar el vehiculo... no sé porqué los que se dedican a la informática, han de hacer todo gratis... Un libro lleva su tiempo y publicarlo tiene un coste asociado, llegado el tiempo en que nadie compre, llegará el tiempo en que nadie publique. O mejor dicho, que se publiquen cosas de calidad... porque de mediocridad internet está lleno y eso es algo que precisamente sobra. Una internet donde cueste encontrar cosas de calidad, no es deseable.

Por otro lado, aunque cualquiera pueda escribir un libro, no cualquiera vale para escribirlo, no cualquiera hace ameno algo en principio infumable.

Hay algunas cosas importantes a tener en cuenta cuando se introducen contraseñas desde el teclado...
- Que estaba activado/desactivado el uso de las mayúsculas.
- Que el idioma del teclado para introducir la contraseña sea el mismo (algunos cambian de posición ciertas teclas, por lo que al creer introducir una lestras estamos introduciendo otras). Esto puede pasar (más) fácilmente si lo intentas desde un equipo que no es el tuyo... No es frecuente pero alguna vez ocurre.
- Cerciorarse de que en efecto, esa contraseña era de 'ese' archivo y no de otro que también se creó recientemente o de nombre muy parecido. A veces incluso puede uno haber creado dos copias con distinta contraseña, haberlo puesto en otra parte y luego tomar el de la primera, peor pretendiendo usar la contraseña dle segundo.

...Si me comprase todo lo que he leído tendría que hacer una hipoteca...

Ya. Pero al menos será verdad que alguno compras, no????.

Cualquiera que se dedique a la informática debería (en mi opinión), comprar algún que otro libro cada año. A la vuelta de 20-40 años te acabas haciendo con una biblioteca muy interesante.

...es curioso que la gente siempre tiene 10-50 euros para gastarse en cervezas, pero nunca para comprarse un libro.

jajja... "te enseño a pescar y me das el 15% de todo lo que pesques ...y caces..."

¡Cuanto "buitre carroñero" con cara de "paloma mensajera"!