|
Not if the user of your dll creates instances of MyStruct itself. It needs to be a complete type if the user of your DLL is to create instances of it.
If you delegate all creation/destruction of MyStruct instances to the dll, you can achieve something like this. I've seen this sort of thing done with void *'s for the interface. I don't know if you could do this with a pointer to an incomplete type. If not, you could get a sort of type safety by wrapping the void * in a struct of its own with the definition of that struct exposed to the consuming application.Please do not read this signature.
|
|
|
|
|
I have the following crash which the debugger points to:
_AFXWIN_INLINE int CComboBox::AddString(LPCTSTR lpszString)
{ ASSERT(::IsWindow(m_hWnd)); return (int)::SendMessage(m_hWnd, CB_ADDSTRING, 0, (LPARAM)lpszString); }
here is sample code:
Class B: public CDialog
{
CComboBox Box;
Box.AddString("xyz"); //This crashes
}
Class A: public CFormView
{
B pDlg(NULL); //launches Dialog B
}
|
|
|
|
|
You cannot "update" a control in a dialog before it's created.
so, all initialization must be done atleast after the OnInitDialog is called, and even in the OnInitDialog after the call to the base class OnInitDialog.
anyway, your code looks weird; are you certain that even compiles ?Watched code never compiles.
|
|
|
|
|
That isn't the exact code, was trying to show the problem without lots of code. I did figure it out, I was initializing before "UpdateData(FALSE)" in the OnInitDialog() function.
Thanks
|
|
|
|
|
Software2007 wrote: I did figure it out, I was initializing before "UpdateData(FALSE)" in the OnInitDialog() function.
You're calling UpdateData() in OnInitDialog()?  "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
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
