setCoordSystem does not work in ggbOnInit()

Sander Tacker shared this question 1 week ago
Answered

Hi GeoGebra friends,


I'm a teacher and am developing an exercise file for students; it's about finding the equations of randomly created linear functions.

When the student clicks the "Next Exercise" button, I create a new linear function and change the bounds of the coordinate system to fitting values by using the command

ggbApplet.setCoordSystem(<xmin>,<xmax>,<ymin>,<ymax>)

in the button skript. (Before, I do some calculations to get good values for the bounds, but that's irrelevant here). This works really fine.

Since by saving the current coordinate system is also saved, I'm trying to reset the bounds of the coordinate system when the GeoGebra file is reloaded. Therefore I put the command

ggbApplet.setCoordSystem(-10,10,-7,7)

in the ggbOnInit() routine.


But for some reason the routine is not working in the ggbOnInit() routine. Why is this? How can I reset the coordinate system on startup? It's really annoying :(


I'd be glad to get some help.


Sander

Comments (15)

photo
1

Can you post the file here?

Anyway I've looped your post to the Support Team.

photo
1

Since the complete file is pretty complex, I've created a new simple file that also produces the problem.


Thanks for looking at it!

Sander

photo
1

I suggest you try setting the xmin/max ymin/max to your variables in the "Basic" tab of settings. Then you can just use setValue() on those to change the zoom

photo
1

Thanks for your response, Michael.


Your suggestion indeed works on startup (see attachment file), but unfortunately it fixes the bounds of the coordinate system, so that the user can't zoom in and out using the mouse wheel after a new zoom is created (which has to be possible for my purposes). For that reason I do need concrete numbers as bounds instead of bounds that depend on variables. That's also the reason I'm using


ggbApplet.evalCommand("ZoomIn[CopyFreeObject(x_{min}),CopyFreeObject(y_{min}),CopyFreeObject(x_{max}),CopyFreeObject(y_{max})]")

inside the click routine of the button "NewRandomZoom" instead of


ggbApplet.evalCommand("ZoomIn[x_{min},y_{min},x_{max},y_{max}]")
which would create a dependency on the variables and therefore would disable the mouse wheel.


So I really need a way to reset the bounds on startup with concrete numbers. It there something I can do to achieve this or is this simply a bug in GeoGebra?

Sander

photo
1

Hello again,

is there a chance to get this issue marked as bug and be solved in the next GeoGebra version? I don't see a workaround for the problem myself.

Sander

photo
photo
1

Hello again,

is there a chance to get this issue marked as bug and be solved in the next GeoGebra version? I don't see a workaround for the problem myself.

Sander

photo
1

I think but I did not try: zoomin(xmin,............) you can try zoomin(ratio) calculating the ratio from corners (perhaps setaxesratio() and centerview() are needed) instead the advice of Michael

photo
1

Thanks for your propose, but it also doesn't work.

It seems like setCoordSystem as well as ZoomIn don't have any effect in ggbOnInit except the fact that all axes vanish.

photo
1

Does it work inside setTimeout()?

photo
1

What exactly do you mean? Do you try to create a workaround for ggbOnInit by using setTimeout? Sorry, but I don't get your idea.

photo
1

Sorry that I post again, but shouldn't this thread be marked as "bug" instead of "answered"?

The problem from the thread subject isn't solved, is it?

photo
1

después de probar muchas, pero que muchas, instrucciones y también muchas combinaciones de ellas he llegado a la conclusión de que hay varias de ellas que, aunque son ejecutadas por ggbOnInit, son anuladas posteriormente con la carga del archivo en el que quedan anotados los parámetros de inicio.

para algunas de estas situaciones yo usaba un motor, un deslizador animado que ejecutaba nuevas instrucciones después de la carga.

el problema sería que este motor debe ser guardado de forma que comience en animación pero, tal vez, después necesitemos que pare.

en el ggbOnInit del adjunto soluciono el problema creando el deslizador y sus comportamientos posteriores a la carga de forma que procuro que su funcionamiento altere lo menos posible el resto del trabajo.

este deslizador lo he llamado, por supuesto, mathmagic

comprueba si tiene el comportamiento que deseabas

Files: foro.ggb
photo
1

un ligero error encontrado y corregido

photo
1

Hey mathmagic,

thank you for your creative workaround, that indeed works.


In terms of improving GeoGebra I think nevertheless that this bug should be fixed in the next version, cause your (really impressing) solution is absolutely not intuitive for users to find it by themselves :)


Is there a way to get it on the official bug list for next version?

photo
1

I think is not a bug. I think the command is executed but then GG read the file and the file says to GG the size of the screen, then the command is reexecuted with another values.

but this is a job for developers. I am only simply an user

© 2019 International GeoGebra Institute