|
I'm writing an app that uses multiple CAxDialogImpl pages within a CWindow - I will hide them and show them as needed (like a property sheet, but I don't want the tabs and other buttons).
The dialog children can keep a pointer to the parent, but how do I have a generic pointer to the active child? At the moment I'm just keeping the window handle and that will get me by for a couple of days, but I'm going to need a pointer to these classes, but I cannot use a base class because all the dialogs are temples using CAxDialogImpl.
Suggestions?
David Stidolph
Winternals
Austin, TX
|
|
|
|
|
All CAxDialogImpl<...>s derive (by default) from CWindow. Can't you use this as your base class?
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
hi everyone! i have the following problem: i have,
#define SOME_CONST 10
typedef struct
{
void* pData;
} SomeStruct;
and then,
static __declspec(thread)
SomeStruct ArrayStruct[SOME_CONST];
and then later in the same file, while initializing my thread local storage data (this function is called once for every new thread that i start, for initialization),
static void SomeFunc(void)
{
for(int i = 0; i < SOME_CONST; i++)
{
ArrayStruct[i].pData = NULL;
}
return;
}
this works fine when i use this code in my console app, but when i use the same code in my dll (doesn't use mfc), it crashes and exits saying access fault and that some memory could not be "read". the access violation happens at i == 0, ie in the first iteration of the for loop. what gives? 
-----------Muralia Dhar
--*--*--*--*--*--*--*--
What goes up, comes down. Ask any system administrator.
--*--*--*--*--*--*--*--
|
|
|
|
|
Are you explcitiy loading the DLL with LoadLibrary? The docs say __declspec(thread) should not be in conjunction with explicit loading.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
er, i think the docs say that __declspec(thread) interferes with delay loading... and the docs also tell me that delay loading is something which *relieves* you from calling LoadLibrary and GetProcAddress. i AM using Loadlibrary in fact, but this is because i thought there would be no problems with that. am i wrong in my assumption? if so, what should i do to get it working? how do i call my functions in the dll?
thanks a lot for helping me out... 
Muralia Dhar
--*--*--*--*--*--*--*--
What goes up, comes down. Ask any system administrator.
--*--*--*--*--*--*--*--
|
|
|
|
|
If I'm understanding the docs, delayed loading poses the same problems with respect to __declspec(thread) as using LoadLibrary and GetProcAddress. Please see the last paragraph of MSDN article Rules and Limitations for TLS. Basically, seems like your only options are:- Statically link your library (using the import associated
.lib), - abandon
__declspec(thread) and use TlsAlloc and related stuff instead.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
It just won't work. I try the simplest trayicon program and I can't do it. I did it 2 years ago but the code was lost.
The simplest stuff if to use MFC to create a Dialog based project. When a button is pressed this code is called
NOTIFYICONDATA pnid;
pnid.cbSize=sizeof(NOTIFYICONDATA);
pnid.uID=1;
pnid.hWnd=this->m_hWnd;
pnid.uFlags=NIF_MESSAGE|NIF_ICON|NIF_TIP;
pnid.uCallbackMessage=WM_NOTIFYICON;
strcpy(pnid.szTip,"Hello");
pnid.hIcon=AfxGetApp()->LoadIcon(IDR_MAINFRAME);
Shell_NotifyIcon(NIM_ADD,&pnid);
I used View->ResourceSymbols to declare WM_NOTIFYICON to 666 (it must be the devil's hand here )
Afterwards in trayDlg.cpp I added in the BEGIN_MESSAGE_MAP section the line ON_MESSAGE(WM_NOTIFYICON,On_WM_TrayIcon) wich means if the WM_NOTIFYICON is sent then call On_WM_TrayIcon
and added at the end of the program the function
void CTrayDlg::On_WM_TrayIcon(WPARAM wParam, LPARAM lParam)
{
switch((UINT) lParam)
{
case WM_LBUTTONDOWN:
AfxMessageBox("L BUT DOWN");
break;
case WM_RBUTTONDOWN:
AfxMessageBox("R BUT DOWN");
break;
}
return;
}
in trayDlg.h in the Generated Message Map Function section added the line afx_msg void On_WM_TrayIcon(WPARAM wParam, LPARAM lParam);
Compiling result is 0 warnings and errors.
Now whenever I push the button and tray icon is created if I try to place the mouse over it, it dissapears. If I remove the NIF_MESSAGE flag it doesn't dissapear.
Now I've spend 5 hours on this and come to the end of my patience so my deepest thanks goes to the person that helps me a little here.
|
|
|
|
|
Here is the code I use in one of my applications that has a tray icon:
In my header fo MyDlg class I have declared
private:
NOTIFYICONDATA m_notifyIconData;
I have also added the declaration for OnTrayNotification after the MFC stuff
// Generated message map functions
//{{AFX_MSG(CAVCDlg)
virtual BOOL OnInitDialog();
afx_msg void OnSysCommand(UINT nID, LPARAM lParam);
afx_msg void OnDestroy();
afx_msg void OnPaint();
// ... other MFC wizard junk
//}}AFX_MSG
// Our handler for the tray WM_ message
afx_msg LRESULT OnTrayNotification(WPARAM nID, LPARAM lParam);
DECLARE_MESSAGE_MAP()
At the top of my Dlg cpp file I declare a WM_ message
static UINT WM_MY_TRAY_NOTIFICATION = RegisterWindowMessage("MyTrayNotification");
// In my message map I use ON_REGISTERED_MESSAGE to handle
// the WM_MY_TRAY_NOTIFICATION instead of ON_MESSAGE
BEGIN_MESSAGE_MAP(CMyDlg, CDialog)
//{{AFX_MSG_MAP(CAVCDlg)
ON_WM_SYSCOMMAND()
ON_WM_DESTROY()
ON_WM_PAINT()
// ... other wizard junk
//}}AFX_MSG_MAP
// This should be delcared outside the wizard section
ON_REGISTERED_MESSAGE(WM_MY_TRAY_NOTIFICATION,OnTrayNotification)
END_MESSAGE_MAP()
// Link up the tray to the MyDlg in OnInitDlg()
BOOL CMyDlg::OnInitDialog()
{
CDialog::OnInitDialog();
//...
SetIcon(m_hIcon, TRUE); // Set big icon
SetIcon(m_hIcon, FALSE); // Set small icon
m_notifyIconData.cbSize = sizeof(m_notifyIconData);
m_notifyIconData.hWnd = this->m_hWnd;
m_notifyIconData.uID = WM_MY_TRAY_NOTIFICATION;
m_notifyIconData.uFlags = NIF_ICON | NIF_MESSAGE | NIF_TIP;
m_notifyIconData.uCallbackMessage = WM_MY_TRAY_NOTIFICATION;
m_notifyIconData.hIcon = m_hIcon;
lstrcpy( m_notifyIconData.szTip, _T("Hello") );
Shell_NotifyIcon( NIM_ADD, &m_notifyIconData );
return TRUE;
}
// We need to destroy what we created...
void CMyDlg::OnDestroy()
{
m_notifyIconData.uFlags = NIF_ICON;
Shell_NotifyIcon( NIM_DELETE, &m_notifyIconData );
CDialog::OnDestroy();
}
LRESULT CMyDlg::OnTrayNotification( WPARAM uID, LPARAM lEvent )
{
if ( lEvent == WM_LBUTTONDBLCLK )
{
AfxMessageBox("Left Button Double-Click");
}
else if ( lEvent == WM_RBUTTONUP )
{
AfxMessageBox("Right Button Up");
}
return 0;
}
Hope all this rambling on help you some
If you still have questions email me and I will send you this test app zipped up.
Roger Stewart
rstewart27104@yahoo.com
|
|
|
|
|
|
Hi folks,
more or less simple question.
I am using the mfc-odbc api to get information about a database table. Currently I am using SQLDescribeCol(...). But I need more information, because I will dynamically build a new table. This table should consist of columns from other tables. so I need all information to create a new CREATE TABLE sql statement.
e.g. I will need the varchar size or the columns default parameter.
Can anyone help me ? 
many thanx
bye
murphman
|
|
|
|
|
|
|
Use it any place that your would normally use the c style cast operator.
LPARAM lParam
LPCSTR szString = (LPCSTR)lParam;
LPCSTR szString = reinterpret_cast<lpcstr>(lParam);
However, if you can it is alot safer to use static_cast, because the compiler will check to make sure that there are define rules to cast from one type to another.
When you use reinterpret_cast, you are basically saying to the compiler:
SHUT UP, I know what I am doing, it is ok to treat object of type A as a type B object.
|
|
|
|
|
|
syntax for reinterpret_cast:
reinterpret_cast < type-id > ( expression )
example:
CFoo oFoo;
CFoo* poFoo = &oFoo;
CBar* poBar = reinterpret_cast<cbar*>(poFoo);
Caution should be used, because you are bypassing all of the compiler's safeguards against type conflicts, etc.
Sef Tarbell
"A mind all logic is like a knife all blade, it makes the hand bleed that wields it." --Rabindranath Tagore
|
|
|
|
|
syntax for reinterpret_cast:
reinterpret_cast < type-id > ( expression )
example:
CFoo oFoo;
CFoo* poFoo = &oFoo;
CBar* poBar = reinterpret_cast<CBar*>(poFoo);
Caution should be used, because you are bypassing all of the compiler's safeguards against type conflicts, etc.
Sef Tarbell
"A mind all logic is like a knife all blade, it makes the hand bleed that wields it." --Rabindranath Tagore
|
|
|
|
|
I am a fairly new programmer, i have been looking at MFC, and being the young person that I am would like to have a try at the art of game programming. From what i gather games can be made in both OpenGL and DirectX, but i do not know which is the best to use, and where i can learn about the programming techniques.
Could someone tell please inform me.
==================================================
When Your Mind Wonders...Where Does It Go???
|
|
|
|
|
As of DX8 I believe DX is easier and more powerful, a new OpenGL standard is on the way. OpenGl is cross platform though, if that is of any use to you.
I'd start with DX and then learn GL later if you want to, although the nehe site has excellent OpenGL tutorials that are free, so you may chose GL as a matter of economics.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
|
|
|
|
|
OpenGL is available for many platforms where DirectX is Windows only.
Jeremy L. Falcon
"The One Who Said, 'The One Who Said...'"
|
|
|
|
|
Is there anyway to do this ?
Ex.:
I´ve a function
HRESULT blah(BSTR sString, BSTR* sResult)
sString is [in] and sResult is [out, retval]
I need to allocate a new BSTR in the second parameter... maybe subclassing the pointer that sResult has and letting the CComBSTR do the dirty work ? Any guesses ?
Mauricio Ritter - Brazil
Sonorking now: 100.13560 Trank
|
|
|
|
|
|
Hi !
Here is my problem :
I've created and connected a CClntSocket* object (derived from CSocket) in my app.
And I want to use this socket to send & receive data in a modeless dialog box.
How can I "pass" this socket to my modeless dialog box ?
Thanks in advance for any kind of advice !!
Laurent
|
|
|
|
|
Augment the dialog constructor with an additional CCIntSocket * parameter. Depending on what part (the dialog or the code using it) takes responsibility for the cleanup of this CCIntSocket *, you'll delete it in one place or the other.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Thanks ! but it is already done 
In fact, when I "start" the modeless dialog by :
AfxBeginThread( RUNTIME_CLASS(CMyDlgThread) )
there's no way I can pass parameters...
Am I missing something ?
|
|
|
|
|
Ummm... So, you're launching a separate thread to maintain that modeless dialog of yours, right? If so, then you can use the CREATE_SUSPEND flag when creating the thread, pass the socket pointer to some member variable in CMyDlgThread designed to that purpose and then call CWinThread::ResumeThread to start the actual execution of the dialog.
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
