|
thanks for replying me.It is really helpfull for me.
|
|
|
|
|
Is there any simple way how to get desktop rect - but without taskbar?
Thank you
viliam
|
|
|
|
|
Check out SystemParametersInfo(SPI_GETWORKAREA...)[^]
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."
|
|
|
|
|
thank you,
that's I was looking for
viliam
|
|
|
|
|
i'm writing an app with the XLAutomation class included into it, the app builds fine, but when i run it sometimes it seems i can't access Excel (read/write) and then i get this error message:
From the XLAut.. class: "ReleaseVariant: unknown type" and "ReleaseVariant: Array contains non-variant type"
and when i debug the error further:
"Unhandled exception in "MyApp" (OLEAUT32.DLL): 0xC0000005: Access Violation"
And it wont go away even if i close the app and restart it, seems theres something in the memory.
somebody know what this means? any solutions?
thanks
|
|
|
|
|
More information would be helpful. Can you show a call stack when the exception is generated and the source code around the line in that triggered it?
Steve
|
|
|
|
|
What I want to do.[^]
(Server seems a bit flaky, hit reload if it fails)
From the image, you can see I've already figured out that I want to remove WS_EX_CLIENTEDGE from the frame window. Problem is that I can remove it in PreCreateWindow(), but something still draws it anyway. Been looking around (Google searches) and it seems there is some problem when trying to remove WS_EX_CLIENTEDGE from a CFrameWnd used as a splitter view but no one's bothered to post whatever solution they figured out.
|
|
|
|
|
Try removing the border flags in a WM_CREATE handler (OnCreate()) for the frame window.
I haven't looked through the source but maybe the splitter sets the style later (seems unlikely
but you never know, well unless you look at the source  ).
Also can you sow your PreCreateWindow code? Are you sure you are removing all the appropriate
styles correctly?
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."
|
|
|
|
|
BOOL CTabFrame::PreCreateWindow(CREATESTRUCT& cs)
{
BOOL x;
x = CFrameWnd::PreCreateWindow(cs);
cs.dwExStyle &= ~WS_EX_CLIENTEDGE;
return x;
}
I verified that this removes the style by using Spy++/Winspector. Yet the border still shows up. It seems to draw it regardless of the style setting. Can't try the OnCreate() thing right now. Got to go to a meeting.
|
|
|
|
|
Thanks. I use this for all my splitter panes and it's ok. You may use other styles in your frame
windows but in my case there's client windows within all of them so I strip all styles except
the two shown.
BOOL CMySplitterPane::PreCreateWindow(CREATESTRUCT& cs)
{
CFrameWnd::PreCreateWindow(cs);
cs.style = WS_CHILD | WS_VISIBLE;
cs.dwExStyle = 0;
return TRUE;
}
Also, make sure any client windowss of frames have their border styles removed as well
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."
|
|
|
|
|
Just tried that. Still doesn't remove it.
Not sure what you are referring to by client windows. I'm not all that familiar with MFC doc/view architecture stuff (I kinda wing it, if you know what I mean).
|
|
|
|
|
dontknowitall wrote: Not sure what you are referring to by client windows.
"Client window" is old-school I guess...I came from Borland's OWL framework originally.
Although, I just checked the MFC docs and they still call them clients 
I'm referring to the child window imbedded in a CFrameWnd window - generally created in a
CFrameWnd::OnCreateClient() override. CFrameWnd contains the "decorations" - toolbar(s), menu,
status bar, etc. - and automagically keeps a "client window" positioned within these
"decorations".
Anyway, the fat ugly border is from the splitter. Not only is the splitter bar drawn but (I
assume) to make the bar blend to the sides, the sides are drawn too. Since the splitter is drawn
"raised" there's no way to get rid of it without drawing your own splitter window.
Here's a screenshot[^] from one of my apps. It's the best I've been able to do with the borders
using tab control and splitter window without drawing anything myself. Anything there defferent
from your results?
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."
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
