Sign in to follow this  
Followers 0
qwert

Need some help on DllCall("user32.dll"...

6 posts in this topic

I'm trying to set up a few "one-time" DllCalls to modify window screen positions in an initialization script. My testing has had widely varying results. Sometimes the calls are acted on -- but sometimes they seem to be ignored (or go into a wait state from which the script never resumes).

This has left me wondering: what is the proper environment for executing a DllCall? Should the target window be set active? Should it matter? My understanding is that AutoIt will automatically open the dll, so OpenDll is not required. But what might cause the call to go into a wait state? (and not return any result).

There's quite a bit of information on MSDN on the statement's syntax and parameters, but precious little on required lead-in or follow-up script steps.

Thanks for any help.

Share this post


Link to post
Share on other sites



O.K. here's another factor: the laptop I'm testing on runs Vista. (all previous testing has been on XP)

My script works properly if I launch it from the desktop -- all the DllCalls work.

But, if I launch it from a button inside the application, itself, the first DllCall hangs. I figure it's something about "permissions" in Vista's new scheme -- but I'm at a loss to know what.

Do this make sense to anyone?

Share this post


Link to post
Share on other sites

What dll function does it hang up on?

SetWindowPos

Share this post


Link to post
Share on other sites

SetWindowPos

Does WinMove() hang as well in the same situation? (Replacing the DLLCall with WinMove() for the test is what I'm suggesting)

Common sense plays a role in the basics of understanding AutoIt... If you're lacking in that, do us all a favor, and step away from the computer.

Share this post


Link to post
Share on other sites

Does WinMove() hang as well in the same situation?

Actually, no; WinMove works. As I've continued testing, that was one of the next things I tried. I wish I could somehow see what DllCall WinMove is making.

From the latest tests I've run, I looks like this has something to with the flags at the end of the SetWindowPos call. By adding the flag SWP_FRAMECHANGED, the internally-called script started working. That same flag is not needed in the externally-called version. Although I can't understand why there is a difference, I did find this comment on a VB forum that seems to confirm its use:

Unfortunately, the first time programmers use these functions, most of them ignore the last parameter ('nFlags'). The solution is to pass 'SWP_DRAWFRAME' or 'SWP_FRAMECHANGED'.

There's one other factor that might be in play: for test purposes, I'm using the uncompiled version of my script. When it's "opened" from the main application (i.e., called internally), it opens SciEditor and I have to execute the script using the Go command (F5). Yet this doesn't affect WinMove. It works either way.

BTW, thanks for the responses.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0