Page 1 of 1

Bug?

Posted: Wed Nov 17, 2010 6:13 am
by Sahmiam
function updateWindowSize()
globals.windowWidth, globals.windowHeight = getMainWindowSize()
globals.windowWidth = globals.windowWidth - 15
end

function updateBorders()
updateWindowSize()
setBorderTop(25)
setBorderRight(****)
end
I'm trying to set up Mudlet to change the border values every time I resize Mudlet. I want the values to change, not be set, so that if I make the window half size, the border is halved, etc.

Anyway, updateBorders() is called by the sysWindowResizeEvent event. That seems to work. However, when I resize the window, the setBorderRight() crashes Mudlet.

I tried putting in set values (25) as well as equations (0.25 * windowWidth), all of which crash the program. Ironically, setBorderTop() works fine.

Any help?

Re: Bug?

Posted: Wed Nov 17, 2010 12:03 pm
by Heiko
What's your OS and Mudlet version?

Re: Bug?

Posted: Wed Nov 17, 2010 5:58 pm
by Sahmiam
Windows 7 32bit and Windows7 64bit, and it was tested on 1.2.0pre5 and 1.2.0pre6.

Re: Bug?

Posted: Wed Nov 17, 2010 10:13 pm
by Heiko
Problem is confirmed, however, it's not a crash but an infinite loop. What happens is that when you change the main window size the resize event gets raised. When you change the border in a function connected to this event, then another window resize event is being raised because the size of the main console has been changed by setting a border size. This is an endless loop.

As a workaround you can use a tempTimer to calculate and resize the new border after a certain amount of time i.e. the time that is supposed to be needed to fully resize the window, and shield the tempTimer spawning with a variable lock to prevent the infinite loop problem.

Re: Bug?

Posted: Mon Nov 10, 2014 3:52 am
by sigma_g
Sorry for the necroing, but I really wonder why choosing to send the same event for a window resize as for a setBorderXxx().
People control when they use the setBorderXxx (and most often it's because the whole window was resized), and even if they want to send an event, they can send it manually.

It would be less of a pain for these users to send it (and I'd never had guessed such a behavior had I not found the infinite loop, that I tracked through my own code, then -finally- found in mudlet source), than for all of the others to find this and try to work around it with tempTimers...

An alternative solution would be that the setBorderXxx behaviour is documented somewhere, with an example of code to work around it...

Moreover, I'd be interested to know what use-case there is for this behaviour, maybe there's something useful I've missed :)
Thanks!