$input crash - mIRC Discussion Forums

If you run $input from a desktop custom window/dialog (unsure for other window), mIRC allow you to use that desktop window/dialog again..
For example if you are running $input from the sclick dialog event, you can get mIRC to run an infinite number of $input window, at some point mIRC crash.

I may have reported that bug in the past..

Code:

;/dialog -m test test
dialog test {
size -1 -1 40 20
button "click me",1,0 0 40 20
}
on *:dialog:test:sclick:*:noop $input(test,o)

I think that when $input is used without the 'u' switch with a custom window/dialog as the active window, the parent should be that window and not the mIRC main window.

Thanks for your bug report. What you are describing is expected behaviour. If you open a large enough number of dialog windows, Windows will run out of resources, become unstable, and applications will begin to fail and crash. It is up to the scripter to ensure that scripts are written carefully so that this does not happen. In your example, if your intention is to allow the user to only open one $input() window for that context, your script would need to check that only one $input() window has been opened.

I understand, I think mIRC should try to prevent any type of crash, shouldn't mirc be receiving an error while trying to create the $input window which causes the crash? Is there no way to repors the usual error "* error creating window"?

mIRC checks for the failure of dialog creation, however if there is a cascade of allocation failures across many functions, it can sometimes be difficult to predict what will happen.

In order to display text in a window, such as an error message, mIRC needs to allocate memory for the string, string context, display context, bitmap handles, and so on. So any attempt to display an error message would very likely fail, if Windows has run out of resources. Pre-allocating all of these in anticipation of an error would be difficult. In general, once Windows has reached a low resource state, it is difficult to guarantee reliable behaviour.

I will try to reproduce this issue to see if I can prevent $input() itself crashing in a low resources state, however there will be many other side-effects in this situation, even if mIRC does not crash.