|
Looking at your pic it looks like your second toolbar (the bottom one immediately above the tab control) is acting as a parent window, not a sibling window as it should be. Notice how it's right hand side border extends down to and around the bottom of your view, while on the left hand side there is no border present at all.
Look into that as I am going to assume that is where your problem lies, not in the frame window itself.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
What are you talking about? The hierarchy goes:
MainFrame w/ Standard toolbar
|- Vertical splitter
|- Tree view
|- Horizontal splitter
|- CFrameWnd w/ Standard toolbar
|- CTabCtrl wrapped up in a view.
|- CScintillaView
|- IWebBrowser2 view
|- CFrameWnd w/ Standard toolbar
|- CReportCtrl (a CP project)
Using ST_SplitterWnd here on CP for splitters.
There's nothing hokey with the toolbars AFAIK - CFrameWnd is managing the toolbar. And the image is a mockup I put together using Photoshop. However, I know it is possible to remove the style because I removed it with Winspector (but the effect was only temporary - resizing the window/moving the splitter restored it even though the style was still gone).
|
|
|
|
|
You're not using the MFC splitters? 
The splitter changes the style of the window back to clientedge? Can you remove that from the
splitter code?
Mark
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
Well, ST_SplitterWnd (here on CP) seems to wrap up MFC splitters in a "nicer" way (it IS derived from CSplitterWnd). I dunno - it works pretty well for various three-pane apps I've done. Just a couple function calls and - voila - new splitter with view. However, for this one view, I want to drop the border (client edge) that gets drawn.
Where does it change the style in ST_SplitterWnd? Only place I've found WS_EX_CLIENTEDGE is in PreCreateWindow() and I've already done the necessary changes to that function. Spy++ and Winspector confirm that the client edge is gone...yet it is drawn anyway.
Here's how the CFrameWnd gets created:
ST_SplitterWnd::Create() calls CSplitterWnd::CreateView().
CSplitterWnd::CreateView() dynamically creates the view and then calls Create().
Create() calls PreCreateWindow() which calls my derived PreCreateWindow().
My PreCreateWindow() calls CFrameWnd::PreCreateWindow(), which alters the extended style to include WS_EX_CLIENTEDGE.
My PreCreateWindow() alters the style as Mark suggested.
The ST_SplitterWnd class doesn't alter WS_EX_CLIENTEDGE.
|
|
|
|
|
Cool. So what are you seeing at this point? Any change from your original screenshot?
You should only see the splitter window border. Are you seeing anything ugglier on the boders
than in these screenshots?
Screenshot 1[^]
Screenshot 2[^]
Mark
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
No change from the original screenshot (actually a mockup done in Photoshop of two separate screenshots - the one in the 'red rectangle' is what actually appears - the rest is a screenshot where I used Winspector to remove the WS_EX_CLIENTEDGE style - it changed instantly when CFrameWnd had the style [i.e. before I started fiddling with PreCreateWindow()]).
I can't tell what the difference is because you've got themes enabled - it is a lot easier to tell what is going on if themes are disabled. However, I do notice one thing different: My toolbar has a line below it while yours doesn't. That line is there because the tab control (view) has the WS_EX_CLIENTEDGE style. I want it that way because it looks better. However, it creates the "double-border" thing because the splitter or frame window is drawing another "client edge".
|
|
|
|
|
dontknowitall wrote: That line is there because the tab control (view) has the WS_EX_CLIENTEDGE style. I want it that way because it looks better.
Yeah I've gone back and forth on that one. Still undecided!
dontknowitall wrote: However, it creates the "double-border" thing because the splitter or frame window is drawing another "client edge".
Exactly! I've been looking at the CSplitterWnd code (that's always bugged me).
Eventually I'l have time to write my own splitter but custom UI is on the back burner for me 
Mark
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
Mark Salsbery wrote: Yeah I've gone back and forth on that one. Still undecided!
Me artist. Me like pretty. Me say it look better, it be better.
Ook. Ook.
Mark Salsbery wrote: Eventually I'l have time to write my own splitter but custom UI is on the back burner for me
So...what you are saying is that I'd have to roll my own splitter? ST_SplitterWnd is probably a better codebase to start from and then just override the painting code from CSplitterWnd in ST_SplitterWnd but that would really only be necessary for the case where someone wants to set an alternate style. The default works pretty well for most cases.
|
|
|
|
|
Overriding the painting part is fairly easy. It's all the calculations for repositioning the
view panes that are based on the 3D border that are the problem!
CSplitterWnd::OnDrawSplitter() overridable looks interesting...
If you do all that work, I'll gladly "test" it for you for free
Mark
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
I'm still looking at the CSplitterWnd code. There's a few handy undocumented overridables.
May not be as much work as I thought...
I'm going to try a bit and see what happens.
Opening the can of worms...
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
Here's a custom CSplitterWnd class - all I changed was the constructor
Needs a little work but getting rid of the fat 2 pixel border helps.
I'd like to draw them more subtle like Visual Studios...
(I removed themes for these screenshots)
Before (CSplitterWnd)[^]
After (CMySplitterWnd)[^]
class CMySplitterWnd : public CSplitterWnd
{
public:
CMySplitterWnd();
};
CMySplitterWnd::CMySplitterWnd() : CSplitterWnd()
{
m_cxSplitter = m_cySplitter = 3;
m_cxBorderShare = m_cyBorderShare = 0;
m_cxSplitterGap = m_cySplitterGap = 3;
m_cxBorder = m_cyBorder = 0;
}
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
These settings seem more pleasing...
m_cxSplitter = m_cySplitter = 3 + 1 + 1;
m_cxBorderShare = m_cyBorderShare = 0;
m_cxSplitterGap = m_cySplitterGap = 3 + 1 + 1;
m_cxBorder = m_cyBorder = 1;
Here's a screenshot[^]
-- modified at 21:03 Wednesday 21st February, 2007
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
Not exactly the effect I'm going after. It affects both sides of the splitter. I want to control just the "client edge" drawing of one specific view. In this case, the code should only affect just one side of the splitter (top part).
Figure how how to affect the drawing of a single side of a splitter and you'll probably have code worthy of a CP article on your hands.
|
|
|
|
|
That may be easy. There's a documented override for the drawing. I'll try in the morning
(11:17pm here )
It looks like I need something similar with a splitter on a tab control. The top line of the splitter pane box messes up the indication of which tab is selected.
Mark
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
Mark Salsbery wrote: That may be easy. There's a documented override for the drawing. I'll try in the morning
(11:17pm here )
Get anywhere with that?
|
|
|
|
|
I'm back on it - got totally sidetracked on some emailed code yesterday
I shall return...
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
Ok. So far I can control...
Splitter width
3D Border width (0,1,2(default))
Which border sides are drawn
All the colors of the drawn border sides (if thickness 2, 2 colors each)
Face color of splitter bar
All border and face colors of the splitter box (shown/used on dynamic splitters)
Useful?
dontknowitall wrote: I want to control just the "client edge" drawing of one specific view
That would be tough - I need to investigate that further.
Still finishing it up in article-worthy (hopefully) fashion.
Mark
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
(Rex Kramer "Airplane!")
|
|
|
|
|
Mark Salsbery wrote: Ok. So far I can control...
Splitter width
3D Border width (0,1,2(default))
Which border sides are drawn
All the colors of the drawn border sides (if thickness 2, 2 colors each)
Face color of splitter bar
All border and face colors of the splitter box (shown/used on dynamic splitters)
Useful?
Interesting. I'd probably have to see a demo app. in action. Or get sleep. One of the two anyway.
Mark Salsbery wrote: That would be tough - I need to investigate that further.
Hmm...maybe it can be faked by setting border width to 0 and then setting WS_EX_CLIENTEDGE on each view EXCEPT the views that authors don't want. Would that work? I'll try it sometime in the next two days with ST_SplitterWnd, but it would be nice to know if it will work up front before I burn a couple hours trying.
|
|
|
|
|
dontknowitall wrote: Hmm...maybe it can be faked by setting border width to 0 and then setting WS_EX_CLIENTEDGE on each view EXCEPT
Good idea. I'll send the code tomorrow am - it's easy enough to test - it's derived from
CSplitterWnd.
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
(Rex Kramer "Airplane!")
|
|
|
|
|
|
Anything happening with this? I've been busy with other projects and haven't had time to try anything out.
|
|
|
|
|
|
|
Yossi_pRJ wrote: ...even when it terminated in brutal such as closing the console.
I am not sure you can do that reliably - under some situations, even trying to closing the console can result in a process being forceably terminated as opposed to ending normally. Launch a command prompt, run the FTP client in it and then try to close the console window by clicking the [X] for an example.
I do not know of a single way to have a process be able to execute some kind of atexit(...) functionality in all cases of the process ending (normally or abnormally).
My suggestion, if something MUST run regardless of how the process ends, is to have another lightweight process that gets the HANDLE to the first process, and when the HANDLE becomes signaled, it indicates that the first process has ended and your second program can do/run something.
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
