Maximizing a Program Window

[Lord[KL]]

How do you maximize a visual basic program, where the windows grow/shrink with the resize of the program?  

[OcTaViuS]

dunno wut this has to do with b.net but

Code Select Expand


me.minimize 'to minimize

me.maximize 'to maximize


oh oh oh, i get to be the first to say it... read a vb b-b-b... aww now i forget what i was gonna say...blast it!! blast it to heck!!

[LoRd[KL]]

No.. the textfield (as used in a battle.net bot, WHERE THE TEXT IS DISPLAYED have to grow as the said program window does

[Camel]

You'll have to dynamicly adjust the top, left, height, and width properties of the controls on your form when the Form_Resize event is called. Here's what I use in my bot:

Code Select Expand

Private Sub Form_Resize()
...
   Const Padding As Integer = 3 * 15 '3 pixels of space between objects; 15 twips per pixel
   Const ChanBoxHeight = 20 * 15
...
   txtChan.Height = ChanBoxHeight
   txtChan.Width = ulWidth
   txtChan.Left = Me.ScaleWidth - txtChan.Width
   txtChan.Top = 0
   
   UL.Width = ulWidth
   UL.Top = txtChan.Top + txtChan.Height + Padding
   UL.Left = Me.ScaleWidth - UL.Width
   UL.Height = Me.ScaleHeight - UL.Top
   
   txtSend.Left = 0
   txtSend.Width = txtChan.Left - txtSend.Left - Padding
   txtSend.Height = sndHeight
   txtSend.Top = Me.ScaleHeight - txtSend.Height
...
   txtChat.Top = 0
   txtChat.Left = 0
   txtChat.Width = txtSend.Width
   txtChat.Height = Me.ScaleHeight - txtSend.Height - Padding
...
End Sub

[edit] added a comment!

[CupHead]

Just so you know, Camel, TwipsPerPixel is not always 15, and the number of twips per pixel up and down can be different from the number of twips per pixel side to side.  You should use the Screen object and the TwipsPerPixelX/TwipsPerPixelY properties to do this more accurately.

[Camel]

Just so you know, Camel, TwipsPerPixel is not always 15, and the number of twips per pixel up and down can be different from the number of twips per pixel side to side.  You should use the Screen object and the TwipsPerPixelX/TwipsPerPixelY properties to do this more accurately.

I'm aware, but there's no real reason to compensate that way unless you're changing the property. In my *actual* code it checks, but I removed because by default TwipsPerPixelX and Y are both 15.

[dxoigmn]

Should also use Obj.Move instead of setting the properties directly.

Except comboboxes!  For some reason one of the properties (Top?) doesn't work when setting via .Move.

[CupHead]

Maybe your default.  Lord[KL]'s may be different.  Also, the reason to compensate would be to have a dynamically changing height/width based on the screen itself rather than some possibly inaccurate calculation given by a frequently inaccurate forum-poster.  

[Camel]

Maybe your default.  Lord[KL]'s may be different.  Also, the reason to compensate would be to have a dynamically changing height/width based on the screen itself rather than some possibly inaccurate calculation given by a frequently inaccurate forum-poster.  

AFAIK, the value of TwipsPerPixelX and TwipsPerPixelY is dependant solely upon a property of the form. It would however, if I am correct in my previous statement, make sense that the default setting of said property is dependant on some system-wide variable, and not some constant. Even if it is, it's irrelivant: The value of said property will be static from system-to-system as it will be whatever the programmer sets it to, or it already is, when he compiles.

[dxoigmn]

I'm aware, but there's no real reason to compensate that way unless you're changing the property. In my *actual* code it checks, but I removed because by default TwipsPerPixelX and Y are both 15.

Care to tell us what property this is?

[Camel]

[form].ScaleMode

[dxoigmn]

[form].ScaleMode

Ok, so if I change the ScaleMode of a form, and then Print out Screen.TwipsPerPixelX/Y, I should get different values right?  Well this isn't the case.  There is a slight flaw in your logic (as usual).  You see, TwipsPerPixelX/Y are dependent on the monitor or printer or whatever object you're referencing, not a property of a form (no property even exists for forms!).  To change values from one ScaleMode to another, you'd use ScaleX() and ScaleY().  For example:

Code Select Expand


Form1.ScaleX(3, vbPixels, Form1.ScaleMode)  ' 3 is arbitrary, this will convert 3 Pixels to what ever ScaleMode the form is set for, thus allowing us to use this number for resizing.


[Camel]

[form].ScaleMode

Ok, so if I change the ScaleMode of a form, and then Print out Screen.TwipsPerPixelX/Y, I should get different values right?  Well this isn't the case.  There is a slight flaw in your logic (as usual).  You see, TwipsPerPixelX/Y are dependent on the monitor or printer or whatever object you're referencing, not a property of a form (no property even exists for forms!).  To change values from one ScaleMode to another, you'd use ScaleX() and ScaleY().  For example:

Code Select Expand


Form1.ScaleX(3, vbPixels, Form1.ScaleMode)  ' 3 is arbitrary, this will convert 3 Pixels to what ever ScaleMode the form is set for, thus allowing us to use this number for resizing.


I'm not the one who suggested using Screen.TwipsPerPixel*! My code uses ScaleX and ScaleY! I really dont see why this is such a big fucking deal; I didn't think that it was worth pointing out that it's possible to do such a conversion dynamicly because it would just be one more thing to confuse him. But then again I must go easy on you; sometimes I forget that you were never new to VB.
There was no flaw in my logic: I openly admited that I was unsure of how Screen.TwipsPerPixel* was determined and offered only a guess. I went on to say -- apparantly not clear enough for you to understand -- that it is irrelivant because, so long as the value of [form].ScaleMode is not being changed at runtime, there is no reason to compensate for a change and the value [of Padding] can be constant. This is why I replaced my code with constants.

[edit] value [of Padding]

[dxoigmn]

My point is that you openly convey wrong information to people intentional and unintentional and it's extremely annoying.  If you're unsure, then go figure it out.  I took the time to, surely you could.

[Camel]

My point is that you openly convey wrong information to people intentional and unintentional and it's extremely annoying.  If you're unsure, then go figure it out.  I took the time to, surely you could.

Let me translate what I said for you: "I'm not sure what Feature X does, but it's irrelivant because it's totally useless anyways. Use Feature Y instead."