hola chjcos,
solo un par de comentarios:
para Jose y de nuevo solo como orientacion (aunque realmente no sea quien para orientar a nadie)=>
Cita:
experimentando se me ha ocurrido hacerlo con una variable:
Código: Option Explicit
Dim Nombre As String
Private Sub Worksheet_SelectionChange(ByVal Target As Range)
Nombre = "si"
If Range("J2") = Nombre Then UserForm1.Show
Range("J2").Clear
End Sub |
me alegro que te animes a experimentar, creo que es la unica forma de aprender. Esto aparte te comento mi opinion sobre el uso de la variable en este caso:
si te fijas en tu propio codigo, realmente esto =>
Nombre = "si"
If Range("J2") = Nombre Then UserForm1.Show
es, en cuanto al objetivo buscado y al resultado obtenido, exactamente igual a esto otro=>
If Range("J2") ="si" Then UserForm1.Show
teniendo en cuenta que las variables ocupan/reservan un espacio de memoria y que lo ideal para [casi] cualquier aplicacion es intentar ser lo mas 'ligera' posible para facilitar y agilizar la ejecucion de sus tareas, lo normal, tanto con las variables como con cualquier otro recurso, es no utilizarlo si no es necesario o sirve para mejorar el rendimiento u otros casos.
en el caso de las variables, cuando realmente no van a 'variar', su uso se hace innecesario. En todo caso, podriamos utilizar una constante, dado que el valor buscado va a ser siempre el mismo (Si) y que ademas no consume recursos
a esto añadele que:=>
.- cuanto mayor es el alcance de una variable (procedimiento < modulo, private < public, ...) mayor tiempo esta consumiendo recursos,
.- [ aunque de esto no estoy 100x100 seguro] en el caso de que este a nivel del modulo de una hoja una vez inicializada la variable se mantendra toda la sesion consumiendo recursos hasta cerrar el libro
.- el declarar una variable fuera de un procedimiento suele tener sentido porque queramos disponer de ella en diversos procedimientos (o en el mismo pero en diferentes momentos) teniendo acceso a su ultimo valor asignado aunque el procedimiento que la modifico por ultima vez ya haya concluido
(digamos que una variable declarada dentro de un procedimiento Sub o Function muere/se extingue con el propio procedimiento, mientras que al declararla a nivel de modulo, si el modulo es de objeto sera accesible para los procedimientos de ese modulo hasta que el objeto propietario de ese modulo se descargue. Finalmente, para declarar una variable accesible desde cualquier procedimiento de cualquier modulo de un proyecto debe hacerse en un modulo NORMAL y declararla como Public)
Cita:
|
"como no sabía como interrumpir la aparición del UserForm, he tenido que meterle la expresión Clear que no creo que sea la más adecuada."
|
en realidad, y esto enlaza con el siguiente codigo que expones, no se trata de 'interrumpir' la aparicion del formulario, sino de no mostrarlo mas que cuando nosotros hayamos decidido Aunque parece una obviedad, cuando de eventos hablamos quizas no lo sea tanto
ten en cuenta que los eventos son un tipo de procedimientos que se ejecutan SIEMPRE (salvo que los inhabilitemos en caso de poderse) que 'SUCEDE' la 'accion' que lo desencadena. Esto quiere decir que si el codigo que introduzcamos en el evento provoca que 'suceda' la accion desencadenante del evento, y salvo que tomemos las debidas precauciones, se puede entrar en un bucle infinito
y en el caso de los eventos de hoja (al menos Change y SelectioChange) se disparan siempre que el suceso correspondiente (cambiar algo para Change y cambiar la seleccion para SelectionChange) se produce en cualquier parte/celda/rango de la hoja
para limitar la ejecucion de nuestras instrucciones a las ocasiones que deseemos (pej. que solo se ejecuten cuando el cambio se realiza en una determinada celda) estos 2 eventos exponen/proporcionan el parametro Target, que hace referencia a la celda/rango en la que esta 'sucediendo' el desencadenante del evento (es decir, para Change la celda en que se realiza el cambio).
asi, pej. para Change, podemos comparar si Target (celda modificada) es la (o una de las) celda que a nosotros nos interesa=>
If Target.Address = "J2" then .... y realizar las acciones solo si este es el caso, o =>
If Target.Address <> "J2" then Exit sub => si no es el caso salimos sin ejecutar las acciones
esta es solo una forma de condicionar el codigo, existen muchas otras, pero en general, casi siempre que usemos procedimientos de evento, debemos condicionar la ejecucion de nuestro codigo a solo las circunstancias requeridas, si no queremos correr el riesgo de llevarnos mas de un disgusto
de todas formas los eventos son muy suyos y, al menos en mi caso, conseguir conocerlos a fondo (si es que es posible) lleva su tiempo y sus tropiezos
Cita:
|
"... si le pones el sí con mayúsculas, no las lee"
|
echale un ojo en la ayuda a las funciones UCase y LCase
bueno, disculpad el rollo, pero solo por si ayuda a ir entendiendo mejor este tingaldo (OJO: no me hagais caso del todo y en cualquier caso intentad contrastarlo por si acaso)
en cuanto a JMER, si ya has decidido como hacerlo pues bienvenido sea, aunque me da la impresion, por tu ultimo mensaje, que, o hay algo que no has acabado de exponer o que no has expuesto correctamente, o que quizas has hecho un poutpourri con el/los codigos de Jose y el/los mios. Pero bueno, lo dicho, me alegro que al menos puedas tirar y lamento no haberte podido ser de mas ayuda
un saludo
Ivan
usser forrm 
Mode Lineal
