issue with cancel button on inputbox

[mmelon]

Hi, when i do the simplest inputbox after the start label

__Webapp_AppStart:
;<< Header End >>
inputbox,outputvar,test
msgbox %ErrorLevel%

the docs for inputbox say that pressing cancel or typing escape, should give 1 in ErrorLevel. It seems when called from within the webgui, it always gives 0. closing the box with the X gives 1 as expected. I think I might have seen this reported before, so sorry if it's a duplicate.

[joedf]

Good catch! This is a very weird bug. It looks like the library is doing something weird which causes the ErrorLevel to vary. I inconsistently get 0 or 1.

Does it happen in a function?

[mmelon]

yes i get it in a function. I seem to consistently get 0 for cancel, and 1 for the close button. Once the webapp has started. But i am running in a virtualised win7.

[mmelon]

i might have found something by pure luck, though it's way above me to work out which bit might be the cause.

commenting out everything in

gui_KeyDown(wParam, lParam, nMsg, hWnd) { }

stops it happening entirely for me. I must have done 20-30 tests in a row on your example.ahk. I got a 0 on cancel as soon as i removed the block comments.

[joedf]

Yes, I think you may be right. gui_KeyDown() was one of my suspicions... It's there to workaround some weird issue with IE, but I guess I ended up causing another issue.

Could you try my latest change?
713f5d6

[mmelon]

Hi. So unfortunately that hasn't fixed it so sorry if i lead you up the wrong path. I've done some more digging

I changed my getDom() function to this

getDOM(){
global __Webapp_wb
MsgBox errorlevel = %ErrorLevel%
return __Webapp_wb
}

Then in example.ahk

__Webapp_AppStart:
;<< Header End >>

inputbox,outputvar,test
msgbox %ErrorLevel%

if (ErrorLevel == 1) {
msgbox we got the proper error level
}

If we use the X to close the inputbox (which we know seems to be working and consistently gives 1), 9 times out of 10, some call to getDom() sets ErrorLevel back to 0, so we don't see "we got the proper error level". We do see errorleve = 0.

Sometimes i do see it, I think because we are getting to the IF condition before getDom() has returned?

[mmelon]

i don't know if this is even an issue to worry about. I was concerned it might be interfering with other errorLevel conditions in my app

[joedf]

I am not sure either. This is similar to what I was experiencing when I said it was inconsistent. This makes is so much harder to figure out ahaha

I generally don't rely on ErrorLevel but it seems that many commands require it to provide some feedback... I think you are safe from this if you are by using functions and avoiding commands where possible, but this is definitely a limitation.

Either way, I will revert my change for now to avoid creating new problems.

[joedf]

As an alternative you could use Neutron.ahk by Geekdude! It's very good and probably better. 👍
https://www.autohotkey.com/boards/viewtopic.php?f=6&t=76865

I wrote Webapp.ahk as a first attempt and as part of a tutorial on the forums. I think Geekdude has done much better job, using classes, cleaner code, and many new features.

[mmelon]

Hi. Thanks I have heard of neutron. I haven't tested it yet to see if it has the same issue.

This is my best work around so far

It seems that the ErrorLevel does get correctly set to 1 after a cancel or close on an inputbox. It seems something is overwriting it back to 0, 50% of the time so quickly that you can't capture the 1 in errorLevel straight after the inputbox.

I found these callback functions

WBClientSite_AddRef(p)
{
global oldErrorLevel
if (ErrorLevel == 1) {
oldErrorLevel := 1
}
return 1
}

they seem to fire constantly and quickly. I've abused one to poll errorLevel and capture the 1 when it is detected. Then i can use oldErrorLevel instead of errorLevel to see what an inputbox did.

then i do

ResetOldErrorLevel() {
global oldErrorLevel
oldErrorLevel := 0 ; Reset oldErrorLevel to 0
}

after the inputbox

inputbox,outputvar,test

if (oldErrorLevel == 1) {
msgbox we got the proper error level
resetOldErrorLevel()
}

this seems to be letting me capture what happens in inputboxes. I don't know the reason for the callback functions or why they are called so quickly and often. Perhaps I am wrong but i seem to be able to capture the change in errorlevel before the naughty bug blanks it again.

[joedf]

Thanks! Webapp.ahk is supposed to be more beginner friendly and has worked well for most overall.

So it seems, the culprit is WBClientSite_AddRef() ?
Or I guess all 3... with WBClientSite_QI and WBClientSite_Release

Maybe you can try commenting out this line (the call to SetWBClientSite()):

Webapp.ahk/src/Lib/Webapp.ahk

Line 76 in 07dac3f

SetWBClientSite()

You will likely get ActiveX issues and warnings, but if ErrorLevel works, then this brings us somewhere!

EDIT: commenting out SetWBClientSite() worked flawlessly for me!
I will try to investigate sometime later next week to see if the "WBClientSite" is still needed. I didn't test all functionality, but for now this works great. Let me know how it works for you.