Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug: Window size not correct with menu

0 views
Skip to first unread message

Bill McNeal

unread,
Jul 13, 2000, 3:00:00 AM7/13/00
to
Using VB6 Enterprise SP4 (it works the same with SP3 too).

Try this:

Create a new project.
Place a command button very near the bottom of the form.
Create a single top-level menu item so that the form has a menu bar.
In the Form Load event, put the following code:

Me.Left = 0

Save the project.
Close the form window so that when the project is loaded again, the form is
not automatically displayed.
Close the VB IDE.
Restart VB and load the new project.
Run the project.

Notice that the command button is chopped off at the bottom of the form. If
you take out the Me.Left = 0, the form displayed with the correct size. If
you open the form in the IDE and run it, it displays correctly even if the
Me.Left = 0 is still there. Finally, if the form has no menu, it also
displays correctly.

Bug!

Has anyone else seen this? Is setting the Left (or Top, etc.) property
before the form is displayed a wrong thing to do?

Ken Halter

unread,
Jul 13, 2000, 3:00:00 AM7/13/00
to
Works fine with VB5/SP3.

> Has anyone else seen this? Is setting the Left (or Top, etc.)
property
> before the form is displayed a wrong thing to do?

I've never seen this. I've written apps that set top/left before showing
with values read from the registry to return the form to the position it
was when it closed and they've never complained so.... I don't think
that's the problem either...
Anyone else?


Bill McNeal <Bill....@ibm.net> wrote in message
news:#0p48hO7$GA....@cppssbbsa02.microsoft.com...

Chuck Bonner

unread,
Jul 13, 2000, 3:00:00 AM7/13/00
to
Bill,

This was just too bizarre, so I had to try it.

I can confirm your bug in VB6 SP3. Very weird.

I dug a little deeper. The results of my tests are described in more detail
below, for those who are interested.

I am interested enough to look into this further, but not right now. More
things I have to test are:

- How does this behave in a compiled EXE?
- How does this behave in older versions of VB (why didn't we notice this
before?)
- Is this bizarre behavior related to any repositioning/resizing in
Form_Load, or only to .Left?

I can sort of understand the logic behind one part of this phenomenon: If
the programmer chose to resize/reposition the Form in Form_Load, the system
will not override the programmer's choice. Remember that repositioning is
the same as resizing as far as the Windows API is concerned. That's what's
happening under the covers when your VB code says "Me.Left=0".

But why does it have to figure this out at run time? Why doesn't it store
the new size of the Form at design time? I have partial answers to this:
At design time, VB doesn't know how tall the Menu Bar will be. The height
of the Menu Bar is determined by user settings that must be read at
run-time. You can confirm this by looking at the Form file in a text
editor. VB does not store the size and position of the *Form,* it stores
the size and position of the *client area* of the Form. Then, at run time,
it figures out how thick the borders are, how high the title bar is, how
high the menu bar is, etc.

My brain hurts. Time to go home.

We shall continue exploring Bill's bizarre bug tomorrow. If I'm not too
zonked when I get home, I'll try this in VB5 SP3.

For those who are interested, there's some detail below of the quick testing
I have done.

Enjoy!

Chuck Bonner


DETAILS:

I put the following code into the Form:

Option Explicit

Private Sub Command1_Click()
Debug.Print "After Click:"
Debug.Print "Me: ", Me.Height
Debug.Print "Button: ", Command1.Top
End Sub

Private Sub Form_Load()
Me.Left = 0
'Changed the following line each run, to indicate which kind of test
I was running.
Debug.Print "Form Load, Me.Left =0, Form displayed before run:"
Debug.Print "Me: ", Me.Height
Debug.Print "Button: ", Command1.Top
End Sub

The Debug.Print statements revealed that what is happening is that the
button stays where it is, but, under certain circumstances, the height of
the Form is adjusted. Sometimes the adjustment occurs after Form_Load
completes, and sometimes before it begins.

Here are the rules as I currently understand them:

1. IF:
- The Form is not displayed in the IDE before Run time AND
- Code in Form_Load modifies the position of the Form
THEN
- The system fails to compensate for the additional height of the Menu
bar

2. IF:
- The Form is not displayed in the IDE before Run time AND
- No code in Form_Load modifies the position of the Form
THEN
- The system compensates for the additional height of the Menu Bar ONLY
AFTER FORM_LOAD

3. IF:
- The Form is displayed in the IDE before Run time, regardless of any
positioning code in Form_Load
THEN
- The system compensates for the additional height of the Menu Bar
BEFORE FORM_LOAD


Here is the output of my session, running the program three times, under
circumstances recorded in the first "Debug.Print" line for each run:

First run: Project was just loaded and the Form was not displayed in the
IDE. The button was "cut off" as Bill described
Form Load, Me.Left=0:
Me: 3600
Button: 2640
After Click:
Me: 3600
Button: 2640

Second run: Same session of the Project, Form was not displayed in the IDE.
Me.Left line commented out. The button was displayed normally
Form Load, Me.Left commented out:
Me: 3600
Button: 2640
After Click:
Me: 3885
Button: 2640

Third run: Same session of the Project, Me.Left line was activated, and I
displayed the Form in the IDE before running. The button was displayed
normally.
Form Load, Me.Left =0, Form displayed before run:
Me: 3885
Button: 2640
After Click:
Me: 3885
Button: 2640


Rick Rothstein

unread,
Jul 13, 2000, 3:00:00 AM7/13/00
to
Yes, I can reproduce that problem here!!!

I'm using VB6Enterprise(SP3) on a WinNT4(SP4) system.

It almost looks like the button was pushed down a distance equal to the
height of the menu bar. Perhaps placing the button BEFORE creating the menu
bar is causing the effect. It's almost like the button's Top property is set
to the distance down from the top of the ScaleHeight area so when you first
placed it (without the menu bar) its value was established by measuring down
from the bottom of the title bar. Let's say that value was 2700. Then you
created the menu bar. The button's Top property value remained 2700 (but the
button didn't move down to account for the smaller ScaleHeight area). Now,
when you reload and run the project, the Top value stays at 2700 (I put code
in the Click event to check) BUT that 2700 seems to now be measured from the
bottom of the menu bar as opposed to the title bar (as when it was first
placed).

I'm at work now -- I'll try this at home on my Win98 system to see if it is
OS dependent.

Rick

Woodie Morris

unread,
Jul 13, 2000, 3:00:00 AM7/13/00
to

This explains some weird behavior I've experienced too. I believe you will
find that it does not occur in the compiled exe though (fortunately).

--
-Woodie
www.Exit109.com/~wildwood

Bill McNeal wrote in message <#0p48hO7$GA....@cppssbbsa02.microsoft.com>...

Todd B - Agendum Software

unread,
Jul 14, 2000, 3:00:00 AM7/14/00
to

Bill, This has to do with the fact that screen area within VB during design
time and screen area during run-time are 'reported' differently between the
two types of code execution.. It is an issue that VB has had trouble
dealing with through SP3. Not sure if SP4 fixes it, but it does exist.

--

Sincerely,
Todd B - Agendum Software
http://www.AgendumSoftware.com | Mailto:Age...@AgendumSoftware.com
AgTransform - Major Update!! Now has 'true' translucency! Create forms,
dialogs and more with 'see through' screens! All using point and click
functionality - NO Code!

"Bill McNeal" <Bill....@ibm.net> wrote in message
news:#0p48hO7$GA....@cppssbbsa02.microsoft.com...

bob butler

unread,
Jul 14, 2000, 3:00:00 AM7/14/00
to
Ken Halter <KHa...@Tamsci.com> wrote in message
news:ugvwo$Q7$GA...@cppssbbsa02.microsoft.com...
> Works fine with VB5/SP3.

>
> > Has anyone else seen this? Is setting the Left (or Top, etc.)
> property
> > before the form is displayed a wrong thing to do?
>
> I've never seen this. I've written apps that set top/left before showing
> with values read from the registry to return the form to the position it
> was when it closed and they've never complained so.... I don't think
> that's the problem either...
> Anyone else?

I have this same problem with one application. If the form designer is
closed when I open the project and run it the main window is chopped off at
the bottom. It positions itself on the screen based on where the user moved
it to on last run so Form_Load does use "Me.Top" and "Me.Left"... taking
them out does appear to fix the problem.

The problem does not appear after compiling so I've just been ignoring it -
if the form is chopped I end the app, open the designer window and run it
again. This has been consistent in VB6 from the start, but just on this one
app, and it has not been worth the effort of tracking down exactly what
affects it. I don't remember if it happened in VB5 or not.


Bill McNeal

unread,
Jul 14, 2000, 3:00:00 AM7/14/00
to
Well, I have to disagree with that. If I load the project without first
displaying the form in design mode and compile to EXE, it behaves the same
way it does in the IDE. It cuts off the button.

In the end, it's totally work-aroundable because all you have to do is
display the form before you build the EXE, and then forever more it will be
right.

I just thought it was very weird, and was not working the way it "should" in
my mind.

Bill

"Woodie Morris" <wild...@exit109.com> wrote in message
news:O3MPc5T7$GA.240@cppssbbsa05...

Bill McNeal

unread,
Jul 14, 2000, 3:00:00 AM7/14/00
to

For me, it works the same way in both SP3 and SP4. I'm glad to hear it
wasn't just some funky thing that only happened on my computer. <g>

Bill

"Todd B - Agendum Software" <To...@AgendumSoftware.com> wrote in message
news:eD3i1fV7$GA.56@cppssbbsa05...
> <snip> It is an issue that VB has had trouble

Bill McNeal

unread,
Jul 14, 2000, 3:00:00 AM7/14/00
to
Wow, I had visually observed all the things you talked about, but thanks for
showing all the real numbers behind it. Very telling. I'm very glad I only
have one form in my project with a menu bar... <g>

Bill

"Chuck Bonner" <Charles...@us.heidelberg.com> wrote in message
news:e9LDnlR7$GA.257@cppssbbsa04...


> Bill,
>
> This was just too bizarre, so I had to try it.
> I can confirm your bug in VB6 SP3. Very weird.

<snip>

Chuck Bonner

unread,
Jul 14, 2000, 3:00:00 AM7/14/00
to
Didn't get to do all the testing I had hoped (got embroiled in a DOS on my
Web site, but that's another newsgroup ...)

Anyway, I was able to confirm:
- This does not happen in VB3 (no service pack reported. Don't remember if
we knew what service packs were in those days)
- This does not happen in the compiled EXE in VB6 SP3 on Win98 SE.

I'm a little puzzled and surprised by each of these findings, because I
thought I was really figuring it out. I thought I would see it in VB3 on
Win98, and I thought I would see it in the EXE. (Dang!)

I notice that Bill stated in a post marked 12:52 today that he *did* see the
button cut off in the EXE. Most peculiar. I'll bet you a Lear Jet that we
will see different behavior on different platforms. (Very safe bet, being
that there are so many platforms.) So, if anyone really wants to
investigate this, take note of the version of VB including service packs,
and the version of Windows, including service packs.

Just to clarify a conjecture that Rick Rothstein posted a few minutes after
my first post yesterday, no, the TOP property of the button is not changing
at all. Take a look at the Debug.Print output in my original post. It's
the Height of the Form that is changing unexpectedly. When the Form_Load
event adjusts Me.Left, the overall height of the Form is the client height
plus the title bar height plus twice the border thickness (i.e. not high
enough, and the button gets cut off). When the Form_Load event does not
adjust Me.Left, the overall height is all that plus the height of the Menu
bar, and all is right with the world. I don't think Rick is correct in
supposing that creating the button after creating the menu will make a
difference (but I wouldn't bet a Lear Jet on it). That's something else to
experiment with.

Some things I will be looking at:
- How does this behave in VB5?
- On what version of Windows available to me (Win95, Win98, Win98 SE) is
this truly a problem (i.e. does it happen in the EXE)?
- What if we compile on one version of Windows and run on another?
- In VB3, what happens if I compile, then twiddle with my User Preferences
to make the Menu taller, then run the EXE? (Just exploring the nature of
the beast here. I'll bet VB3 EXEs do not respect User Preferences in
Menus.)
- Same thing in VB6. (This time, I'll bet it still resizes properly on my
Win98 SE system, but perhaps not on others.)
- Can I make this bug happen by setting any size or position property of the
Form in Form_Load? So far, I've only tested "Me.Left = 0"
- What about other pre-display events, such as Form_Paint, Form_Resize,
Form_Activate?

In a few weeks, I'll be on a client site where I can do a little testing on
NT 4.0 workstation. I'll try to remember to bring some of this stuff with
me.

Just to sum up what I *think* is happening. When a VB program (possibly any
other Windows program) draws a window, it begins drawing it in the
design-time size. The only stored size information is about the client
area. The system "usually" adjusts the overall size of the window by
applying borders, title bar, and menu bar, so we end up with a window whose
client area is the size stored at design time. When this happens, the size
of the borders, etc., are determined by API calls that take account of the
border style and other relevant properties of the Form, and of the user
preferences that affect these features. However, these "usual" adjustments
do NOT occur if programmer-provided code makes its own adjustment to any
size or position properties while the window is being constructed for
display. If the Form has been displayed in the IDE before running, all of
these adjustments have already been made, and the full design-time client
area of the Form is displayed, regardless of whether programmer code has
modified the position of the Form.

As already stated, there are subtleties at work here such that this behaves
differently under different versions of Windows. (Actually, that's a
working conjecture. We know from Bill that the bug appears in his EXE, but
we don't really know the difference between his situation and mine.)

Does it really matter all that much? Yes, I think I want to understand this
well enough to feel confident that I know what controls will be visible or
not and whether my Form_Load should always initialize the Form's Height to
ensure that everything the user needs is available. This is academically
interesting, but I also want a good, reliable work-around for all likely
conditions.

Bill, you made me think. Thanks!

Chuck Bonner


Todd B - Agendum Software

unread,
Jul 14, 2000, 3:00:00 AM7/14/00
to
Bill, Aye this is something most people are not aware of and we have
learned all about it in the development of our products AgFastform and
AgTransform. Screen area and size numbers are reported differently
depending on whether you are in design mode, run mode or compiled .exe.
Also having an impact is the type of monitor and the type of video card.
These very reasons are why AgFastforms resize methods are completely
different than any other product on the market.... we took all of this into
account (and it was not easy, let me tell ya). Sorry for the plug. ;-)

--

Sincerely,


Todd B - Agendum Software

http://www.AgendumSoftware.com | Mailto:Age...@AgendumSoftware.com
AgTransform - Major Update!! Now has 'true' translucency! Create forms,
dialogs and more with 'see through' screens! All using point and click
functionality - NO Code!

"Bill McNeal" <Bill....@ibm.net> wrote in message

news:OjVVRRb7$GA.279@cppssbbsa04...

Woodie Morris

unread,
Jul 14, 2000, 3:00:00 AM7/14/00
to
Well, then I guess what I've experienced is a little different. I don't
remember all the specifics, but I do remember my forms sometimes resizing
differently in the IDE, but always OK in the compiled exe.

--
-Woodie
www.Exit109.com/~wildwood

Bill McNeal wrote in message <##3OrPb7$GA.196@cppssbbsa04>...

Rick Rothstein

unread,
Jul 15, 2000, 3:00:00 AM7/15/00
to

> Just to clarify a conjecture that Rick Rothstein posted a few minutes
after
> my first post yesterday, no, the TOP property of the button is not
changing
> at all. Take a look at the Debug.Print output in my original post. It's
> the Height of the Form that is changing unexpectedly.

My post was supposed to convey that the TOP value did *not* change, only
what it was being measured from. That conjecture turns out to be wrong. You
are correct; the height of the form physically changes by a value equal to


the height of the menu bar.


> . ..... I don't think Rick is correct in


> supposing that creating the button after creating the menu will make a
> difference (but I wouldn't bet a Lear Jet on it). That's something else
to
> experiment with

You can safely bet that Lear Jet; it made no difference.


Zero for two . . . I'm pretty good with those "shoot from the hip"
conjectures of mine, huh? <bg>

Rick

Bill McNeal

unread,
Jul 16, 2000, 3:00:00 AM7/16/00
to

Just to further clarify, this problem happens with any of the size
properties (Top, Left, Width, Height). Try something like Me.Width =
Me.Width in the Load event, and it will still do the same thing.

Bill

Chuck Bonner

unread,
Jul 17, 2000, 3:00:00 AM7/17/00
to
Well, I'm about to consider myself totally educated on this issue. Here is
what I have found:

VB3: Unable to reproduce malfunction
VB5: Unable to reproduce malfunction
VB6: Malfunction appears only in IDE

According to my own tests, this is largely a non-problem. I have not been
able to produce an incorrectly sized form in a compiled EXE, no matter which
flavor of VB I compiled it in, and no matter which flavor of Windows I ran
it on (Win95, Win98, Win98SE).

As I stated originally, I think I have a handle on why this happens: When
programmer-supplied code resizes/repositions the Form before it is
displayed, the system leaves it as it was, but otherwise the system resizes
the Form to accommodate the design-time size of the Client area and the
run-time size of the Menu bar. The interaction of these two rules results
in some cases where the system does not compensate correctly. However, as
stated above, I can not find a way to make this happen in an EXE, which is
where it really counts.

Bill says he saw it in an EXE, but I can't make it happen. Unless you can
point me a way to make it happen, I'm going to file this under "interesting
phenomena that might appear unexpectedly in the future," and take no
specific action for now.

Chuck Bonner


Bill McNeal

unread,
Jul 18, 2000, 3:00:00 AM7/18/00
to
Well, I am using Windows 2000 Pro, so maybe that's why I can make it happen
in a compiled EXE. I can consistently make it happen with ease. Just open
the project, making sure the form is not automatically opened, compile to
EXE and run, and bingo, the form is chopped the same as in the IDE.

Bill


Bill McNeal

unread,
Jul 18, 2000, 3:00:00 AM7/18/00
to

I just took the EXE and ran it on a different Win2K computer, and it did NOT
chop the form! Also, the EXE running on an NT4 SP6a computer also does not
chop the form.

Okay, so it's only my single computer running Win2K where the compiled EXE
also doesn't work. Great... Looks like it might be time to reinstall
Visual Studio again.

Michael E. Reed

unread,
Jul 19, 2000, 3:00:00 AM7/19/00
to

On Mon, 17 Jul 2000 12:10:39 -0400, "Chuck Bonner" <Charles...@us.heidelberg.com> wrote:

>Bill says he saw it in an EXE, but I can't make it happen. Unless you can
>point me a way to make it happen, I'm going to file this under "interesting
>phenomena that might appear unexpectedly in the future," and take no
>specific action for now.

I think I have seen it in an EXE also (NT4 SP5 / VS6 SP3) and it seemed to be caused when I made changes in the code window without displaying the form itself, then compiling. I'll experiment with that today and see if I can reproduce it.

/* Michael E. Reed */

Chuck Bonner

unread,
Jul 19, 2000, 3:00:00 AM7/19/00
to

(looking at Bill's two replies and Michael's)

ARGH!

Yes, this is why I filed it away. It might come back, but I still don't
know under what circumstances.

(Taking a few deep breaths.)

Well, this is what keeps life interesting. If we find that there is some
unavoidable circumstance that can cause this bug to exhibit itself, we'll
just have to make that rule for ourselves: If you change any size/position
property of the Form in Form_Load, change *all* of them to what you want.

Chuck Bonner


Michael E. Reed

unread,
Jul 21, 2000, 3:00:00 AM7/21/00
to
On Wed, 19 Jul 2000 08:31:02 -0500, Michael E. Reed <Mi...@compuserve.com> wrote:

> I think I have seen it in an EXE also (NT4 SP5 / VS6 SP3) and it seemed to be caused
> when I made changes in the code window without displaying the form itself, then
> compiling. I'll experiment with that today and see if I can reproduce it.

The problem happened consistently in the IDE if I did not show the form before running the program. I never did get it to fail in the EXE so I'll chalk that up to faulty memory.

0 new messages