|
Software2007 wrote: CComboBox Box;
Box.AddString("xyz"); //This crashes
Here the Box object is not created or associated with a combobox. So, there no valid handle associated with the Box object.
|
|
|
|
|
An assertion is hardly the same as a crash. It's telling you the exact line and file that is problematic (hint: it's not in your call to AddString())."One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
Hi, I am trying to pass Flashvars to send some parameters to a swf using Visual C++, I´ve tried using put_flashvars but it doesn´t work. I am using the videoPlayer.swf that is included in the Adobe Flash Development Server. Using HTML there´s no problem, but in C++ seems not to work.
m_FlashPlayer.put_FlashVars(L"&videoWidth=0&videoHeight=0&dsControl=manual&dsSen sitivity=100&DS_Status=true&streamType=vod&autoStart=true&serverURL=http:/vod/sa mple1.flv");
m_FlashPlayer.LoadMovie(0,L"D:\videoPlayer.swf");
m_FlashPlayer.Play();
I also tried to input the variables in the URL string.
m_FlashPlayer.LoadMovie(1,L"D:\videoPlayer.swf?&videoWidth=0&videoHeight=0&dsControl=manual&dsSensitivity=100&serverURL=rtmp%3A%2Fvod%2Fsample2&DS_Status=true&streamType=vod&autoStart=true");
I don´t know what else to do. I checked in the web but i couldn´t find anything similar. Please help...
|
|
|
|
|
I have a class derived from CListBox which is owner-drawn (I implement the DrawItem function). My problem is I use a white brush for the background, but when the list box is empty, its background is just gray. As soon as one item has been added, the background becomes white.
My drawing function is very simple:
void CNiceListBox::DrawItem(LPDRAWITEMSTRUCT lpDrawItemStruct)
{
CString txt = (const TCHAR*)lpDrawItemStruct->itemData;
CDC dc;
dc.Attach(lpDrawItemStruct->hDC);
CRect r(lpDrawItemStruct->rcItem);
dc.SetBkMode(TRANSPARENT);
dc.SelectObject(m_font);
dc.FillRect(&r, (lpDrawItemStruct->itemState & ODS_SELECTED ) ? &m_selectedBrush : &m_listBoxBackBrush);
dc.DrawText(txt, txt.GetLength(), r, DT_VCENTER | DT_SINGLELINE | DT_LEFT);
dc.Detach();
}
Where's the problem?There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition.
Blaise Pascal
|
|
|
|
|
When the list is empty, there should not be a call to a "drawitem" since there are no items.
The background of the list (empty or not if less items than the size of the list) might dependent of your current color theme (vista, vista aero, xp, ... )Watched code never compiles.
|
|
|
|
|
You could implement the reaction OnEraseBkgnd(CDC* pDC) for your nice box
to process pDC->FillSolidRect(cClienRectOfBox, 0xFFFFFFFF) inside,
as example  Check your definition of Irrationality[ ^]
1 - Avicenna
5 - Hubbard
3 - Own definition
|
|
|
|
|
Do I need to incorporate SM_CYBORDER to catch the border of the horizontal scrollbar or is this value inclusive in SM_CYHSCROLL?
Here is why I am asking
I have a window that I need to know the client height if a scrollbar is present. (horiz scrollbar is not set yet)
GetClientRect returns 292. Using ::GetSystemMetrics(SM_CYHSCROLL) + ::GetSystemMetrics(SM_CYBORDER)
returns 21. Therefore, the window will have a client height of 271 when this window gets a scrollbar.
After the horizontal scrollbar is set I use GetClientRect (which should return 271) It returns 272.
Do I need to incorporate SM_CYBORDER to catch the border of the horizontal scrollbar or is this value inclusive in SM_CYHSCROLL?
GetClientRect is off by one pixel when scrollbar is present
MSDN says SM_CYBORDER = Width and height, in pixels, of a window border. But it doesn't say whether this is already included in the SM_CYHSCROLL value. I saw some code that uses both to determine the scrollbar size so its messing with my head. That pixel may be a misunderstanding of some other factor.
Thanks
|
|
|
|
|
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]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
