VB6 SSTab: Left-shifting of Controls on Tabs
Rod R.
shifts all the controls on all other tabs to the left by
subtracting 75000 from their Left properties. These shifts
to the left cause all controls on all other (non-current)
tabs to be temporarily invisible to the user. Only the
controls on the current tab can be visible. When the user
clicks on a different tab, VB adds 75000 to the Left
properties of the controls on the new current tab to make
them visible and subtracts 75000 from the Left properties
of the previous tab to make them invisible.
What is the recommended way to programatically set the
Left properties of controls on the various tabs so as not
to "get in the way of VB's subtracting 75000"? If I try a
straight-forward assignment of Left property values on
controls on various tabs, I'm apparently doing so after VB
subtracts the 75000. During what event, if any, can I
assign Left property values before VB does all of its left-
shifting?
Or do I need to subtract the 75000 myself from each
control appearing on a tab other than tab 0? (Tab 0 is the
default initial current tab. It seems that VB subtracts
75000 from the Left properties of controls on all tabs
other than tab 0 before I assign values to the Left
properties of these controls. I'm thus "stepping" on the
left shifts made by Visual Basic.)
Is the value of the left shift a constant 75000? Can it
vary with the desktop area?
And, where the heck is this subtraction of 75000
documented in the VB help screens? I've been pulling my
hair out trying to understand why controls on non-current
tab are appearing on my current tab!
Rod R.
Ken Halter
Subject: VB6 SSTab: Setting Left Properties on Controls in Tabs > 0
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&th=7b63c85452d87ff7&rnum=1
Still no help? This doc tells about the 75000 issue..
HOWTO: Resize the Controls in SSTab When Form is Resized
http://support.microsoft.com/default.aspx?scid=kb;en-us;187562
This sample (and explanation) didn't help?
Subject: Re: Lost focus?
http://groups.google.com/groups?q=+%22manageframes%22&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=u0%24AtPLECHA.1064%40tkmsftngp04&rnum=1
The bottom line is... if you move a control that's not on the current tab (not counting
the frame control array trick I posted above), the SSTab gets lost. The SSTab stores all
control positions at design time.. when you change the positions at runtime, the SSTab has
no way of "knowing".. This means that it's trying to move the controls to "what it thinks"
is the correct location, based on where they were located at design time. You probably
already know that.... no matter how many tabs there are, the SSTab is one (and only one)
container. Moving the controls far off screen is the only way it can make controls
show/hide when a new tab is selected. Without the frames, you'll be constantly fighting
this "feature".
--
Ken Halter - MS-MVP-VB - http://www.mvps.org/vbsight - Please keep it in the groups..
"Rod R." <rodr...@prodigy.net> wrote in message
news:02d601c2e438$6f2d3390$a301...@phx.gbl...
Rod R
Thank you for your reply.
I did, indeed, submit two messages on the same question. I
throught I submitted my first message to the
microsoft.public.vb.controls group. When I saw that it
didn't get posted to this group, I thought it got lost
somewhere in the internet graveyard so I rewrote and re-
posted the message. Please tell me where my first message
got posted, so I can learn from my mistake.
Yes, the article "HOWTO: Resize the Controls in SSTab When
Form is Resized" helps.
But, I think the direct answer to my question is: (1) The
program can set the left property of any control on the
current tab normally; however, (2) if the program needs to
set the left property on controls on other than the
current tab, the program needs to subtract 75000 from each
computed left property.
Is this direct answer correct?
If so, then, shouldn't something like this direct answer
have been included in the Visual Basic Help Screens SSTab
topic? (1) It's not intuitively obvious, and (2) it sure
could have saved me hours and hours of frustrating trial-
and-error debugging. The fact that Visual Basic left-
shifts controls by 75000 on non-current tabs is rather
significant and relevant, it seems to me.
>.
>
Ken Halter
add/subtract. It just wasn't designed to allow repositioning of controls. The control
itself is quite old.. regardless of what version it reports, the code that makes it work
hasn't changed since VB4 (well early VB5 anyway). The help on that control is equally old.
Most likely copied and pasted from the original help files provided by Sheridan (which is
where that control came from). If you use the "array of frames" method, a lot of SSTab
bugs/issues disappear completely. The TabStrip control doesn't suffer from these problems
because it's not a container. You may want to play around with that and see if you like it
better... For one thing, it takes on the "XP Look" when the correct code and manifest is
supplied. The SSTab will never take on that look. It's ancient and there are no plans to
improve it (imo). I got tired of SSTab "wierdnesses" too and built my own tab control
(http://www.mvps.org/vbsight/TBGDialogCTL.htm). I'm not sure what people have against
placing only a single frame on each tab and then placing their controls inside of these
frames... but it's surely worth the 10 seconds (or less) per tab to do it.
--
Ken Halter - MS-MVP-VB - http://www.mvps.org/vbsight - Please keep it in the groups..
"Rod R" <rodr...@prodigy.net> wrote in message
news:07ff01c2e449$33312700$3001...@phx.gbl...
Rod R
Thank you for your candid answer.
Your suggestion of an "array of frames" is a reasonable
workaround.
I just wish the SSTab Help Screen either (1) suggested it,
or (2) warned us against positioning controls on tabs
programatically.
I'll take a look at your tab control.
Thank you, again.
>.
>