Form Size Mystery

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Darrell Wesley - 22 Oct 2003 14:27 GMT

I have a VB6 application that has run thru the conversion
process to VB .net. All compile time and run time errors
have been cleaned up and the application does run.

One puzzle remains to be solved. The application uses an
MDI form as well as 3 child forms which may or may not be
all on screen at once. In the primary child form's
properties I have the Height set at 544 and Width at 552,
I even set the Height and Width in that forms load routine
but when it becomes active it has completely different
values like 478 and 800.

I have searched for where the height and width may being
used but have come up empty handed. No place in code can I
find these being set. Is there someplace else to look?

The properties are set at 544 and 552 for Height and
Width. Just before the show method is used in the MDI form
these values are 537 and 768, in the load routine they are
set to 555 and 541 but when activated they are 478 and
800. Where can they possibly being set to something on
there own?

Reply to this Message

John Hart [MSFT] - 22 Oct 2003 19:56 GMT

Hi Darrel,

There was a post fairly simular to this here recently. It's not perfectly
clear to me from your post if this is the MDI form or the child forms that
are having the problem. Either way are you setting the location property of
these forms prior to the form load? If so try moving this to the form's
load event instead. The other example of this problem that I saw was
related to the form's location being setting prior to the load and the
control box property being set to False at design time. For some reason
this was causing the form's size calculation to be off and it appears
something simular is happening with your project.

Let me know if this helps. If not if you could provide some a code sample
of how your showing the child form's I'll be glad to look into it further.

Signature

John Hart, Microsoft VB Team
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------

> Content-Class: urn:content-classes:message
> From: "Darrell Wesley" <anonymous@discussions.microsoft.com>
[quoted text clipped - 13 lines]
> Path: cpmsftngxa06.phx.gbl
> Xref: cpmsftngxa06.phx.gbl

microsoft.public.dotnet.languages.vb.upgrade:5640

> NNTP-Posting-Host: TK2MSFTNGXA12 10.40.1.164
> X-Tomcat-NG: microsoft.public.dotnet.languages.vb.upgrade
[quoted text clipped - 21 lines]
> 800. Where can they possibly being set to something on
> there own?

Reply to this Message

Darrell Wesley - 22 Oct 2003 22:37 GMT

The problem is with one of the child forms. The only place
where the SIZE is being set is either in the Design time
properties or in the load event of the child form.

The ControlBox property is set to TRUE for both the MDI
parent and the child.

The Startup form for this project is the Child form. If I
choose to start with the MDI parent form I get sometype of
reentrant or recursive call to the parent form which .net
does not like but more on that later.

Remember this is a VB6 program that has been run through
the convert routine. The VB6 compatablilty layer it throws
in may be at issue here. I know that it sets up some type
of default instance of the form but I don't see any
reference to height or width at that point.

Will post sample code if needed.

>-----Original Message-----
>Hi Darrel,
[quoted text clipped - 57 lines]
>
>.

Reply to this Message

John Hart [MSFT] - 23 Oct 2003 19:28 GMT

I don't intially expect the compatbility library as the problem here. It
may be that the upgrade is over using the pixeltotwips conversion but I
would expect you would see that in more then just the one form. I didn't
see that you answered my question though, are you setting the problem Child
form's Location prior to it being shown?

If you could post some code that would be helpful or you can send a repro
to me at VBResult@microsoft.com and I'll be glad to take a look

Signature

John Hart, Microsoft VB Team
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------

> Content-Class: urn:content-classes:message
> From: "Darrell Wesley" <anonymous@discussions.microsoft.com>
> Sender: "Darrell Wesley" <anonymous@discussions.microsoft.com>
> References: <0c5601c398a0$42724440$a401280a@phx.gbl>

<jdIBI5MmDHA.2464@cpmsftngxa06.phx.gbl>

> Subject: RE: Form Size Mystery
> Date: Wed, 22 Oct 2003 14:37:14 -0700
[quoted text clipped - 10 lines]
> Path: cpmsftngxa06.phx.gbl
> Xref: cpmsftngxa06.phx.gbl

microsoft.public.dotnet.languages.vb.upgrade:5651

> NNTP-Posting-Host: TK2MSFTNGXA11 10.40.1.163
> X-Tomcat-NG: microsoft.public.dotnet.languages.vb.upgrade
[quoted text clipped - 104 lines]
> >
> >.

Reply to this Message

Darrell Wesley - 23 Oct 2003 22:07 GMT

The pixeltotwips conversion has been commented out and
the .net values inserted so I don't think that is the
cause.

You keep saying "location" , this problem child form is
not having it's location set except in the design time
properties. I have noticed that instead of the top left
corner of this form being in the top left corner of the
MDI container it is offset - I even tried to set these to
0 and 0 and had no effect on the outcome.

I will zip up the entire assembly and send it to you.
Maybe you can see something I don't.

Thanks for the help so far.
Darrell

>-----Original Message-----
>I don't intially expect the compatbility library as the problem here. It
[quoted text clipped - 136 lines]
>
>.

Reply to this Message

John Hart [MSFT] - 24 Oct 2003 23:12 GMT

Thanks Darrel for sending me the project. It really helped to understand
the problem.

The problem with the MDI Child form being a different size then you set at
design time was due to the StartupPosition property. The form's
StartupPostion was set to WindowsDefaultBounds and should have been set to
WindowsDefaultLocation.

Here's the help topic that explains the differences:

WindowsDefaultBounds The form is positioned at the Windows default location
and has the bounds determined by Windows default.
WindowsDefaultLocation The form is positioned at the Windows default
location and has the dimensions specified in the form's size.

The other problem that you mentioned with the MDIForm being the Startup
object and it causing an overflow was being caused by your call to Sub
Main() in the MDI Form_Load event. What was happening is this call was
actually calling the hidden Sub Main that was inserted in the form by the
compiler since it was the startup object so instead of calling the sub Main
in your Globals.vb file you were calling Sub Main on the form over and over
and over. To fix the problem I just following qualified the call so it
should be Globals_Rename.Main(). This fixed that problem.

Signature

John Hart, Microsoft VB Team
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------

<jdIBI5MmDHA.2464@cpmsftngxa06.phx.gbl>
<04b901c398e4$a8930a40$a301280a@phx.gbl>
<qTUltNZmDHA.1804@cpmsftngxa06.phx.gbl>

> Subject: RE: Form Size Mystery
> Date: Thu, 23 Oct 2003 14:07:45 -0700
[quoted text clipped - 10 lines]
> Path: cpmsftngxa06.phx.gbl
> Xref: cpmsftngxa06.phx.gbl

microsoft.public.dotnet.languages.vb.upgrade:5658

> NNTP-Posting-Host: TK2MSFTNGXA13 10.40.1.165
> X-Tomcat-NG: microsoft.public.dotnet.languages.vb.upgrade
[quoted text clipped - 189 lines]
> >
> >.

Reply to this Message

Form Size Mystery

Free Magazines