Custom Query (3933 matches)

Ello,

It'd be great if you guys included classes in a future version of AutoIT. I think it would promote more people writing UDFs which are a little more flexible.

It looks like there might be a bug/regression in the betas with regards to GUIRegisterMsg(), though I'm not exactly sure when the regression occurred. I've attached an example script (sorry it's a tad bit long, but it's simple).

As is, it behaves correctly, and the treeview root can't be expanded by double-click. On the other hand, if you return anything, anywhere in the callback function chain, AutoIt decides it wants to handle the message, regardless of what is returned, and regardless of whether the return value even bubbles up back to the original callback function.

Regarding the function chain, ignore the For loops. I only added them to demonstrate the fact that it isn't because the function chain is taking too long to return that causes AutoIt to behave wonkily (it's something I considered at first).

The GUIRegisterMsg() documentation needs updating. It's difficult to determine what return value would cause AutoIt to stop handling the message internally.

From the manual:

By using 'Return' without any return value the AutoIt internal message handler (if there is one for this message) will NOT be proceed!

Yet, an empty return *does* allow AutoIt to continue handling the message. Returning 0 does the same. It seems that it's only when you return a non-zero integer that it stops handling things internally.

So yeah, clarification/reorganization would be nice :)

Additionally, the example script no longer works properly (though that problem might originate from the possible regression described in ticket #222)...