For the life of me I cannot get this API function to work as expected
in VB.Net

I am however using SetWindowPos, and so long as the window is not
minimized, it will position as I tell it to. If the window is
minimized SetWindowPos will not move the window, and
SetWindowPlacement does not appear to have any effect on changing the
state of the window from Minimized to any other state, such as normal,
maximized or otherwise.

I've tried code, and combination of code from a number of sources,
including MSDN, pinvoke.net, and vbnet.mvps.org, all with no luck.

Now keep in mind that I'm not concerned about 64 bit systems, so a
data type of Long should be fine. I've tried various versions of this
function, including the <DLLImport...> version, as well as having the
function return a Boolean value rather than a Long. This function
appears to have zero effect. Also note that I do have the proper
constructs in place, i.e. WindowPlacement, PointAPI & Rect.

Interestingly enough I have been able to get the IsIconic function
working, and it *will* return correctly the state of the application
window (minimized or no).

Here's the code for what its worth...although this variation and its
forms are all over the net...any thoughts, advice or ideas would be
greatly appreciated. Thanks.

Public Declare Function SetWindowPlacement Lib "user32" _
(ByVal hwnd As Long, _
ByRef lpwndpl As WINDOWPLACEMENT) _
As Long

Private Sub (Blah, Blah)

Dim lhWnd As Long = lvWindows.SelectedItems(0).SubItems(1).Text
Dim currWinp As WINDOWPLACEMENT

currWinp.Length = Len(currWinp)
currWinp.flags = 0&
currWinp.showCmd = SW_SHOWNORMAL

SetWindowPos(lhWnd, 0, 0, 0, SWP_NOSIZE)
SetWindowPlacement(lhWnd, currWinp)

End Sub



'RestoreWindow(lhWnd)

End Sub

"Long" in VB5/6 was 32 bits - but in .NET it is 64 bits. [
http://msdn2.microsoft.com/en-us/library/y595sc15.aspx ]
However a HWND is still 32 bits - so the data type Int32 or better still
IntPtr should be used in its stead.
[
http://msdn2.microsoft.com/en-us/lib...rs(VS.71).aspx ]

Hope this help,
Duncan

"Zamdrist" <zamdrist (AT) gmail (DOT) com> wrote

Thank you Duncan. Use of IntPtr I understand will ensure my
application is compatible with 64-bit systems, and while I understand
that is good form, its not a concern of mine as I am developing for a
controlled environment of Windows XP clients using 32-bit Intel
processors.

Nevertheless, I removed all of my non working code, and started from
scratch, using the code found here:

http://www.dotnetspider.com/kb/Article3505.aspx

Interesting enough, it casts the hWnd value as an Integer. It appears
to work nevertheless, or even as a Long. I haven't figured out a way
to convert a value to IntPtr in any event, even if I wanted to.

So the code from the above mentioned article works very much as is and
I'm looking for a compelling reason to monkey with it more or just let
it be. Again, I'm not the least bit concerned this program would ever
be ran on anything but a 32-bit system. Its distributed within a
controlled environment.

Thanks

On Dec 28, 3:21 pm, "Duncan Jones" <Dun... (AT) merrionomputing (DOT) com> wrote: