Estoy haciendo una clase derivada de tableview y todo me funciona perfectamente salvo que en algún momento me aparece el warning:

Circular References detected

TableView(1)

¿Cómo puedo depurar en qué momento a = b que a su vez b=a? (que creo que es el origen del error)

===================
No podemos regresar

Hola, no me ha quedado clara la pregunta, que es a y que es b?
Que quieres decir con "a = b que a su vez b=a", si a=b entonces b=a, no?
Quizas soy yo pero no me he enterado del asunto...

Pido perdón, que llevas razón, soy más oscuro que las ingles de KuntaKinte...
Si tú tienes un objeto, en este caso un tableview, cualquier asignación que hagas se hace por referencia, es decir, lo que tienes es una referencia al objeto. Si le cambias alguna propieadad  a la "copia", se la cambias al mismo objeto.
es decir si

dim tb as object
tb=me.tableView1
tb.tag = "Este soy yo"
print me.tableView1.tag

Producirá en la consola "Este soy yo"
Sin embargo, si luego se realiza una asignación inversa, algo así como "tableview1=tb" se da el caso de que intentas convertir tableview1 en una referencia a tb, que ya es a su vez una referencia a tableview1.
Eso se denomina referencia circular y genera un warning en la consola.
Sin embargo no sé cómo depurar el código para encontrar en qué punto se produce esa asignación errónea.

===================
No podemos regresar

Hombre, en una hoja de cálculo ese tipo de problemas pueden ser realmente complejos y viene bien una herramienta para detectarlos, pero en gambas no veo el problema

Dim tb as object
tb=me.tableview
tb.tag="este soy yo"


Y ahora pongamos que en otro sitio tienes
tableview=tb
Y eso te da un error por referencia circular. Eso solo puede significar que tableview y tb son lo mismo así que para empezar estás haciendo una asignación inútil puesto que ambos ya son lo mismo. En este caso tendrías que mirar que es lo que contiene tb y para eso basta con buscar donde haces tb igual a algo.

Pero cuanto te encuentras ese tipo de problemas como regla general es que estás cometiendo un error de lógica. Conviene plantearse de nuevo lo que estas haciendo porque algo está muy mal. Lo mejor es ponerse al principio y comprobar paso a paso que estas haciendo y por que. Con toda seguridad encontrarás algún error de bulto.

Ese error yo no lo he tenido nunca pero errores de bulto .... si yo te contara ...

snif
 

Muy a malas lo que hago es poblar la parte de código que creo que puede tener el problema de msgbox... perdon de Message.Error("x"), por ejemplo, o creo una variable intError y voy asignado valores a lo largo del código, capturo el error y imprimo el intError para saber por donde se ha quedado, voy acotando hasta que doy con la linea exacta que da el error.
Esto me va bien cuando el ejecutable falla pero cuando lo ejecuto desde el debuger no, o si está el programa instalado en el cliente y solo le falla a el.
Pero cuando se pueda lo mejor es lo que ha dicho soplo.
Saludos!

Hombre no se en tu caso, pero para esas cosas parece mejor utilizar el DEBUG.

Incluyes en tu proyecto el componente debug y a partir de ahí donde te va interesando pones
debug variable
o bien
debug "estoy en la rutina de XX y el valor de tal cosa es" & variable
y tal

Cuando casca miras en la consola de gambas y ves los sitios por donde has pasado y los mensajes que has ido escribiendo. Así puedes ver donde coges valores erroneos o lo que sea.

También es práctico utilizar los puntos de interrupción que los pones y quitas con F9. Así ejecutas hasta cierto lugar y compruebas lo que tienes obtenido hasta ese momento.

 

Si si, lo que he dicho antes lo uso para casos "especiales":
* El exe (hablo del vb6) da un error pero desde el IDE todo va bién.
* El programa falla solo en casa del cliente.
Para todo lo demas, debugcard.