Is PushButton blocking, waiting for something?

[Dick99999]

I have a PushButton like the one below. This one clicks on the Connect button of a regular windows Network Connection dialog. It looks like pushbutton is waiting for something before it returns.

If the modem of the dial connection is not working then windows waits for something like one and a half minute and return in a redial dialog. During that time Pushbutton seems not to return, and thus I cannot act on the response window that has a choice to redial or cancel.
Is PushButton indeed waiting/blocking, any workaround if so?

Code: Select all

                     Let>WF_TYPE=0
                     Let>WIN_USEHANDLE=0
                     Let>WIN_REGEX=0
               PushButton>umtsNetwConX,{"&Connect..."}

[Marcus Tettmar]

PushButton gets underneath the UI and tries to send the message that gets sent when a user clicks the button. We cannot guarantee or know how an app will respond to that. It is often better to simulate a user precisely by sending a Press Enter or LClick to the button instead.

[Dick99999]

Thanks for the fast response. Then apparently the message sending process itself is blocking. Does that also depend on the app or is perhaps a timeout possible?
The key/click alternative is less reliable, that's why I switches to push.

[Marcus Tettmar]

Completely depends on the app. PushButton works on the assumption that the button responds to the BM_CLICK message which in theory simulates the button being clicked. But the dialog may need to be active and I have seen many situations where this doesn't always work - probably due to the app expecting some other condition. We can't know for sure what is going on inside the app. The only thing we can be sure of is that if the button is focused and we actually click on it or press enter or space on it (or use the accelerator keystroke if it has one) it will be invoked. And then we need not care what's going on behind it.

Similarly I've seen CloseWindow cause strange things. CloseWindow sends the WM_CLOSE message to a window. This gets sent when the window must close so we can assume that sending WM_CLOSE will cause a window to close. But some apps do other stuff. As an example it used to be the case that if you sent WM_CLOSE to MS Word (or was it Excel) it would NOT ask you to save changes - it bypassed the usual closedown procedure! The developers presumably assumed a user would click the close button and trapped that event earlier than just trapping a WM_CLOSE. It's understandable really: Developers generally aren't anticipating that robots will use their software.

Macro Scheduler offers numerous ways of achieving something. Different apps may require different approaches.

[Marcus Tettmar]

The key/click alternative is less reliable, that's why I switches to push.

I'd disagree. I'd say the key/click method is the most reliable. That's how the app was designed to work and how a user would use it. We know therefore that that will work. So use it.

[Dick99999]

The key/click alternative is less reliable, that's why I switches to push.

I'd disagree. I'd say the key/click method is the most reliable. That's how the app was designed to work and how a user would use it. We know therefore that that will work. So use it.

Thanks for the insight in the previous answer. And sorry, the quoted sentence should have been :
IN THIS PARTICULAR CASE, The key/click alternative is less reliable, that's why I switched to push.

The case being that buttons switch their label/function i.e. from connect to disconnect (once connected). Of course I could read the label of the button and then decide on the click. In that case it would be great if some reliable X,Y coordinates would also be returned (GetControlText>) of a label text, that would make the follow on click a lot more reliable I think.