positioning windows in MDI

positioning windows in MDI

Post by Gila » Fri, 07 Nov 2003 18:54:35


Hello, can anyone teach me how to position a form exactly in the middle of
the mdi.

I have a form, which I would like to position in the middle of the mdi when
executed. How do I go abt doing it?
What is the code to use?
Can someone pls enlighten me.

Thanks.
 
 
 

positioning windows in MDI

Post by John Lauwe » Fri, 07 Nov 2003 19:54:37

Try this

Public Sub MySize(frm As Form)
frm.Move (Screen.Width - frm.Width) / 2, (Screen.Height - frm.Height) /
2
End Sub

then call mysize(Yourform) in the code window

Greets
J.
"Gila" < XXXX@XXXXX.COM > schreef in bericht

when

 
 
 

positioning windows in MDI

Post by Jeff Johns » Fri, 07 Nov 2003 23:04:08


/

Actually, to place the child form in the middle of the parent form (which is
what I believe the poster wanted) you should use the ScaleWidth and
ScaleHeight of the parent in place of Screen.Width and Screen.Height.
 
 
 

positioning windows in MDI

Post by John Lauwe » Fri, 07 Nov 2003 23:09:39

Yes you are right, I use this with forms that have no parent.In youre case
it should be :
Public Sub MySize(frm As Form)
frm.Move (mdiform1.ScaleWidth - frm.Width) / 2, (mdiform1.ScaleHeight -
frm.Height) /2
End Sub

Gr
J.

"Jeff Johnson [MVP: VB]" < XXXX@XXXXX.COM > schreef in bericht



frm.Height)
is
 
 
 

positioning windows in MDI

Post by Rick Roths » Sat, 08 Nov 2003 00:14:59

> > > Try this
(which

(mdiform1.ScaleHeight -

Which could be written this way if you didn't want to hardcode the MDI
form's name in the Sub (makes the routine easier to reuse).

Public Sub MySize(frm As Form)
Dim F As Form
For Each F In Forms
If TypeOf F Is MDIForm Then Exit For
Next
frm.Move (F.ScaleWidth - frm.Width) / 2, _
(F.ScaleHeight - frm.Height) / 2
End Sub

Rick - MVP
 
 
 

positioning windows in MDI

Post by Gila » Sat, 08 Nov 2003 10:03:41

IS this how I call it under the Formload of the particular form that I want
to centralise?

MySize (FrmLogin)
FrmLogin is the name of my form...
Anything wrong?
I got Type mismatch...pointing to the line above..




case
 
 
 

positioning windows in MDI

Post by Rick Roths » Sat, 08 Nov 2003 11:19:55

> IS this how I call it under the Formload of the particular form that I
want

When you make a call to a Subroutine without using the Call keyword, you
should not use parentheses. If parentheses that are not part of the required
syntax are used, VB treats it as an expression to be evaluated. In the case
of an object, it evaluates to its default property. I don't remember what
the default property of a form is, it may be another object (ActiveControl)
in which case I think that object's default property is used); but, in any
case, passing the form's name in parentheses does not pass the form object.
Remove the parentheses (and remember never to add them anywhere in VB just
because you think they look good) and the function should work fine.

Rick - MVP
 
 
 

positioning windows in MDI

Post by ahseo » Sat, 08 Nov 2003 12:01:28

THANKS ALOT!
The code works perfectly fine now.

But another problem I see is that when I'm running the application under
1024x768 resolution.. the screen is centralised.

However, when I tried changing the resolution to 800x600..the whole screen
moves towards the right..
Is there anything I can add on to make it such that the screen will always
be centralised regardless of the resolution used.?

Thanks.,


required
case
(ActiveControl)
object.
 
 
 

positioning windows in MDI

Post by Rick Roths » Sat, 08 Nov 2003 15:10:35

If I understand the problem you are trying to describe, it is not a VB (nor
any other programming language) problem. I suspect the forms are centered
correctly within the visible section of the screen; it is just that the
screen itself has moved. While I don't know the reason behind the problem,
it seems to be a graphics card problem. The monitor settings for one
resolution seem to have nothing to do with the settings that need to be used
on other settings. If you set your monitor to 800x600 and re-center the
screen using the monitor controls, I think you'll find the forms are
properly located in the screens.

Rick - MVP



what
any
just
 
 
 

positioning windows in MDI

Post by Randy Birc » Sun, 09 Nov 2003 09:24:42

That's not *quite* true when considering variables. When you make a call to
a subroutine with parenthesis the value passed is passed ByVal, rather than
ByRef, regardless of the variable declaration in the called procedure.

--

Randy Birch
MVP Visual Basic
http://www.yqcomputer.com/
Please respond only to the newsgroups so all can benefit.




: > IS this how I call it under the Formload of the particular form that I
: want
: > to centralise?
: >
: > MySize (FrmLogin)
: > FrmLogin is the name of my form...
: > Anything wrong?
: > I got Type mismatch...pointing to the line above..
:
: When you make a call to a Subroutine without using the Call keyword, you
: should not use parentheses. If parentheses that are not part of the
required
: syntax are used, VB treats it as an expression to be evaluated. In the
case
: of an object, it evaluates to its default property. I don't remember what
: the default property of a form is, it may be another object
(ActiveControl)
: in which case I think that object's default property is used); but, in any
: case, passing the form's name in parentheses does not pass the form
object.
: Remove the parentheses (and remember never to add them anywhere in VB just
: because you think they look good) and the function should work fine.
:
: Rick - MVP
:
:
 
 
 

positioning windows in MDI

Post by Rick Roths » Sun, 09 Nov 2003 13:54:47

gt; : When you make a call to a Subroutine without using the Call keyword, you
what
any
just

"Randy Birch" < XXXX@XXXXX.COM > wrote in message
news:eJWqb.179406$ XXXX@XXXXX.COM ...
to
than

I'm not so sure that is 100% accurate either. I have always thought that
when VB evaluates an expression, it (by whatever mechanism it uses) selects
a temporary memory location for the evaluation to take place in and then
assigns the value it derives there to wherever directed by code. For
instances, if you have

Variable1 = (Variable2 * Variable3)

I thought the multiplication takes place in a memory location other than
Variable1's and, once the multiplication operation is completed, it is
assigned from that temporary memory location to the memory location given to
Variable1. In a similar manner, I figured something like this

MySubroutine (Variable2 * Variable3)

would also use a temporary memory location to calculate the expression in
the parentheses (just like it did above... same VB internal routines being
called by the exact same code) and then, if MySubroutine was expecting a
ByRef argument, pass the address of that temporary memory location into the
subroutine. The subroutine would be free to change that temporary memory
location at will; but, since it **is** temporary, nothing happens back in
the calling code. The minimal variable expression that could be passed to a
subroutine would be

MySubroutine (SomeVariable)

The expression (the thing in parentheses) is easy for VB to evaluate here
(it just copies the content of SomeVariable into a temporary memory
location, looks around for what it is supposed to do with it, finds out that
there is nothing to do to it and so exits its internal expression evaluation
routine), but I still think that evaluation happens in a temporary memory
location and I believe it is that temporary memory location that gets passed
into the Subroutine meaning that MySubroutine can't change the actual
contents of SomeVariable, only the temporary memory location where VB
evaluated the expression at. The net effect of this is it **looks** like
SomeVariable is passed ByVal even though the subroutine's argument specifies
ByRef; but I don't think the parentheses triggers an "ignoring of the ByRef
specification" exception to occur, just that it (the passing in of the
argument) happens to the expression's memory location rather than the
variable's.

I know I'm arguing for a subtle difference in interpretation here, it's just
your the "parentheses makes VB ignore the argument passing specification"
doesn't seem logical to me. On the other hand, the explanation I have
offered doesn't require VB to create any exceptions-to-operations during its
processing of code, only that it use and reuse its internal routines in a
consistent and repeatable manner. That, to me, seems to be the more logical
approach for the coders of VB to have taken.

Rick - MVP


 
 
 

positioning windows in MDI

Post by Steve Gerr » Mon, 10 Nov 2003 04:44:53

iven that the subroutine in question can be called from several places in the
program, some of which may not use parentheses and some of which use the Call
keyword, the subroutine itself must be compiled with ByRef semantics. That is,
the resulting machine code expects the address of a variable to be passed on the
stack, not a value.

Therefore, some scenario such as Rick has described must be taking place, rather
than a "switch" to actually pushing a value on the stack instead of an address.
I believe that this "address of a copy" process also applies when data other
than simple elements are passed ByVal, i.e. strings, arrays, and the like.

"Rick Rothstein" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...


 
 
 

positioning windows in MDI

Post by Randy Birc » Mon, 10 Nov 2003 10:47:02

Variable1. In a similar manner, I figured something like this
:
: MySubroutine (Variable2 * Variable3)
:
: would also use a temporary memory location to calculate the expression in


This is fundamentally different than passing a *variable* in brackets.
Above VB passes the result of the (Variable2 * Variable3) expression.

: ByRef; but I don't think the parentheses triggers an "ignoring of the
ByRef
: specification" exception to occur, just that it (the passing in of the
: argument) happens to the expression's memory location rather than the
: variable's.

Right, when an expression is passed. The situation is different when a
variable is passed:

Private Sub somefunc(var1 As Long)

var1 = 999

End Sub

Private Sub somefunc2(var1 As Long, var2 As Long)

var1 = 999
var2 = 333

End Sub

Private Sub Command1_Click()

Dim v As Long
Dim b As Long

'passed byref - calling
'method can change var
v = 25
Print "in :", v
somefunc v
Print "out :", v, "..byref"
'>999

'passed byval - calling
'method does not change var
v = 25
Print "in :", v
somefunc (v)
Print "out :", v, "..byval"
'>25

'passed byref - calling
'method can change var
v = 25
b = 100
Print "in :", v, b
somefunc2 v, b
Print "out :", v, b, "..byref"

'passed byval - calling
'method does not change var
v = 25
b = 100
Print "in :", v, b
somefunc2 (v), (b)
Print "out :", v, b, "..byval"

End Sub


: I know I'm arguing for a subtle difference in interpretation here, it's
just
: your the "parentheses makes VB ignore the argument passing specification"
: doesn't seem logical to me.

Re-read my post. I did not make this assertion. My response was directed to
your statement " If parentheses that are not part of the required syntax are
used, VB treats it as an expression to be evaluated". I pointed out that
using parenthesis to surround a *variable* causes vb to pass that value
ByVal, rather then ByRef, regardless of the way the variable in the called
procedure was defined. You have extended the argument to include
expressions, which was not part of the original discussion.

Naturally, attempting to pass an object using parenthesis around the
variable causes an error 424 (object required) since objects must be passed
byref :

Private Sub Command2_Click()

Dim ctl As Control

Set ctl = Command2

'pass object byref
somectlfunc ctl
Stop

'reset caption
Command2.Caption = Command2.Name

'pass object byval
somectlfunc (ctl) 'error

End Sub

Private Sub somectlfunc(c As Control)

c.Caption = "changed!"

End Sub


Since brackets around a variable representing an object causes the default
value (aka byval - the default property) of the object to be passed, rather
than the object itself, you can pass the control to a variant as long as you
don't try to perform operations on the parameter as an object ....

Private Sub Command2_Click()

Dim ctl As Control

Set ctl = Command2
somevarfunc (ctl)
'> boolean
'> True

Set ctl = Text1
somevarfunc (ctl)
'> string
'> Text1 (the textbox contents)

End Sub

Private Sub somevarfunc(c As Variant)

Print TypeName(c) '= boolean
Print c '= true

' c.Caption = "changed!" 'no can do: error 424
' c.Text = "changed!" 'no can do: error 424

End
 
 
 

positioning windows in MDI

Post by Bob Butle » Mon, 10 Nov 2003 11:38:58


I think Rick is correct; the statement
MySubroutine (var1)
causes VB to evaluate the expression "(var1)"; the fact that the expression
consists only of a single variable with no operators is irrelevent. It's
the same as an assignment in the form
variable=expression
is still the same even if the expression is just a variable as in: var2=var1

When you pass an object reference in parens the same thing happens; VB
evaluates the expression by retrieving the default property. The rules are
exactly the same for passing an expression with multiple operands or for
expressions that consist only of a single variable.

Private Sub Main()
Dim x As Long
Debug.Print "'Real' x: " & VarPtr(x)
MySub x
MySub (x)
MySub x + 0
End Sub

Sub MySub(ByRef y As Long)
Debug.Print "passed as: " & VarPtr(y)
End Sub
 
 
 

positioning windows in MDI

Post by Randy Birc » Mon, 10 Nov 2003 21:55:41

Maybe we're splitting hairs. My point is one can expect a call to preserve
the original value of a passed variable when surrounded by a bracket, and
this may be and undesirable side effect of such syntax.

--

Randy Birch
MVP Visual Basic
http://www.yqcomputer.com/
Please respond only to the newsgroups so all can benefit.