Ridiculously Strange VB Behaviour...

[ShepherdOfChaos]

If anyone can offer a reasonable explanation for what follows, I'd sure love to hear it.

Basically, the situation is I've got some code to do form captures (I've left out the boring, mundane bitblt stuff that isn't relevant to the problem at hand). The given code has been working fine for a couple of months now.

Form 1

Private Sub Copy_Active_Pic()
Dim width, height As Long

hWndActive = GetForegroundWindow()
lRet = GetWindowRect(hWndActive, rct)
Debug.Print "getWindowRect= "; lRet
dcActive = GetWindowDC(hWndActive)

width = rct.Right - rct.Left
height = rct.Bottom - rct.Top
Debug.Print "width= "; width; "height="; height

When doing a full screen form capture, the above code yields

width= 808, height=578 (which is correct for the VB IDE form)

Last night, I did some tweaking and decided to make width and height global variables:

module 1

Global width, height as Long

This had the very bizarre effect of yielding the following:

width= 1800 (???) height= 574

The only other noteworthy thing I can think of is width and height were also declared as local variables in a function in another form. But this shouldn't have any effect, should it?

[Gen-X]

Why not change the global variables to "rctwidth" and "rctheight" and answer your own question for you

[ShepherdOfChaos]

Not sure I understand what you're getting at. I've tested this several times already. The capture function works correctly when width and height are local function variables, and doesn't work when width and height are global variables. When I get rid of width and height being globals, the problem disappears. This I know already. What I don't know is why. Do you?

[ShepherdOfChaos]

Okay, I did what you said and I see what you were getting at. There is something particular about "width" and "height" being globals that causes a problem, that "rctwidth" and "rctheight" are not subject too. WHAT?

[Gen-X]

Hehehhe... its called the magic of debugging ;-)

"width" and "height" are terms that could be considered reserved because the system uses them itself for various things.

Consider being in a particular form or class.

I can state the width by doing any of the following :

form1.width
Me.width

Or just simply...

"width"


Now when you create a class (and all forms are defined as classes) their properties are considered "local". So when you defined width and height as local variables they took precidence over the default values (meaning you could only get the width and height by using form1 or Me). But when you defined them as global variables the class definition superseeded the values for them.

Its all about a wonderful topic that always causes so much confusion called "Variable Scope".

Glad you got it working

[Sacred_knight]

I have notice that height and width seems to be keywords at times. If you look the following example below, the height and width are assumed to belong to the form.

Private Sub Form_Click ()
Width = Screen.Width * .75
Height = Screen.Height * .75
Left = (Screen.Width - Width) / 2
Top = (Screen.Height - Height) / 2
End Sub

Maybe height and width declared as global in a module, interferes with the form's height and width properties.

Also, instead of printing the height and width to the debug box, try printing it in an object on the form, like a label or textbox. See if the problem still occurs

[ShepherdOfChaos]

Ahh, I see. I was guessing it was something like that. Thanks for filling in the gaps in my knowledge.

While were on the subject of strange behaviour, I had another situation a few months ago that went something like this:

form 1

private sub whatever1()
dim x, y as long

y= x / 4


form2

private sub whatever2()
dim x,y as long

y= x / 4


The actual computations were a bit more complex than this (the exact details I can't remember), but essentially I had the exact same calculations in two different forms with the exact same input values (I had merely pasted all the code from one into the other) and I GOT TWO DIFFERENT RESULTS. Any clues?

[Gen-X]

If you are saying that the coputations were a bit more complex than that then I would assume that somewhere in there something was not exactly the same.

Computers RARELY give 2 different answers to the same thing for no reason and 95% of the reasons come down to human error.

Best way to fix that... Cut'n'Paste the sections that were the same to confirm they were the same.

[ShepherdOfChaos]

I've managed to find the offending code:

private sub write_pic_file()

Select Case bi.bmiHeader.biBitCount
Case 1
bufSize = (bufSize + 7) / 8
Case 4
bufSize = (bufSize + 1) / 2
Case 24
bufSize = bufSize * 3
End Select
' And make sure it aligns on a long boundary
bufSize = ((bufSize + 3) / 4) * 4
' And multiply by the # of scan lines
bufSize = bufSize * bi.bmiHeader.biHeight


This same code was placed in another form like so:

private sub read_pic_file()

Select Case bi.bmiHeader.biBitCount
Case 1
bufSize = (bufSize + 7) / 8
Case 4
bufSize = (bufSize + 1) / 2
Case 24
bufSize = bufSize * 3
End Select
' And make sure it aligns on a long boundary
bufSize = ((bufSize + 3) / 4) * 4
' And multiply by the # of scan lines
bufSize = bufSize * bi.bmiHeader.biHeight



The code in both cases is the same, and also wrong for what I was trying to do (needed to do integer divides \), but actually gave different results for bufsize given the exact same inputs. It was as though in one form VB decided to round up at a certain point in the calculation and in the other form it decided to round down at the same point.

Might try an experiment and see if I can get VB to duplicate that behaviour.

[Gen-X]

The code might be the same but its relying on a variable called "bi.bmiHeader" which could have been set to DIFFERENT values for each of those forms.

I would output this variable before the select statment especially for bi.bmiHeader.biHeight and see if you get the same value.

I wouldn't be so quick to even THINK that VB is "deciding" to do anything differently between forms.

I have to say this again... 95% of problems are HUMAN ERROR or HUMAN OVERSIGHT... NOT the computer deciding "Well, *THIS* time I am going to ignore my coding and do something different

Until you get the idea out of your head that VB is doing something wrong these kinds of problems will keep coming up and keep stumping you

private sub whatever1()
dim x, y as long

Just something i noticed:
the dim x, y as long

Would declare x as variant and y as long
dim x, y as long =
Dim X
Dim Y as Long


Do it like, dim x as long, y as long

[ShepherdOfChaos]

The code might be the same but its relying on a variable called "bi.bmiHeader" which could have been set to DIFFERENT values for each of those forms.

I would output this variable before the select statment especially for bi.bmiHeader.biHeight and see if you get the same value.

I wouldn't be so quick to even THINK that VB is "deciding" to do anything differently between forms.

I have to say this again... 95% of problems are HUMAN ERROR or HUMAN OVERSIGHT... NOT the computer deciding "Well, *THIS* time I am going to ignore my coding and do something different

Until you get the idea out of your head that VB is doing something wrong these kinds of problems will keep coming up and keep stumping you

Preaching to the Choir, my friend. I know what I originally wrote may have seemed mushy minded and superstitious, but I honestly don't really believe in ghosts in the machine. (But after you've pulled your hair out on a seemingly intractable problem, you sometimes begin to wonder ) Years of c programming have taught me that it is indeed almost always something ridulously SIMPLE or ABSURDLY STUPID that my feeble human brain has glossed right over.

I'm still in the early stages of experience with VB so I'll probably still be repeating the simple and the stupid for awhile yet Thanks for your help.

[ShepherdOfChaos]

private sub whatever1()
dim x, y as long

Just something i noticed:
the dim x, y as long

Would declare x as variant and y as long
dim x, y as long =
Dim X
Dim Y as Long


Do it like, dim x as long, y as long

EEEEEEEEEEEEEKKKKKKK

IS THIS TRUE? Egads, man, you may have just pinpointed a major source of the "strange" behaviour I've encountered in the last few months.

I really must devote more of my time to formal VB study so these simple things won't keep biting me in the butt

THANKS

[MartinLiss]

Yes, it's a common mistake, but it is true.

[ShepherdOfChaos]

Guess what I discovered. In the example above, bufSize was actually declared like so in one sub:

dim bufSize as long

And like so in the other sub:

dim bufSize, bytes_read as long

SO, now it makes sense why I got two different results with the same calculations. bufSize being a variant in one DIDN'T chop off the decimals, and bufSize being a long in the other DID chop off the decimals.

Well, boys and girls, this has been a wonderful learning experience for yours truly. Hope you all got as much out of it as I did.