¿Seguro que es es la descripción que te han dado o el resumen que tú haces...?
Es que es ambigüo, tiene múltiples interpretaciones, y en el mundillo de la programación el enemigo número 2 es la ambigüedad.
Yo podría interpretar (por ejemplo), que dado un punto en un fichero se localice el comienzo y final de una palabra, o de una frase... deduciría esto si estás estudiando por ejemplo operaciones con cadenas... es decir si hay un contexto que puede usarse para resolver la ambigüedad.
Ante las dudas reclama a tu profesor más claridad y detalles.
 
Considera que las líneas en blanco también cuentan.
Sería tremendamente molesto que se diera el índice de una línea de código desechando las línea en blanco, casi que obligaría a uno a contarlas a ver cual es... siendo una posición absoluta basta mirar la línea que se señala.

La mayoría de IDEs enumeran las líneas, en cambio es raro en editores de texto plano, luego en ese caso toca contar.
 

Ni hace falta mirar el código... cuando dices que te dan valores muy elevados.

Debes usar un array temporal, para mantener los valores que se van calculando, de otro modo acabas multiplicando por un valor ya calculado, varias veces...


p.d.: Nota que A, en realidad es también temp...
Te lo resumo, nota como la solución se devuelve en un array por referencia... y los arrays de origen no se alteran.

En vez de complicarte eliminando espacios, simplemente sáltalos.
Tendrás 2 punteros, el de posición de lectura del principio, y el del final.
Mientras un cáracter sea espacio (ó puntuaciíon: ',' '.' ':' ';', paréntesis, etc..) avanzas sin hacer la comparación, así llegas a un carácter comparable.
Luego igual desde el final, cuando localizas dos caracteres comparables, es cuando realizas dicha comparación.

Es realidad, es preferible hacer saltos, simplificando la lógica, es decir mientras no sea un carácter saltar al siguiente...


Con este pseudocódigo para evitar que devuelva como palíndromo un texto que no contuviera ni un solo carácter, alfabético en el rango AZ... se controla, desde la última línea del bucle, solo si se ha ejecutado al menos una vez una comparación satisfactoria, 'pal= TRUE'.

...y es de suponer que la capitalización no debe ser un obstáculo para considerarlo palíndromo, pero esto último abórdalo solo cuando hayas solucionado el problema y te funcione bien.

Esos tiempos, se imponen (entre otras cosas), para impedir que la gente 'abuse' (en realidad para molestar a los que bajan mucho para señalarles que si tienen una cuenta de pago, esos tiempos de espera no se dan, porque desde luego quien no se va a crear una cuenta d epago, es quien solo descargue algo una única vez o algo cada variostantos días)...

Luego no podrás saltarlo sin más... tendrías que hacerle creer que se trata de otro usuario, que procede de otro lugar y usa otro equipo... es decir tendrías que ver que datos recoge el sitio de tu equipo, que luego utiliza para reconocer que 'eres tu otra vez'... y ver de proveerle datos distintos cada vez. La cuestión de la IP, MAC, etc... es lo más obvio.

No hay ningún evento en el combobox, que actúe sobre la lista desplegable, al momento que tu vayas cambiando la selección con el ratón. El evento click, es tardío, cuando ya has seleccionado el ítem. El resto de eventos se refieren justo a la parte no desplegable (como mousemove, mouseenter or SelectedIndexChanged, por ejemplo).

Tampoco te vale imitarlo mediante un textbox y un listbox, tal que al pulsar el textbox, se haga visible un listbox y cuando se seleccione un ítem de esta o pierda el foco, se oculte. Porque el listbox, no cambia dinámicamente entre items a medida que el cursor se va desplazando por la lista, si no solo cuando se pulsa en un elemento.

Para lograr hacer lo que quieres tendrás que enfangarte y crear tu propio usercontrol imitando un combobox. Ahora, merece el esfuerzo necesario solo para mostrar en un label un ítem que en sí mismo ya se ve en el combobox... No es acaso precisamente esa función la del desplegable del combobox?.

Yo acabo de terminar de ver "Cowboy Bebop", que es una serie con actores reales, siguiendo las andanzas de la serie anime japonesa de finales de los 90.

El personaje del perrito "Ein", está subexplotado en esta temporada, es de esperar que en las próximas tenga el papel que se le debe dar.

Los protagonistas son cazarecompensas en un mundo post-apocalíptico, donde excepto la tecnología, el resto parece igual. Ni van sobrados de virtudes, ni de humanidad, como la vida misma.

A juicio mío, se acabará convirtiendo en una serie de culto, si continúan por esa línea...

Hay algunas discrepancias...

Primero los valores de precio y suma total admiten decimales, luego declarar a 'TotalContado' y 'TotalCredito' de tipo integer, limita la precisión del cálculo, es decir legalmente no se admitiría y comercialmente despidirían al programador...  

Luego, estás sumando en base a un registro que has leído para una determinada factura (reg2), pero en realidad cada factura tiene su propio indicador. Es decir estás aplicando a toda la facturación del fichero el criterio de pago de un único registro, luego si ese registro fue 'pagado' al contado todo el listbox, sumará sus valores como si fueran pagos al contado (y pagos con tarjeta no sumará nada, luego 0), y viceversa..., si ese registro fuera pagado con tarjeta de crédito, todo el listado se suma como si fuera pagado con tarjeta de crédito (luego el pago al contado será 0).

Puedes elegir entre leer e ir sumando del fichero o con lo que aparece en el listado.
Si tiras del listado, debes leer cada línea, hacer el split, pero no a un string, mejor volcarlo a un registro...  

Nota que el orden de los campos, debe coincidir con el orden en que fueron serializados... para recordarlo, pongo aquí dicha función (si la modificaste,  lógicamente debes equipararla (la función FromString) con los cambios que hiciste).

Private Function SerializarRegistro(ByRef Registro As RegCompra, ByVal Separador As String) As String
    With Registro
        SerializarRegistro = CStr(.NumTicket) & Separador & .Producto & Separador & CStr(.Cantidad) & _
                            Separador & CStr(.PrecioUnidad) & Separador & CStr(.SubTotal) & _
                            Separador & GetMetodoPago(.MetodoDePago) & Separador & CStr(.FechaCompra)
    End With
End Function
 
Private function FromString(byRef Linea As String, optional ByRef Separador as String = vbTab) As RegCompra
    dim campos() As string
 
    campos = Split(Linea, Separador)
    With FromString
        .NumTicket = CInt(campos(0))
        .Producto = campos(1)
        .Cantidad = CInt(campos(2))
        .PrecioUnidad = CSng(campos(3))
        .SubTotal = CSng(campos(4))
        .MetodoDePago = SetMetodoPago(campos(5))  ' función que se añade debajo... ' CByte(campos(5))
        .FechaCompra = CDate(campos(6))
    end with
end Function
 

Igual que teníamos la función 'getMetodoPago, que traducía '0' ó '1' a un texto más descriptivo, ahora necesitamos la función inversa:

Private Function GetMetodoPago(ByVal Metodo As MetodosDePago) As String
    If (Metodo = PAGO_AL_CONTRADO) Then
        GetMetodoPago = "Contado     "
    Else
        GetMetodoPago = "T. Credito  "
    End If
End Function
 
Private Function SetMetodoPago(ByRef Metodo As String) As MetodosDePago
    If (LCase$(Trim$(Metodo)) = "contado") Then
        SetMetodoPago = PAGO_AL_CONTRADO
    Else
        SetMetodoPago = PAGO_CON_TCREDITO
    End If
End Function
 

Lógicamente si dejaste como texto "0" ó "1", entonces bastaría una conversión:
 .MetodoDePago  = cbyte(campos(5))
en vez de la llamada a esta función

Ahora la suma debe modificar la lógica...
Reg2 es obtenido con cada línea, luego el valor 'metododepago' es actualizado justo con cada factura y por tanto se suma al total que procede...

    Dim totalcontado As Single  ' <-------- no olvides cambiarlo.
    Dim totaltcredito As Single
' ...
' ...
' ...
 
            For h = 0 To List1.ListCount - 1
                reg2 = FromString(List1.List(h), vbTab)
 
                If (reg2.MetodoDePago = PAGO_AL_CONTRADO) Then ' valor 0
                    totalcontado = totalcontado + reg2.SubTotal    'Val(Split(List1.List(h), vbTab)(6))
                Else 'If reg2.MetodoDePago = "1"  Then
                    totaltcredito = (totaltcredito + reg2.SubTotal)    'Val(Split(List1.List(h), vbTab)(6))
                End If
            Next
'...
 

Por último, nota que en función de la complejidad de cada línea puede ser preferible leer del fichero de nuevo cada registro, o del listado dando formato a cada campo... ...como operabas desde el listado he modificado desde ahí.

Si un fichero fuera enormemente grande, lo más probable es que un listado contuviera solo una cantidad predefinida máxima de facturas (no todas las que un fichero tuviere, imagina 100.000 ó 1 millón), por lo que uno debe decidir si lo que suma es el total del fichero o solo el total del contenido en el listado. Piensa además que un listado puede estar filtrado (no solo por la cantidad de líneas que deba contener), sino por cosas como un rango de fecha, por ejemplo 'todas las compras de diciembre de 2021'... en fin es una lógica que hay que tener presente, no siempre sumar todo lo que el fichero contiene, si no sujeto a determinados criterios de filtro.

¿Podrías aclarar, porque alguien debe ayudarte con eso?. ¿Qué impedimento tienes que te impida buscarlo por tí mismo?. ¿Necesitas que te arropen esta noche cuando te acuestes?.

Si lo solicita (aparece en las opciones al instalar), permite formatear la unidad a bajo nivel, ese formateo a bajo nivel realiza ese chequeo de disco.

Instalando sin formatear a bajo nivel, incluso (casualmente) puede finalizar, pero claro, cuando intente acceder a alguno de los ficheros ubicado en sectores dañados, se colgará. Siendo una isntalacón reciente dará mucho pesar y de qué pensar...

El compilador no hace según qué optimizaciones... pero de modo general pueden hacerse 3 o 4 fases de optimizaciones.

- Cuando se completa el análisis semántico, hace una optimización de código entre operaciones sencillas, del tipo si se suman dos constantes, remplazarlas por una sola constante ya sumada. Si hay una cascada de sumas, utilizar un registro destino (acumulador), para ir almacenando (algo como x= b +c) ; y= (x + v): z= (y +s), se convertiría en: mov regz b; add regz c; add regz v; add regz s, si se hace el a´rbol sintáctico entre uno y otro se verá la cantidad de instrucciones que se evitan), también por ejemplo cosas como si se multiplica o divide por una potencia de 2, cambiarlo por un desplazamiento a derecha o izquierda, etc...  Esta optimización suele ser a nivel de expresiones.

- Tras esa optimización hay una más global, a un nivel mayor, que suele consistir por ejemplo, en sacar de un bucle ciertas operaciones que bastan ser calculadas una vez antes del bucle...bifurcaciones para las que puede calcularse una dirección de desplazamiento relativo (casos de Select case (switch) o if...elseif..elseif... Así, se hace un cálculo inicial, se suma a la dirección actual y se salta al punto exacto, en vez de comprobar caso por caso (cuando esto e sposible, lo que queda recogido en el árbol sintáctico cuabndo se realiza dicho análisis)), múltiples llamadas a una rutina que pueden yacer como una única llamada, etc...

- Cuando se convierte a código objeto, también suelen hacerse optimizaciones. Esta suelen utilizar mucho la notación polaca inversa a la que el código se ha ido convirtiendo y que permite encontrar fácilmente ciertas optimizaciones basado en lo que permita el diseño del tipo de código objeto generado.

- Finalmente cuando se compila para la plataforma destino, conforme a las instrucciones que admita, suelen hacerse optimizaciones que son dependientes del hardware destino. En generla aquí se decide en muchas ocasiones si ciertas construcciones son más efectivas utilizando una pila o los registros del sistema. Sin conocer la plataforma destino, estás optimizaciones no pueden asegurarse que lo sena, por eso se demoran hasta dicho momento.

---

El S.O. mantiene búferes de archivos, en general a veces lejos de ser efectivos, suponen un lastre. Lo ideal es que un S.O. base la decisión de utilizar o no búferes en base a si el usuario abre un fichero para lectura, escritura, lectura y escritura, y aún así si no vas a hacer múltiples lecturas al mismo punto, puedne no ser efectivos. En general el S.O. no tiene mucha libertad de elección, o mejor dicho, si hace ciertas elecciones no tiene garantías de que sena acertadas, después de todo no es un compilador y no tiene que procesar nada al respecto, son decisiones 'generales' que no pueden personalizarse para cada programa.

En cambio el driver del disco (el código interno del fabricante, no el que proporciona el S.O.)... en general leen como mínimo un sector, así tu le digas que solo necesitas un byte, y luego otro y otro... pero pueden hacer acopio de búferes mucho mayores, los detalles exactos quedan a cubierto porque queda dentro del hardware del propio disco, y en general sirven de caché, de modo que si luego solicitas un acceso de lectura al mismo sector, lo provee del buffer en memoria que mantiene, en vez de leer estúpidamente de nuevo otra vez del disco. Esto actualmente ha aumentado dado que el precio de chips de memoria han bajado y las velolcidades de RAMs son mayores que las lecturas mecánicas (hoy puede afirmarse que los discos duros son híbridos entre esa tecnología cierta cantidad de RAM en froma SSD oculta, eso mismo lo hace bastante frágil a fallos ante determinados problemas), así un disco duro, puede tener una velocidad mucho mayor que la que obtendría si con cada petición tuviera que leer o escribir en el disco físicamente. Proporcionan acceso al S.O. a ciertos búferes como una caché, pero no hay forma de saber si dicho búffer será mucho mayor que lo que el S.O. solicite...

Dicho de otro modo, si el programador no provee cierta soltura con búferes propios, no será igual de íptimo, porque incluso auqnue el S.O. mantenga una caché y el propio disco lo provea máyor, todavía el tiempo de verificar si una dirección solicitada consta en la caché, consume algo de tiempo.

En consecuencia, el programador debiera para manejo de grandes volúmenes de datos proveer un array de tamaño múltiplo de un sector, y tirar de bucles (aunque luego lo limites, si resulta que el volumen leído supera el tamaño actual del fichero (pudiera estar relleno de 'urliburly').
Por supuesto si un fichero ocupa menos de un sector, no tiene sentido proveer un array de mayor tamaño, salvo que haya un bucle que lean un fichero y opere en él y al término otro, etc... en este caso, proveer un array de cierto tamaño, permite que sea memoria reservada para todo ese bucle externo, de otro modo será un array que se genera de nuevo para cada fichero con que se va a operar...

Aunque un S.O. el disco y los compiladores intenten ser efectivos, no realizan nunca manipulación del programa al nivel que tu esperas, el compilador JAMÁS debe modificar la semántica que el programador ha provisto (salvo corrección de errores corregibles de los que además debe avisar). El S.O. no está obligado a más que proveer un sistema de caché (que muchas veces es inefectivo, si lo que tratas de hacer es leer no más de una vez cada dato) y lo que el disco hace queda alejado del programa, por tanto se limita a proveer algortimos basado en heurísticas de frecuencia de uso, para decidir el tamaño de los búferes internos por encima de lo que el S.O. demande... por supuesto deberá descartar, cuando yerre.

El peso finalmente de la optimización depende básicamente del diseño del programador, procura ceñirte a ello.