Identificar un hijo

[Drumpi]

Hola a todos:

Son las 4 de la mañana y no puedo parar de darle vueltas.
Si habeis visto el hilo de mi editor de mapas de tiles, habreis visto que he creado lo que he llamado un botón-slider: se comporta como un botón, pero si lo mantienes pulsado puedes modificar su valor como si fuera un slider, en lugar de incrementos predefinidos.

Bueno, pues resulta que por exigencias del programa debo congelarlos en un momento dado, y como el valor que contienen lo leen mediante un puntero y lo escriben con write_int, pues este se puede actualizar perfectamente en cualquier momento.
Pero no la barra que indica el porcentaje del valor. Tengo que hacerlo con una función desde fuera.

El problema es que el botón-slider usa tres gráficos diferentes: el gráfico de fondo que se lo asigno al propio proceso, el gráfico del botón que cambia si está pulsado o no, y la barra. Estos dos últimos están asignados a sendos hijos del proceso botón-slider, ambos se llaman igual, son procesos-dummies (procesos en permanente estado de congelación).

Y esa es la pega ¿Cómo distingo ambos hijos? En principio pensé en size_x, pero en un momento dado ambos tienen dicho valor a 100. Luego en FILE, pero también pueden tener el mismo.
Luego pensé en la variable SON ¿Esta devolvía cada uno de los hijos en las diferentes llamadas? ¿En algún orden en particular? ¿Hay alguna forma de saber el ID del último proceso creado por este proceso?

[SplinterGU]

SON es el ultimo hijo creado

tambien tenes:

BIGBRO es el hermano mas viejo del proceso(se creo antes)
SMALLBRO es el hermano mas joven del proceso (se creo despues)

por otro lado podrias (mas seguro):

- asignar un nombre a cada proceso con una local o publica
- guardar en un vector o struct los ids de los procesos dummy que creas segun su tipo (bckg_graph_pid, button_on_off_pid, level_ pid) y pasarlos al proceso externo o que esten en el proceso padre en una publica y el proceso externo los lea de ahi

[panreyes]

La idea de FATHER y SON es perfecta, pero BIGBRO y SMALLBRO me parecen peligrosos xD

Instancias un proceso, y quieres cambiar algo externamente:
son.x=4385384;

Luego instancias otro, y quieres cambiar etc...:
son.y=2398234;

Pero para volver a acceder al anterior, o al siguiente, o al que no sea el más reciente, debería hacerse siempre por variables propias.

BIGBRO y SMALLBRO deberían desaparecer del diseño, en mi opinión.

[Drumpi]

Es que por lo que he entendido de la wiki, un BIGBRO puede ser un proceso creado a continuación, aunque no sea hijo, padre, abuelo o nieto del anterior :P
Si SON me devuelve el último hijo de dicho proceso, es justo lo que necesito. Es que sacar el ID fuera son ya demasiados parámetros, el botón-slider tiene actualmente 18 entre posición, gráficos, límites del valor, indicador de eventos... :S

Lo cierto es que vendría bien que:
- SON (o una función equivalente) devolviera uno a uno cada hijo del proceso que se le pregunta.
- O que SON fuera un array variable de datos, y que se pudiera acceder a sus valores como tal (o que no sea un array, que internamente siga siendo un árbol de dependencias, pero que se pueda acceder a los datos como si fuera un array).

Si no, pues se me ha ocurrido que la barra de relleno sea el padre, y hacer fondo y botón hijos del mismo, así ya tengo el ID. La única pega es que entonces la Z que puedo obtener no es la más alejada de la cámara, que es la Z de referencia del botón-slider (la referencia sería mi_botonslider_id.z + 1).

[panreyes]

Creo que puedes crearte tú mismo esa función, aquí te dejo la pista :)

while(blabla=get_id(0))
  if(blabla.father==id) ...

[SplinterGU]

panreyes, esto es asi

todos los hijos desde el menor al mayor

Code Select Expand


hijo = padre.son;

do {
     say( hijo );
} while( ( hijo = hijo.bigbro ) );


si quitaramos bigbro y smallbro, no habria forma de recorrer los hijos de un proceso. SON solo devuelve 1 id, no devuelve todos los ids...

no es lo mismo

id.SON.SON

que

id.SON.BIGBRO

el primero referencia al nieto de id, y el segundo al primer 2do hijo (de menor a mayor) de id

no alcanza solo con SON

no podes tener 8000 variables propias para tener lista de todos tus hijos, estas variables son necesarias para muchas funciones, tales como señales a tree de jerarquias, mantener la lista enlazadas de hijos, y otras cosas.

mientras no se cambien los valores no tiene porque ser peligroso, en este aspecto es tan peligroso como father, son, etc

[Drumpi]

¿Pero entonces BIGBRO y SMALLBRO hacen referencia sólo a procesos con el mismo padre que el proceso de referencia?
Es decir, si tengo el proceso A, y este crea los procesos B1, B2 y B3, si invoco A.son me devuelve B3, pero si hago B3.bigbro me devuelve B2, si hago B3.bigbro.bigbro obtengo B1 y si hago B3.bigbro.bigbro.bigbro obtengo 0 porque no hay ningún hermano creado antes ¿O me he equivocado en algo?

[panreyes]

panreyes, esto es asi

todos los hijos desde el menor al mayor

Code Select Expand


hijo = padre.son;

do {
     say( hijo );
} while( ( hijo = hijo.bigbro ) );


si quitaramos bigbro y smallbro, no habria forma de recorrer los hijos de un proceso. SON solo devuelve 1 id, no devuelve todos los ids...

no es lo mismo

id.SON.SON

que

id.SON.BIGBRO

el primero referencia al nieto de id, y el segundo al primer 2do hijo (de menor a mayor) de id

no alcanza solo con SON

no podes tener 8000 variables propias para tener lista de todos tus hijos, estas variables son necesarias para muchas funciones, tales como señales a tree de jerarquias, mantener la lista enlazadas de hijos, y otras cosas.

mientras no se cambien los valores no tiene porque ser peligroso, en este aspecto es tan peligroso como father, son, etc

Vale, lo tenía mal entendido, pensaba que eran ints simples, no "meta-funciones"

[SplinterGU]

¿Pero entonces BIGBRO y SMALLBRO hacen referencia sólo a procesos con el mismo padre que el proceso de referencia?
Es decir, si tengo el proceso A, y este crea los procesos B1, B2 y B3, si invoco A.son me devuelve B3, pero si hago B3.bigbro me devuelve B2, si hago B3.bigbro.bigbro obtengo B1 y si hago B3.bigbro.bigbro.bigbro obtengo 0 porque no hay ningún hermano creado antes ¿O me he equivocado en algo?

perfecto!

[SplinterGU]

panreyes, esto es asi

todos los hijos desde el menor al mayor

Code Select Expand


hijo = padre.son;

do {
     say( hijo );
} while( ( hijo = hijo.bigbro ) );


si quitaramos bigbro y smallbro, no habria forma de recorrer los hijos de un proceso. SON solo devuelve 1 id, no devuelve todos los ids...

no es lo mismo

id.SON.SON

que

id.SON.BIGBRO

el primero referencia al nieto de id, y el segundo al primer 2do hijo (de menor a mayor) de id

no alcanza solo con SON

no podes tener 8000 variables propias para tener lista de todos tus hijos, estas variables son necesarias para muchas funciones, tales como señales a tree de jerarquias, mantener la lista enlazadas de hijos, y otras cosas.

mientras no se cambien los valores no tiene porque ser peligroso, en este aspecto es tan peligroso como father, son, etc

Vale, lo tenía mal entendido, pensaba que eran ints simples, no "meta-funciones"

son ints, pero tienen la misma funcionalidad que ID. (son IDs) :D

claro, bigbro y smallbro, son para saber el hermano mas grande y mas chico de un proceso (sea cual sea)(misma generacion por llamarlo de alguna manera, y sirve para recorrer los hermanos en un sentido o en otro, digamos en sentido horizontal), SON y FATHER (son para recorrer generaciones hacia arriba o abajo, en sentido vertical)
incluso FATHER y SON pueden tener hermanos (bigbro y smallbro)

en el caso de FATHER con respecto a ID, todos los *BRO de FATHER son los "tios" de ID (no son father de ID, sino tios).
en el caso de SON con respecto a ID, todos los *BRO de SON son hijos de ID

[Drumpi]

Muchas gracias a los dos por vuestra inestimable ayuda :)

Estaba tentado de usar la solución de Pixel, de buscar los procesos de ese tipo cuyo padre fuera el que busco, porque al final no eran tantos (he calculado unos 24 en todo el IDE). Pero como no sé cuántos habrá al final, y quería buscar una solución más elegante, al final opté por esta solución:

Code Select Expand

      temp_son = ibs_id.son;
     
      while (temp_son != 0)
         if (temp_son.reserved.process_type == (type i_button_slider_fillbar))
            temp_son.size_x = ibs_percent;
            temp_son = 0;
         else
            temp_son = temp_son.bigbro;
         end
      end

Donde ibs_id es el proceso botón-slider, el padre de todos. Lo que he hecho ha sido clonar el proceso dummie, y cambiarle el nombre, para que fuera más fácil de encontrar usando el type. Sé que la estructura reserved es la zona prohibida, que no se debe tocar, y que te caerá una maldición de 1000 años que bla bla bla, pero creo que ya soy lo suficientemente mayorcito como para saber lo que hago, y sólo estoy leyendo, y eso nunca le ha hecho mal a nadie (salvo que vivieras en la Edad Media :P ).
Ya con eso y el uso de SON y BIGBRO, funciona de lujo.

Aunque luego me he planteado que el nuevo proceso, si le paso el valor mínimo, el máximo, y un puntero al valor, podría hacer que se actualizara sólo... aunque luego he pensado que sería un proceso más activo todos los frames, que no se debería congelar (lo que supondría un problema si el padre cambia de estado, no me gusta que los hijos estén despiertos cuando el padre no por cuestiones de mantener el control), y prefiero tenerlo así, con una función que lo actualiza desde fuera sólo cuando es estrictamente necesario.

[panreyes]

Vale, Splinter, entiendo el concepto. No son meta-funciones (ints que se actualizan al leerlos), ahora he visto el hijo=hijo.bigbro.

En fin, pienso que el método perfecto es el comprobar el father de todos los procesos, aunque igual no es el más óptimo.

[SplinterGU]

otro detalle, no se actualizan al leerlo, se actualizan solo si:

- un hermano muere y si es el hermano mas proximo al que murio, (se actualizan SMALLBRO.BIGBRO y BIGBRO.SMALLBRO)
- si el proceso que muere es el hijo menor (SON). (se actualiza FATHER.SON al BIGBRO del proceso que murio)

en los casos de querer usar o referenciar a FATHER, SON, BIGBRO, SMALLBRO, hay que hacer un EXISTS para asegurarse que el proceso existe antes de acceder al mismo, para evitar que el motor reviente por no existir el proceso.