|
I think I see where the problem is: the original client height (292) does not include the border, therefore when you subtract (::GetSystemMetrics(SM_CYHSCROLL) + ::GetSystemMetrics(SM_CYBORDER)) from it, you get a value smaller than the real client area. Summary: the border had already been subracted from the client height, and you subtracted it again. 272 is the correct value for the height in this case.
|
|
|
|
|
Thanks for the response, I appreciate it.
The question is really this. When people/you/me account for scrollbars, do we also need to account for the border of the scrollbar with GetSystemMetrics(SM_CYBORDER)? The border I think you were talking about is the border of the client window which I realize I don't need to subtract.
(::GetSystemMetrics(SM_CYHSCROLL) Does this include the entire scrollbar (bar + borders of scrollbar)?
It appears to.
It's just that I saw some code in which the programmer subtracted the border (GetSystemMetrics(SM_CYBORDER))in addition to the scrollbar and so I'm wondering why they did it.
Thanks again.
|
|
|
|
|
No, you do not have to account for the scrollbar's border, and my previous statement should alude to this (I think?).
The best way to test something like this (in my opinion) is to Use FillRect for what you believe to be the correct client area, and see if it covers only the real client area.
|
|
|
|
|
Okay, great. I appreciate your responses. I'll do the FillRect thing and do some testing. Thanks again!
|
|
|
|
|
Yep, 272, the value returned from GetRectClient() does correctly account for the scrollbar's presence/absence. Why other people are using GetSystemMetrics(SM_CYBORDER) along with GetSystemMetrics(SM_CYHSCROLL)is beyond me.
Using dc.FillSolidRect was a good suggestion and helped me to determine what was going on.
Thanks again.
|
|
|
|
|
| Who can recommend some UI tools? Like skin++ uskin ,xttool etc. I am not a genius, but shed more sweat!
|
|
|
|
|
What UI feature are you looking for in a toolkit that MFC (and its Feature Pack) does not offer ?
Few things to consider :
- Support.
- Support.
- Support.
-
...Watched code never compiles.
|
|
|
|
|
Hi,
When using a CListCtrl I am adding a custom CListBox to help with subitem selection.
One particular instance sees the CListBox drawn over the CListCtrl and the parent Dialog.
The Vertical Scroll bar is displayed, and thanks to previous help from users of this site, I can ensure that I know I am managing a ScrollBar movement.
Two points I have issues with are as follows :
1 - The Up button of the scrollbar is positioned over the CListCtrl, and so I have to manually direct the CListBox to handle the Up button of the scroll bar. The problem I have is that holding the Up button down using the mouse only results in a single item scroll, as opposed to continually scrolling up the list as would happen when holding down the down button which would continually scroll down the list. I have added a WM_SCROLL handler to my CListBox, but this only gets called when the down button is held down, the Up arrow message doesnt appear to filter it's way to any control. I've tried adding a WM_SCROLL handler to the CListCtrl, but to no avail.
2 - When trying to grab the scrollbar, I cant drag it if the scrollbar is positioned over the CListCtrl unless I use the down button first and then grab the scrollbar when it is over the parent dialog.
Any ideas on the above would be much appreciated.
Tony
|
|
|
|
|
One possibility for (1) could be (although there will probably best solutions):
When you press down you trigger a Timer with, let's say, 250 or 500 ms, and you kill it when you release the button, scrolling your control at each tick.Regards.
--------
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpfull answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Hi Nelek,
I had thought of that solution, and tried implementing a timer, started using SetTimer(1, 500) with the very thought of doing what you suggest.
The timer, handled using the WM_TIMER route ran once, and then didnt start again. I can only assume that the timer is lost in the message queue somewhere.
Typical implementation used, OnTimer(UINT nEventID) function and CListCtrl::OnTimer(nEventID); called in the function body.
KillTimer was added to my LBUTTONUP handler, and doesnt get called, nor does a KillTimer in my class destructor.
Confused by all this? I am 
Tony
|
|
|
|
|
Mmm...
are you starting paralel processes that can affect the message queue?
or it could be that the focus is changing to other elements and affecting the functions calls.Regards.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpfull answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Problem resolved for issue 1 -
Instead of running a timer in the CListCtrl, I start a timer on the child CListBox (from the CListCtrl) and it manages the vertical scroll bar nicely.
Thanks for focusing me on that point.
Problem 2 is now just to be resolved.
Thanks again
Tony
|
|
|
|
|
Glad to see that you solved the first point.
About the second, the fact that you have to click down with mouse first in order to do the other operation could be caused by having the focus in other place, so the first click bring the focus to where you need and the second time you do it.
If not... sorry, but I am not really getting the point you are explaining.Regards.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpfull answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Hi Nelek,
Thanks for your help.
What I have found with problem 2 is that bringing the CListBox control to the front using BringWindowToTop() gives me the ability to drag the thumbtrack of the scrollbar.
And typically, with that working, the introduced issue is that the CListBox control doesn't draw itself, and it's not until you move the mouse over the scrollbar that the scrollbar becomes visible, and dragging the thumbtrack causes the CListBox to start drawing itself, but not of the style created, i.e. borderless.
Any ideas?
Update - moving BringWindowToTop to the OnNcLButtonDown handler doesnt force the CListBox to hide, and it means that I can handle the thumbtrack - but not until the second time of trying 
Thanks again
Tonymodified on Friday, February 26, 2010 5:35 AM
|
|
|
|
|
Sorry, but I am getting out of ideas. I hadn't an scenario like yours yet, so I can not tell any solution for sure. I think that the problem is not in the Z-Position.
Is it really necessary that the listbox overlaps the listctrl? Couldn't you make it on the side and just hide and/or show according to requirements? So could be easier, as you won't need the ownerdraw styles and so on.
I personally don't like to use some controls into dialogs, for "high-level" controls I prefer to use a CFormView derived class/window.
Have you tried it? You can design them in editor as a dialog, but the functionality is much bigger. Maybe...Regards.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpfull answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I have a code library that i wish to use to draw graphic objects on the view.
I dont want to use the built in functions in MFC. What must we use?
|
|
|
|
|
| GDI+, please check the link for more info [^] Величие не Бога может быть недооценена.
|
|
|
|
|
There aren't built in drawing functions in MFC. There are wrappers to GDI calls.
You may use GDI directly, or as suggested, you may consider using GDI+.
 If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Hello everyone,I develop a MFC application. I display the excel file in the view, but can't hide the file menu bar. How to resolve it.
|
|
|
|
|
I think you want to hide the menu bar of a SDI/mDI app.
If so then use
SetMenu(NULL); Величие не Бога может быть недооценена.
|
|
|
|
|
when I display the excel file in my view, the Excel's menu bar and tool bar will auto display. I want to hide the Excel's menu bar and only display the file.
|
|
|
|
|
I have to build a OCX in VC6.0,
but we have ported it to VS 2008.
But its dependent libs are already build on VS2008, so whether it is possible to build the OCX on VC6.0Ajayraj
|
|
|
|
|
| The VS2008 .lib format is incompatible with the linker in VC6 - that's why you can't use a modern Windows SDK with VC6.... Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
CodeProject MVP for 2010 - who'd'a thunk it!
|
|
|
|
|
no.
in general, static libs are completely incompatible between VC/VS versions. you will need to build VC6 libraries from the source itself.
|
|
|
|
|
Hi,
I would like to write Articles here.
How do I do that?. Help me.
thanks
mridula.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
