|
He say that the code works sometimes... so it should! :/
------------------------------
©0d3 ©®4©k3® - That's me! 
------------------------------
|
|
|
|
|
Two quick questions... [1] What is the *value* (WM_APP + 1, WM_USER + 1, etc.) of the message you are sending, and [2] what are you sending as the WPARAM and LPARAM parameters?
Peace!
-=- James.
|
|
|
|
|
Hey James,
Ok, so WM_USER is defined as:
#define WM_USER 0x0400
which is 1024 in decimal...
The id of the message I'm sending is 1385, so WM_USER + 361.
The WPARAM and LPARAM are both sent as 0, as I don't use them in this message.
 Weird....
Cheers,
swinefeaster
Check out Aephid Photokeeper, the powerful digital
photo album solution at www.aephid.com.
|
|
|
|
|
Just want to post the code for the GetMainUiThreadId() function, as this was asked...
The GetMainUiThreadId() is simple... I basically have a cSubMainApp class
that adds some more functionality to CWinApp. This class has stores the
thread id on the thread that created it (which is always the main ui
thread). It does this with the following code:
m_mainUiThreadId = ::GetCurrentThreadId();
That variable is declared in the class as:
// The thread id of the main ui thread.
DWORD m_mainUiThreadId;
Also, the GetMainUiThreadId() is defined as:
DWORD
cSubMainApp::GetMainUiThreadId(void)const
{
return m_mainUiThreadId;
}
Nothing tricky to it, unfortunately. Any more ideas?
Thanks!
Check out Aephid Photokeeper, the powerful digital
photo album solution at www.aephid.com.
|
|
|
|
|
I want to add more than 256 controls onto a dialog,but after i added 255 controls,no more controls can be created.
Can anybody help me???Thanks a lot!
|
|
|
|
|
Add them with code
Nish
Sonork ID 100.9786 voidmain
www.busterboy.org
If you don't find me on CP, I'll be at Bob's HungOut
|
|
|
|
|
With that many controls on one dialog I would seriously consider redesigning my GUI.
|
|
|
|
|
i agree with mark
:wq
|
|
|
|
|
I need help obtaining a pointer to my CDocument class in a class that I have derived from CTabPageSSL. The TabPageSSL control can be found on this site and it essentially allows you to used child dialog box resources as a TabPage. My problem is this. I need to be able to take text entered on one tab and place it onto a diffent tab.
My view class is CFormView which I have then placed a tab control on the main view. On this control is where I have placed two tabs using the TabCtrlSSL. I can respond to the ON_EN_CHANGE of the individual tabs but I can not figure out how to pass this information on to the CDocument class. In all the examples that I have read and seen, they use a function called GetDocument() but this is only available inside my View class. I have attempted to create a function similar to it inside my derived class for my tab pages, but have had no luck.
Can anyone help me obtain a pointer to my CDocument or is there an easier way to pass information from between my child dialog boxes?
Thanks in advance for any help you can provide.
-Eric
|
|
|
|
|
you can use the following function to get your document from any place in your app (just replace 'CMyDocument')...
CMyDocument* DangerousGetDocument()
{
CWinApp* pApp = ::AfxGetApp();
POSITION p = pApp->GetFirstDocTemplatePosition();
ASSERT(p);
CDocTemplate* pTmp = pApp->GetNextDocTemplate(p);
p = pTmp->GetFirstDocPosition();
ASSERT(p);
CDocument* pDoc = pTmp->GetNextDoc(p);
ASSERT(pDoc);
return reinterpret_cast<CMyDocument*>(pDoc);
}
..have fun...
jk 
|
|
|
|
|
jk,
Thanks for the help. I stumbled onto what appears to be an answer late last night. I am attempting the following...
CFrameWnd *pFrame = (CFrameWnd *)(AfxGetApp()->m_pMainWnd);
CFormView *pView = (CFormView *)pFrame->GetActiveView();
CMyDocument *pDoc = (CMyDocument *)pView->GetDocument();
Thanks again though for the help,
-Eric
|
|
|
|
|
i want to do a CTreeCtrl of own drawing ,who can help me
hope the tops give me a hand !!!!
thanks a lot!!
ZHANGYIFEI
|
|
|
|
|
these codes is part my project:
class CLvlIndexTree : public CTreeCtrl
{
public:
int m_nSplIndex;
...
};
void CLvlIndexTree::OnPaint()
{
CPaintDC dc(this); // device context for painting
CRect rcClip, rcClient;
dc.GetClipBox( &rcClip );
GetClientRect(&rcClient);
// Set clip region to be same as that in paint DC
CRgn rgn;
rgn.CreateRectRgnIndirect( &rcClip );
dc.SelectClipRgn(&rgn);
rgn.DeleteObject();
COLORREF m_wndColor = GetSysColor( COLOR_WINDOW );
dc.SetViewportOrg(0, 0);
dc.SetTextColor(m_wndColor);
// First let the control do its default drawing.
CWnd::DefWindowProc( WM_PAINT, (WPARAM)dc.m_hDC, 0 );
HTREEITEM hItem = GetFirstVisibleItem();
int n = GetVisibleCount();
// the most urgent thing is to erase the labels that were drawn by the tree
while(hItem!=NULL && n>=0)
{
CRect rect;
GetItemRect( hItem, &rect, TRUE );
dc.FillSolidRect(rect.left,rect.top,rect.Width(),rect.Height(),m_wndColor);
hItem = GetNextVisibleItem( hItem );
n--;
}
// create the font
CFont *pFontDC;
CFont fontDC, boldFontDC;
LOGFONT logfont;
CFont *pFont = GetFont();
pFont->GetLogFont( &logfont );
fontDC.CreateFontIndirect( &logfont );
pFontDC = dc.SelectObject( &fontDC );
logfont.lfWeight = 700;
boldFontDC.CreateFontIndirect( &logfont );
// and now let's get to the painting itself
UINT nDrawFormat = DT_CENTER;
BOOL bFoundSpl = FALSE;
hItem = GetFirstVisibleItem();
n = GetVisibleCount();
while(hItem!=NULL && n>=0)
{
CRect rect;
BOOL bBold = (GetParentItem( hItem ) == NULL);
BOOL bSplColor = FALSE;
if ( bBold && !bFoundSpl && m_nSplIndex >= 0 )
{
HTREEITEM hTmpItem = GetRootItem();
int index = 0;
while( hTmpItem != NULL )
{
if( index == m_nSplIndex && hTmpItem == hItem )
{
bFoundSpl = TRUE;
bSplColor = TRUE;
}
hTmpItem = GetNextSiblingItem(hTmpItem);
index++;
}
}
UINT selflag = TVIS_DROPHILITED | TVIS_SELECTED;
if ( !(GetItemState( hItem, selflag ) & selflag ))
{
dc.SetBkMode(TRANSPARENT);
CString text = GetItemText( hItem );
GetItemRect( hItem, &rect, TRUE );
dc.SetBkColor( m_wndColor );
dc.SetTextColor( bSplColor ? RGB(255,0,0) : RGB(0,0,0) );
if( bBold )
dc.SelectObject( &boldFontDC );
dc.DrawText(text, rect, nDrawFormat);
if( bBold )
dc.SelectObject( &fontDC );
dc.SetTextColor(::GetSysColor (COLOR_WINDOWTEXT ));
}
else
{
GetItemRect( hItem, &rect, TRUE );
COLORREF m_highlightColor = ::GetSysColor (COLOR_HIGHLIGHT);
CBrush brush(m_highlightColor);
dc.FillRect (rect, &brush);
// draw a dotted focus rectangle
dc.DrawFocusRect (rect);
CString text = GetItemText( hItem );
dc.SetBkColor(m_highlightColor);
dc.SetTextColor(::GetSysColor (COLOR_HIGHLIGHTTEXT));
if( bBold )
dc.SelectObject( &boldFontDC );
dc.DrawText(text, rect, nDrawFormat);
if( bBold )
dc.SelectObject( &fontDC );
}
hItem = GetNextVisibleItem( hItem );
n--;
}
dc.SelectObject( pFontDC );
}
|
|
|
|
|
With VC++ 7 they have removed the helper functions CreateElements and DestructElements for the template collection classes. You are supposed to be using constructors and destructors now, but this is a big problem when the collection contains pointers to objects since I used to do something like this...
CSomeClass * pItem = new CSomeClass();
CArray < CSomeClass*, CSomeClass* > array;
array.Add(pItem);
Then I would override DestructElements to delete the objects when elements of the collection were deleted.
No more!
I have a lot of code using the collection classes like this and the only thing I can think of is to rewrite it using smart pointers as the collection elements, using reference counting so the objects can delete themselves when no longer referenced.
This is a pain in the *** though, any alternatives?
|
|
|
|
|
I guess the most viable alternative is replacing your raw pointers with some sort of refcounted smart pointers, as you pointed out. Maybe Boost shared_ptr is useful to you.
It kind of strikes me VC++ 7 guys have been so inconsiderate to break backwards compatibility this way. If you accept an advice, you'd be beter off migrating to STL containers (after all, you'll be rewriting code anyway), which are less likely to break between releases of the compiler.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Hi,
I'm wondering how to grab the generic system icons, like the one for a hard drive, cd-rom drive, that kind of stuff. I remember reading an article about this somewhere, but can't seem to find it. Anyway, I want to build an image list out of these little icons. Anybody got any sample code? Maybe LoadResource, LoadImage, something like that's involved?
Thanks,
Aaron
|
|
|
|
|
The icons you refer to are the so called shell icons. These you can load from shell32.dll as follows:
HINSTANCE hShell32=LoadLibrary("SHELL32.DLL");
HICON hicon=LoadImage(hShell32,MAKEINTRESOURCE(nIcon),IMAGE_ICON,0,0,LR_DEFAULTSIZE|LR_SHARED);
...
FreeLibrary(hShell32);Experiment with different values of nIcon starting with 0 till you find the one you're looking for.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
You can also use the icon-select dialog and load shell32.dll in order to find the indicies to the icons.
the quick way to get one of these windows is to change the icon of a shortcut.
// Rock
|
|
|
|
|
Hello,
I have a newbie question about staticly linked exe's.. lets say you make an app that takes advantage of IE 4.0 dll's for a list control.. and you staticly link the .exe when you compile.. does the user that installs the software still require IE 4? Or is that included in the exe?
Rob
|
|
|
|
|
Static MFC linking does away with the need to distribute the MFC DLLs along with your app. However, the list control lives in ComCtl32.dll and can't be statically linked into your app. Hence, the user's system must have a valid version of ComCtl32.dll.
Btw, there are ways to easily ensure that an appropriate version of the DLL is present. Articles at CP describe this.
/ravi
"There is always one more bug..."
ravib@ravib.com
http://www.ravib.com
|
|
|
|
|
Nope, only the MFC dll's are included in the exe. I think though, that a machine having a min. of IE4 is a fair assumption today.
Simon
"Does the room have a CView?"
Sonork ID 100.10024
|
|
|
|
|
Yes it would. There isn't a static version of IE.
Static and dynamic linking can be thought of as more of a hint that include files can use to decide if they should request the static or dynamic versions of the libraries. If an include only supports one or the other, then it always uses that option.
For example, take a look at ::CreateWindow. It links to USER32.DLL (I think). There is no static version of USER32.DLL.
Tim Smith
Descartes Systems Sciences, Inc.
|
|
|
|
|
Many DLLs come with a companion .lib library that you link your EXEs with (the so called import libraries). This import libraries do automatically the task of loading the associated DLL (thru LoadLibrary and retrieving the addresses of all the DLL functions declared in the DLL's header file through GetProcAddress). What this libraries don't do is fetch the DLL itself along with your app.
So, if you deploy an EXE statically linked to an import library to a system lacking the corresponding DLL, the program won't even start (a message box appears with a message saying something like "this program requires missing foo.dll").
If the corresponding DLL exists, but it's a prior version than you expected (as it is often the case with comctl32.dll, which is constantly updated by succesive releases of IE), then your program may start and yet show strange behaviors, like featuring list controls without all the graphic gadgets you designed the app for. In that case you should instruct the user to download the appropriate version of the DLL (in the comctl32.dll case the standard requirement is having IE vX.X installed on the target machine).
I strongly suspect your actual problem has precisely to do with comctl32.dll. If so, you might find MSDN article Shell and Common Controls Versions useful.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Hello everyone!!!
I am using email services of a Microsoft MAPI ActiveX control(msmapi32.ocx) by 2 totally identical instances of MFC apps except that each instance is running on a different server. Both servers have Outlook services installed and proper connections to company's mail server are established, therefore, each server sends email without any problems. Each copy of msmapi32.ocx is properly registered on each server box. My MAPI control is instantiated and interfaced through CWnd wrapper class.
The problem is that one application on one server is working whereas another doesn't.
After dumping log information I have observed the following interesting things:
1) When the working application instantiates component through CWnd's Create() function, wrapper's HWND is NOT 0, BUT the failing application has wrapper's HWND == 0.
2) Even if wrapper's HWND == 0, component's properties and methods can be easily accessed without any exception thrown, but, of course, NO ACTION is DONE.
My questions are:
1) Does anyone know where the problem is?
2) When wrapper's Create() function instantiates OLE control, is "HWND" CORRECT indicator about the success of contorol's instantiation.
3) If 2 is wrong, how can I find out through the CWnd-wrapper object wether the component is breathing or not.
Thanks so much in advance.
Kirill
|
|
|
|
|
I would say having HWND==0 is a clear indication that the ActiveX control is not working.
Is by chance the machine where your app works the one where you have installed your development environment? If so, you might be experiencing problems because the second server needs some sort of license that is already covered by the development license installed on the first machine. I haven't explored the issue in detail, but seems like some sort of license is actually required for using msmapi32.ocx.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
