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

[qwert]

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.

[qwert]

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?

[BAM5]

What dll function does it hang up on?

[qwert]

What dll function does it hang up on?

SetWindowPos

[SmOke_N]

SetWindowPos

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

[qwert]

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.