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?
> 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...
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
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
www.Exit109.com/~wildwood
Bill McNeal wrote in message <#0p48hO7$GA....@cppssbbsa02.microsoft.com>...
--
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...
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.
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
"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
"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>
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
--
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
www.Exit109.com/~wildwood
Bill McNeal wrote in message <##3OrPb7$GA.196@cppssbbsa04>...
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
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
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.
>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 */
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
> 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.