Devolver lo invertido, cuando el precio se ha triplicado... resulta gracioso... ya quisiera ver si harían lo mismo se el precio se hubiera "trividido"...

Curioso... en la wiki española pone algo muy distinto:


Vamos, que ahora los alcohólicos podrían llamarse: "noetilfóbicos"... siguiendo el mismo esquema... parece que desconocen el significado del sufijo 'filia'...

En el evento 'changed' compruebas la cantidad de caracteres que lleva escritos, si es igual o mayor que la cantidad deseada (3 en tu caso), buscas en una colección de textos que quieras buscar (se supone que es una colección que mantienes internamente o externamente) y extraes una subcolección que coincide con ese patrón, si la colección devuelta contiene al menos 1 elementos, lo cargas en una lista que haces emerger ('popup'), debajo del textbox (en general, aunque también vale bajo el cursor si no está muy alejado del textbox).
Si no se usa un método popup, todavia puede ser fácilmente imitado, con una objeto invible con un alto para 5 ítems (o los que tu quieras, si son muchos mejor una lista, para que tenga scroll, sin tene rque porveerlo tú), en tal caso, si el patrón del usuario devuelve entradas, las pegas al control que actúa de contenedor, lo posicionas bajo el textbox, en primer plano y lo haces visible. Luego cuando el usuario seleccione un ítem de la lista, lo copias al textbox y haces invisible la lista. Un banderín debiera indicar 'seleccionado', para luego desactivar ya mostrar la lista, mientras no se borre la entrada, o bien ocultarlo simplemente cuando no coincida el patrón (no se encuentre coincidencias), y cuando se pulse en un ítem de dicha lista. y si se vuelve a cambiar el contenido del textbox, nuevamente operar como se ha indicado...


Al caso un control 'ComboBox' ya hace todo eso por tí mismo, con la salvedad que muestra la lista completa que contiene... es decir avanza hasta el ítem coincidente con la entrada en la caja de texto, pero muestra todos, incluso aunque no coincidan. Pero vamos te ahorra mucho trabajo usarlo (con respecto a montarlo por tu cuenta como te comentaba en el párrafo anterior). Tu solo debes encargarte de mantener la lista que debe contener la parte de lista del combobox (por ejemplo los messes del año, y luego el usuario escribe 'm' en la caja de texto, se selecciona marzo, cuando avance a 'ma' todavía sigue en marzo, pero cuando avance a 'may' ya se selecciona mayo.

Otra diferencia de este control, respecto de lo que tu quieres es que la selección busca con cada carácter entrado, no es posible indicar como preciso x caracteres... podría desactivarse la parte de lista del combobox, hasta que tenga 3 caracteres, pero eso exige subclasificar o bien modificar la herencia del control, en ambos casos es mucho trabajo para tan poca cosa. Si requieres que sea así, mejor acometer lo señalado en el primer párrafo...

No importa lo complejo de un sistema, la cuestión es que solo se 'carga' lo que se necesita usar. Por ello el diseño debe ser eficiente.

Las dependencias deben ser realistas... si es objetiva y realmente dependiente, se hace dependiente, si no, no.

Una rueda tiene atributos, como numero de radios, diámetro, ancho, número de tornillos, marca, etc... luego es razonable que todos esos atributos sean propiedades de las ruedas. Luego la cargar una rueda (crearla, referenciarla) todos sus atributos estarán disponibles. Y todo vehículo tiene una cierta cantidad de ruedas, luego las ruedas será algún tipo de colección, que tienen todos los vehículos, pero que cada implementación de vehículo tiene un valor diferente. Sin embargo si cambias una rueda, deberá del mismo tamaño que el resto, esto es debe encajar... así que debiera haber constructores específicos para cada tipo de vehículo.

Piensa con cosas cotidianas, manejables que puedas fácilmente entender el porqué de ello.
Un simple ejemplo:

Una interfaz (es una clase que) define una plantilla básica y que luego cada implementación puede particularizar.



Como se puede ver algo simple, pero fácil de entender y seguir el ejemplo... tiene varios atributos de solo lectura, y tan solo el color es lectura y escritura. Como es una bicie, no tiene motor ni puertas, además fuera de la interfaz que implementa se han añadido dos atributos aparte, NúmeroDePiñones y NumeroDePlatos... faltaría a la interfaz un método 'cambiarDeMarcha' y añadir un atributo 'NumeroDeMarchas'... la bicileta también tiene...

Como ves cuando se 'carga' un vehículo, con él se carga todo lo necesario, porque forma un 'objeto', todo englobado en la clase, un único objeto engloba a todo, pero puede estar formado por varios objetos, un motor podría ser otro objeto en sí mismo, lo mismo que las ruedas y las puertas... básicamente cualquier cosa que sea más compleja que una mera propiedad. Fíjate como aunque no hemos definido una clase Rueda, al crearla sin embargo le estamos pasando algunos atributos necesarios para crearla, y tras ello, incluso modificamos un atributo (donde está situada la rueda), que no se incluye en el 'constructor'... en cambio al crear el objeto bicicleta, solo se reclama el atributo color, el número de ruedas es prefijado por el diseño propio de la bici, lo mismo sucede con 'motorizado' y 'tienepuertas'.  Un diseño mejor sería tener un atributo llamado NumeroDePuertas, en sustitución de 'TienePuertas', ya que 'número identifica cuantas son, y al caso '0', es lo mismo que 'no tiene'. Es decir una primera aproximación se define y luego de repensarlo haces cambios y ajustes...

Como ves no es necesario cargar nada más que lo que respecta al vehículo... pero eso está en su propio diseño. si ahora creas un objeto ciudad, tendrás por un lado objetos calle, objetos edificios y objetos vehículos, incluso objetos garaje.
Cada uno de ellos sería una colección, pero incluso así, una ciudad tendría atributos como 'nombre', 'extension', 'ubicacion', etc... pero es necesario cargar todos los vehículos de la ciudad?... No, tan solo los de la calle actual.
Siendo calles una colección de la clase 'Calle', y poseyendo cada calle una colección vehículos (que circulan por ella), bastaría cargas solo esos. A su vez cada vehículo podría tener un atributo 'calle', para referenciar al objeto calle en el que se encuentra.
Cuando se cambia de calle (otra distinta), se descarga la previa para cargar la nueva...
Intenta diseñar un objeto calle, edificio y ciudad.

Una colección es una lista de objetos que puede ser tanto homogéneos como heterogéneos, el diseño estbalece lo deseable y al caso, suelen abundar las colecciones cuyo contenido son del mismo tipo "Colección de tipo x"... una colección tiene métodos tales como: añadir (al final), eliminar (del final), insertar (en cierta posición), Borrar (de cierta posición), vaciar (por completo), listar (desde x hasta y), enumerar (todos), Devolver (el enésimo objeto en la colección), y algunos más complejos como 'UnirAOtraColeccion, Clonar, Copiar, etc...
y suele tener atributos del tipo: Vacia, Cantidad, Tipo para señalar si la colección está vacía, cuantos objetos contiene y el tipo de objetos que aloja. Incluso puede hacerse uno como actual y tener un atributo IndiceActual, que puede ser leído y cambiado...
Según la necesidad se crea o no, por ejemplo en una bicicleta, la colección ruedas, no precisa un atributo 'indiceActual', además siendo sólo 2 es fácl acceder a una y saber cual de ellas es (trasera, delantera), pero (por ejemplo) en una ciudad saber el nombre de la calle actual seleccionada, si resulta conveniente... ya que por ejemplo podría ser deseable 'conducir' un vehículo a dicho destino.
Así, un método Conducir (a la calle x)... movería un vehívulo hacia dicha calle, haciéndolo más complejo, debería encontrar el trazado desde su ubicación actual hasta el destino, y al llegar allí detenerse  y avisar...

Piensa en objetos de la vida real y trata de 'visualizarlo' todo desde esa perspectiva de la manipulación, propiedades que tienen y lo que se puede hacer con ello...

Es lo que vengo aconsejando a muchos conocidos desde hace la tira de años, que tapen la cámara con un simple post-it, de esos semitranslúcidos.

...sin embargo es enormemente criticable que el propio hardware, no traiga una simple ventanita deslizante, giratoria, etc... que imposibilite que incluso aunque un intruso llegara a activar la cámara, pudiera enfocar al usuario. Y dado lo sencillo y barato dle sistema, cabe preguntarse por qué... por qué no lo hacen. Es simple y llanamente: negligencia.
Si un día utilizan tu cámara sin tu permiso, desde luego yo pondría una denuncia al fabricante, precisamente por negligencia, es algo tan simple y lógico de prever, que no ponerle remedio responde exclusivamente a negligencia.

...pero la gente se ha acostumbrado (YA) a tragar por el 4N0... 

Cuántas vueltas...
Bastaba decir que se basa en la arquitectura ARM Cortex-A53, que no se ve afectada por dichos problemas (exactamente la misma que mi tf. y otros muchos modelos), tal y como publicó ARM.

mmm... "nomofobia"?. Ese palabro parecería tener sentido para un significado tipo: "fobia a los gnomos de jardín". aunque al caso, mejor si fuera gnomofobia.

En cualquier caso, el sufijo 'fobia' es miedo... sería la antítesis a la adicción...

Quizás la palabra adecuada fuera mejor algo como: "fonoadicto".

Sin llegar a acusación, si no solo sospechas... Creo que Mediakarkt, realiza ofertas falsas con la única finalidad de captar clientes...

En dos ocasiones este año pasado, me ha sucedido ver una oferta que me pareció interesante y justo el mismo día de la oferta (o al día siguiente, pero en ofertas que duran entre 7 y 15 días)), intentar hacer la compra, con un subsiguiente mensaje de: "Stock agotado"... que sería la forma en que limitan la posibilidad de que alguien acceda a dicha oferta falsa, irreal...
...en esa línea es que creo que se encuentra este caso que se comenta en la noticia, solo que al poner la 'oferta falsa', han fallado  (olvidado desviar) en dirigir el pedido a la respuesta de: "stock agotado"... lo habrán procesado y solo cuando se han dado cuenta de que no frenaron para esa 'oferta', es cuando han decidido liquidar por las malas el asunto...

Mmmmm... se te ha olvidado una cuestión importante: ¿para qué quieres hacer eso?.

Y te señalo por qué es importante.
Supongamos que tu idea es intentar bloquear "programas maliciosos", en este caso, lo más probable es que no sea efectivo al 100%. y te lo razono.
Imagina un programa malicioso, supera cierto nivel de carga de CPU y lo matas, ok... 1 minuto después ahí está otra vez... entonces aunque sea con interrupciones, su tarea sigue adelante, solo que más demorado en el tiempo.

Un programa malicioso, en general si está medianamente bien programado, no opera sólo, siempre están al acecho, son otros ejecutables los que lo lanzan y que 'pasan' por 'buenos', nada raro ni sospechoso en ellos se detecta... es decir el programa que ejecuta la tarea maliciosa, es 'contratado' por otro programa que lo pone en marcha (algo así como cuando alguien contrata un asesino para matar. Él que quiere que muera alguien y la persona que lo mata, si no quiere (ensuciarse las manos y arriegarse a) ser descubierto, es otra, no la misma. Más aún ni siquiera 'habla' directamente, con el que hace el 'trabajo sucio', si no que busca un intermediario...

Así, resumiendo: un programa malvado (A), tendrá una apariencia limpia, y su única tarea será arrancar otro programa (B). Es B, quien de cuando en cuando revisa si el programa que hace el trabajo sucio (C), está en marcha o no, y si no lo está lo manda ejecutar... Así si ya resulta difícil asociar B con C, mucho más A con C.

Luego en efecto matar un proceso, no es todo lo efectivo que es deseable si el objetivo de tu programación, es librarte de procesos 'maliciosos' o solo 'indeseables'. Debes investigar el padre del (proceso) mismo y a su vez al padre de ése y así respectivamente. A veces no es fácil, porque resulta difícl rastrear sin meterse a fondo en el tema. Un programa puede arrancarse, realizar alguna ejecución y luego pararse... al caso, entonces resulta conveniente consultar las tareas programadas... A veces incluso un programa descomprime de un archivo cifrado, otro y lo ejecuta... más aún imagina por ejemplo que tengo dos ficheros, un ejecutbale maligno y un fichero comprimido en zip, rar, 7z, etc... le das una orden de extracción al mismo y a su vez tras ser extraído, es autoejecutado (caso típico de instaladores, que descomprimen y/o decodifican y se ejecutan), tras lanzar esto se desvincula de su marcha y s epara, así la autoría incluso parecerá proceder de winrar, winzip, sevenzip, etc... para todo ello, como te decía debes meterte a fondo y suscribirte a eventos de carga de procesos, peor incluso así, hay virus que se las apañan, para saltarse el control del sistema...

En definitiva, según para qué lo quieras, lo que tienes es suficiente o te quedas a medias. Si por ejemplo tu idea es matar procesos de programas que mina (criptomonedas) en tu equipo (tan de moda en los últimos meses), si es abusivo, puede ser efectivo, pero si no pone el procesador a un nivel muy elevado (digamos que lo deja en un 3-7%), seguirá ahí latente... y si pretendes matar procesos que sobrepasen un 5%, básicamente te vas a cargar a todos, porque en algún momento, todos los programas alcanzan ese valor y lo superan intentasamente.

Sería más sensato, hacer estadísticas, es decir descubrir procesos que sobrepasen ciertos umbrales y registrarlos (nombre de procesos, valores alcanzados y tiempo que permanecen por encima de cierto umbral y frecuencia con que esto sucede), al tiempo consultar dicha estadística y sacar conclusiones... después de eso se supone que lo que hagas tendrá una lógica más acorde que la simpleza de matar al que 'se rebela'...

Por otro lado hay programas legítimos, que en algún momento dado pueden tener picos de trabajo y en general tiene programado que si se para se ponga de nuevo en marcha... hasta x veces, luego ya no se vuelve a cargar hasta la próxima sesión... pero como decía si es legítimo, puede que al matarlo estés impidiendo alguna acción absolutamente necesaria que podría incluso colgar el sistema o generar un reinicio.

...hay más tela que cortar al respecto, pero tampoco es plan de que te sientas atosigado, con toda la panoplia de características...

Uhmmmm... el texto es insuficiente no da detalles precisos, resulta vago, veo de descargarme el vídeo para verlo en otro momento con tiempo... peor creo que no van en la 'buena dirección'...

La solución tiene que ser HARDWARE, de fábrica, nada de webs, ni correos ni leches. Todas las capas que se quiera encima, pero si al fondo no está basado en HARDWARE, siempre será penetrable.