Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 883
  • Last Modified:

statusbar without sizing grip

I'm using CStatusBar to create a status bar which I'm
placing at the top of my frame.  I want to get rid of the
resizing grip that's on the status bar.  (In other words, I
don't want it created with the SBARS_SIZEGRIP style.)  Once
it is created, modifying the window style to remove this
does not seem to work for me.  Do I have to roll my own
status bar from CStatusBarCtrl in order to remove the sizing
grip?

I'd like to see some sample code to create a status bar
without this sizing grip.  If it is a big effort, I'll
increase the points.  :)
0
eric_m
Asked:
eric_m
  • 6
  • 4
  • 2
  • +2
1 Solution
 
plebelCommented:
you may overwrite the PreCreateWindow() for midifying styles or extra styles

if it's not working, you may also use SetWindowLong with the GWL_STYLE nIndex, this let you modify any window parameters

0
 
eric_mAuthor Commented:
Plebel:

Have you tried overriding PreCreateWindow from CStatusBar?
It's not declared virtual, so doing so won't be trivial.

I have found the following in CStatusBar::Create...

      if (pParentWnd->GetStyle() & WS_THICKFRAME)
            dwStyle |= SBARS_SIZEGRIP;

If I remove WS_THICKFRAME from the parent window's style
before creating the status bar and then restore it
afterwards, the status bar is drawn without a grip...just
like I want.  This is an ugly hack, however, and subject to
break when Microsoft's implementation changes.  I'm looking
for an elegant technique that is a bit more stable.  :)

Thanks!

0
 
snoeglerCommented:
Another possibility:

m_StatusBar->ModifyStyleEx(SBARS_SIZEGRIP,0);

See ModifyStyleEx online docs. It is used to manipulate windows styles - i think that is what
you need.
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
eric_mAuthor Commented:
snoegler:

Once the CStatusBar::Create method is called, neither
ModifyStyle nor ModifyStyleEx appears to remove the
SBARS_SIZEGRIP style.  Even thought it is a CWnd, it doesn't
appear to be behaving like one.  :/

0
 
eric_mAuthor Commented:
plebel:

My mistake...PreCreateWindow *is* virtual...just not declared so in
the header for CStatusBar.  I did just that, and it works like a
charm.

BOOL MyStatusBar::PreCreateWindow(CREATESTRUCT& cs)
{
  if (cs.style & SBARS_SIZEGRIP)
    {
      cs.style -= SBARS_SIZEGRIP;
    }

  return CStatusBar::PreCreateWindow(cs);
}

Thanks!  Please re-answer the question, and I'll award your points.
:)

0
 
mikeblasCommented:
Responding to ModifyStyle() or ModifyStyleEx() is not an attribute of "acting like a CWnd".  It's an attribute of the implementation of the actual window--for the status bar, that means that COMCTL32.DLL doesn't react to WM_STYLECHANGED or WM_STYLECHANGING.

That is, it's not a bug in MFC as you imply; it's an effect of the implementation provided by Windows.

B ekiM
0
 
mikeblasCommented:
By the way, your override of PreCreateWindow() is wrong. The big problem is that you should post-inherit.  Further, you don't need an if() statement and your use of the -= operator is dubious.

BOOL MyStatusBar::PreCreateWindow(CREATESTRUCT& cs)
{
   if (!CStatusBar::PreCreateWindow(cs))
      return FALSE;

   cs.style &= ~SBARS_SIZEGRIP;
   return ;
}

Calling PreCreateWindow() after you change the style is wrong, as the base-class implementation might change the syle bits itself.

B ekiM

0
 
eric_mAuthor Commented:
Mike:

> The big problem is that you should post-inherit.
 
Thanks for pointing that out.  I hadn't thought of that.

I had meant to type "^=" instead of "-=".  But you're
right...using AND NOT saves the if comparison over the XOR.

> It's an attribute of the implementation of the actual
> window--for the status bar, that means that COMCTL32.DLL
> doesn't react to WM_STYLECHANGED or WM_STYLECHANGING.

> That is, it's not a bug in MFC as you imply; it's an effect
> of the implementation provided by Windows.

I don't understand what you mean by "it's an attribute of
the implementation..."  If CStatusBar is a CWnd, then I
should be able to use an instance of CStatusBar wherever I
would want to use a CWnd.  If I can modify a CWnd using the
method ModifyStyle, then I should likewise be able to modify
a CStatusBar using the same method.  Please correct my
thinking on this and help me understand what I'm missing.
Thanks!

I really appreciate your time, Mike!  :)

0
 
mikeblasCommented:
If CStatusBar is a CWnd, it just means that it has an HWND.  CStatusBar is polymorphic with CWnd, but MFC (nor Windows) imply no stronger contract. That is, just because the members polymorph doesn't mean that they have true function or meaning.

Any window class (that is, a Windows window class, not a C++ window class) can decide to handle or ignore whatever messages it wants to.  And it might do so on a flag-by-flag basis. For example, using CStatusBar::ModifyStyle() might work to change the border, but might not work to change the gripper flags.

CStatusBar::ModifyStyle() _is_ an allowable call on a status bar object, just like it's an allowable call on any CWnd object. You're making the appropriate window call, and it's safe and reasonable call to make.  But the Windows implementation of the handler for that function, when the window in question is a status bar control, doesn't do anything.

Being able to alter the window proc for a window is not a feature of MFC, it's the way Windows was designed.  It would be foolish to write a C++ class library and change derivations (eg, derive CStatusBar from CCmdTarget instead of CWnd) just because some members did or didn't actually cause a visible effect.

B ekiM

0
 
mikeblasCommented:
I guess that didn't come out as clear as I wanted it to.  You're saying "If I can modify a CWnd using the
method ModifyStyle, then I should likewise be able to modify
a CStatusBar using the same method."

That's wrong. It would be correct to say: "If you can _ask_ a CWnd to change its style using the method ModifyStyle, then you should likewise be able to _ask_ a CStautsBar using the same method".

The rub is that actual system-provided implementation of _any_ window might decide to completely ignore your request.

B ekiM
0
 
regbanCommented:
Please read October MSJ!
0
 
eric_mAuthor Commented:
Regban:

Any particular article in the Oct MSJ?  I don't see the
relevant article by looking at their table of contents.


Mike:

Thanks for your explanation.

I've got another question regarding changing styles of a
status bar...

Is there an easy way to change the thickness of the borders
between panes in a status bar?  I found m_cxLeftBorder,
m_cxRightBorder, and m_cxDefaultGap as data in CControlBar.
I tried changing them, and the left and right border data
members work just as I expected...they alter the thickness
of the left and right borders.  I can't see that
m_cxDefaultGap changes anything, though.

Should I move this to a new question, or is it alright here?

Thanks!


Eric

0
 
plebelCommented:
This is for the answer you forgot to pay me

It was a pleasure :)
0
 
eric_mAuthor Commented:
Thanks for your help, Plebel.  I've re-asked my 2nd question
in another topic...that would probably be more appropriate.
Please see the following:

http://www.experts-exchange.com/Q.10082572


0
 
regbanCommented:
Read page 34 and 35 of MSJ october 98.
0

Featured Post

Important Lessons on Recovering from Petya

In their most recent webinar, Skyport Systems explores ways to isolate and protect critical databases to keep the core of your company safe from harm.

  • 6
  • 4
  • 2
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now