[power-pro] unwanted effect of new "more responsive" feature

[[e-mail] [power-pro]]

When I set the value mentioned below to anything other than zero, it slows down a script of mine that sends wheel scroll events to windows. Does that make sense?

"PowerPro more responsive when other programs using high cpu. On Advanced setup, Limits tab, set "Time to wait before aborting call for icon/text" to small value like 2 or 1."

Thanks

[[e-mail] [power-pro]]

It only affects active bars. Do you use them? If so, set it to a value to that works best for you. I cannot think of how it would affect sending wheel scrolls I am afraid.

[[e-mail] [power-pro]]

I should have asked exactly how you are sending wheel scrolls.

[[e-mail] [power-pro]]

If you have a looking for a window which matches some text in a script loop which also sends wheel scrolls, then possibly this may be the source of the issue.

If so, try moving the search for the text outside the loop, eg save search results as window handle and then use it to send scrolls.


The technical background: the enhancements are meant to deal with non-responsive windows. When you look for a window matching some text, PPro has to loop through all active windows to see if any match the given text. This is done with a system api which asks the window itself to return its text. If the window is non-responsive, PPro will hang. The feature uses a different windows api call which aborts after a given time.


Now it is not clear to me why that would matter, but this is all I could think of that would affect the situation you describe as I understand it.


BTW, this feature was always there, but the recent versions optimized it and extended it to apply to any PPro request for window text. Setting wait to zero means the old method is used; ie send request and wait indefinitely for it to return.

[[e-mail] [power-pro]]

I have since realized that the issue with the slower mouse scrolling and not being able to send other keystrokes is probably due to something else. I'm currently still on 5.3.35p. When I update to the unicode version, I think the following plugin call in the script I use to send keystrokes from Powerpro via my main AHK script (rather than having Powerpro itself send the keystrokes) breaks:

unicode.sendcopydata(SendString, win.handle("*master.ahk*,&,=autohotkey"))

Do you reckon I could fix this just by using

win.sendcopydata(SendString, win.handle("*master.ahk*,&,=autohotkey"))

instead after upgrading to a .37 version? I suppose the unicode plugin is obsolete after upgrading to .37?

Many thanks!

[[e-mail] [power-pro]]

First, is their a reason not to stick with 0 as the value for the delay? Please review previous notes for what the delay does -- it's only helpful for situations where you have _any_ window on your system that has failed or is CPU-intensive and does not respond to required for text or icon.

If you still want to leave the parameter non-zero: Have you reviewed the notes I sent about optimizing the loop by moving the gethandle outside of it, rather than doing a caption match within the loop? Have a look if you have not already. That optimization may help.


I don't understand why you are using unicode unless sendstring is unicode. Is it?


I don't see why using native win.sendcopydata would be more efficient that using unicode plugin. Do you have a reason you want to do that?


If you think you do, there is a win.sendcopydatau in the unicode version of win. and you could call it from .35 by:
Getting the win plugin from the Unicode install (install .37 to some other folder).
Rename it to (say) winu.dll and
copy .winu.dll to 35 plugins folder under exe folder.
Then you'd use unicode plugin to make UTF16 as utf8
then sending that UTF8 with winu.sendcopydatau.


There's a bit more on renaming plugins the help as well, (although not specifically for this purpose). However, as per above, doubt this will matter.






The unicode plugin is not obsolete. Although many of its functions can now be performed from .37, some cannot. If you are interested in details, see the help second on unicode support, subsection on, using the unicode plugin.