Same VB.NET code behaves differently on 2 different PCs.

[sunama]

Hi,

I am programming in VB.NET

I want to move an IE window to the top left hand corner of the screen.

I have the following code, which works fine on my Vista PC.

--------------------------------------------------------------------

Private Declare Function FindWindow Lib "user32.dll" Alias "FindWindowA" (ByVal lpClassName As String, ByVal lpWindowName As String) As Long

Declare Function MoveWindow Lib "user32.dll" Alias "MoveWindow" (ByVal hwnd As Long, ByVal x As Long, ByVal y As Long, ByVal nWidth As Long, ByVal nHeight As Long, ByVal bRepaint As Long) As Long

Public Sub positionWindow()
Dim smartWindowHandle As Long
smartWindowHandle = getWindowHandle(windowName) 'where the windowname is previously specified
MoveWindow(smartWindowHandle, 0, 0, 647, 550, 1)
End Sub

The window handle is attained using the following:

Private Function WindowHandle(ByVal sTitle As String) As Long
WindowHandle = FindWindow(vbNullString, sTitle)
End Function

and ...

Public Function getWindowHandle(ByVal windowName As String) As Long
Return (WindowHandle(windowName))
End Function

---------------------------------------------------------------------

The problem is that on my Vista machine, it works fine. But on my XP machine, the window that is being moved, freezes and doesnt repaint itself. And when I run another window over it, it dissapears.

Can anybody offer any advice on how to move the window, without the window falling apart?

Thanks

 

[sunama]

Yesterday I tried changing the values to boolean and integer values, as you suggested, however, it made no difference. Well, actually it did. Rather than the window disintegrating when other windows moved over it, the window simply dissapeared.

I havent tried changing the window handle to IntPtr though and I honestly can't see why that should work. I've checked that the windowhandle is being attained using a messagebox and a long number is being assigned to the windowHandle successfully.

I shall try your full declaration though and report back.

 

[sunama]

Right. Ive sorted out the problem.

As it turns out XP was able to deal with declarations for MoveWindow involving Integer only. When I was originally using Long, it didnt like this. Vista of course, had no problems dealing with Long or Integer.

So, I changed the code, replacing all variables of type 'Long', to 'Integer' or 'Boolean'. The code now works in both Vista and XP.

Declare Function MoveWindow Lib "user32.dll" Alias "MoveWindow" (ByVal hwnd As Integer, ByVal x As Integer, ByVal y As Integer, ByVal nWidth As Integer, ByVal nHeight As Integer, ByVal bRepaint As Boolean) As Boolean

Thanks to Dolph. He didnt solve the problem, but he did plant the seed in mind that the problem lay in the variable declarations.

 

[sunama]

I'm developing an app that allows me to analyse the results to see if there is any funny business going on, by playing casinos using free money and collating the outcomes. If everything is totally random, then the results should bear this out.

Obviously the casino has to win over the long term, however, by the same token, they should be run honestly.

There have been many reports/anecdotes that some online (and real) casinos should not be trusted as their random number generators will change to ensure you don't win too much money and that over the long term you end up losing.

Not trying to scrape / automate casino windows are you? Been there, done that.... much0s pain in the ass

Specifically what did you do and what were you findings?

 

[sunama]

...

Obviously it depends on which casino you are looking at, but try and pick a casino where there is some other means to capture the outcome.

Capturing screenshots of a small section of the cards dealt, I think, is a bad idea, because in some cases, there may be more than 2 cards. You would then need to match up 52 different cards to stored screenshots, which becomes a nightmare.

Look for other indicators, on screen, which allows your program to determine the outcome.

I do agree though - sitting comparing screenshots and searching for errors in pixel matches, looking for the ideal base screenshot to compare future screenshots with, can be extremely tedious and mind numbing.