|
John's answer is the way to go (I guess you already were using MFC serialization, so this is very good news to you.) The DDJ's article Inside MFC Serialization I've just read could be of some help for you (it was for me.)
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
hi,
are-
* Subclassing
* Owner/Custom Draw
* Custom Controls
complementory,some what same,almost same or totally different?
i am confused
|
|
|
|
|
subclassing (when talking about controls) is where you take an existing windows control (like an edit box) and create a new version that does something differently than the original. it's not the same as C++ subclassing (creating derived classes), but the effect is similar. and with MFC it does work out to the same thing in most cases.
owner draw is where the control allows you to handle the rendering while it handles the back-end data work as usual. a common example is an owner-drawn button where you control the rendering of the button, but all the message handling is handled as usual.
a custom control is something you've built from the ground up.
-c
Garbage collection, making life better - for weenies!
|
|
|
|
|
It's probably good to mention one you omitted: superclassing.
A window is created by the OS as a thing with a callback procedure
and some data. The template for creation of this object is called the
windows class. (not related to c++ class. a window class is just
a spec sheet basically.)
Here's the jist:
SUBCLASSING: Have OS create a window from class X. Replace its callback
with your own. Take care of business in your callback and then pass
off to the replaced callback. (You won't be able to intercept creation
messages since that happens before you subclass.)
~ CREATE, REPLACE CALLBACK, HANDLE MSG, RELAY TO OLD
SUPERCLASSING: Register a new window class Y derived from X. This new
class extends an old class. Your callback gets called first even for
creation messages. You can still pass off to the old callback.
~ REGISTER CLASS, CREATE, HANDLE MSG, RELAY TO OLD
OWNER DRAW: Have OS create a window from class X. Set some data in the
window that lets its callback know that you want to handle some drawing.
The windows callback will route a message allowing you do drawing in
you message handling.
~ CREATE, HANDLE OWNER DRAW MSG
CUSTOM CONTROLS: Just an original window class and callback.
~ REGISTER CLASS, CREATE, HANDLE MSG
I'm probably missing some details.
|
|
|
|
|
I have been doing a bit of detective work on this problem, and have found 2 things that puzzle me ( a bit of an understatement).
First of all, the value of hwnd returned to EnumChildProc() always seems to be the value of lparam supplied to EnumChildWindows(). As if that wasn't bizarre enough, I have found that whilst in EnumChildProc() the value reported for 'this' in the variables window of the debugger changes on the four calls !!
As I have just discovered Spy++, I used the WindowFinder tool to establish the handles for all windows within my application. Would you believe that the four values (Caption and Client area for each of the two documents) corresponds to the 4 values of 'this'. (Yes, yes - I KNOW that one is a handle and the other is a constant pointer to the Document - that's what's so bewildering. More than a coincidence, don't you think ??) I believe this a BIG clue to someone who has more more experience than me.
H E L P !!!!!! (This problem is driving me NUTS !!!!)
My current code is as follows :-
(Incidently, I tried moving these 2 routines from the Document into the View, but it gives exactly the same sort of results)
void CIRCDoc::OnTapeMove()
{
// TODO: Add your command handler code here
CMDIFrameWnd *pFrame = (CMDIFrameWnd*)AfxGetApp()->m_pMainWnd;
// HWND hWndParent = pFrame->GetSafeHwnd();
// pFrame->SetWindowText("Hello Mum !!"); // DOES set mainframe title
// BOOL bResult = FALSE;
// LPARAM lParam = (LPARAM)(&bResult);
// BOOL rc = EnumChildWindows(hWndParent, EnumChildProc, lParam);
DWORD param = 0;
LPARAM lParam = 0; //(LPARAM)(¶m);
BOOL rc = EnumChildWindows(pFrame->m_hWndMDIClient, EnumChildProc, lParam);
}
BOOL CALLBACK CIRCDoc::EnumChildProc(HWND hwnd, LPARAM lparam)
{ TCHAR* pSaveText = new TCHAR[20+1];
BOOL rc = GetWindowText(hwnd,pSaveText,20);
DWORD wErrorResult = 0;
if(!rc)
wErrorResult = GetLastError();
delete pSaveText;
return TRUE; // keeps enumeration going
//SendMessage(hwnd,WM_SETTEXT,0,(LPARAM)"Test");
}
Doug
|
|
|
|
|
Apologies !! I accidently posted this as a new thread rather than an addition to my previous thread entitled "Problem with EnumChildWindows" of 25th June (I think ??)
Doug
|
|
|
|
|
Hello there,
I hope someone has a clue how to solve this problem. I want to 'stop' a PCMCIA card (IDE flash card) so that the user can remove it without a message popping up. You can 'stop' the device with the little icon in the taskbar but I want to provide this functionality in my software. Someone must have had this problem before...
An extensive search on MSDN found nothing, maybe it is a Plug-and-Play problem, maybe it is a 'configuration manager' problem, but I found no sample or code.
Thanks for you help in advance.
Josef
Josef Schroettle
|
|
|
|
|
Hi All,
Can anybody help me out in creating a toolbar in a regular DLL. I have two
modules, first the main exe file, and the second is the DLL.
the Main app loads the DLL, and then invokes CreateToolBar(HWND hWnd), and
passed AfxGetApp()->m_pMainWnd->m_hWnd as the handle of the mainframe window...
But the code to create toolbar asserts... so i tried to comment code which
does the docking part. Now the code does not assert but toolbar is not shown.
I even tried to use ShowWindow(SW_SHOW) on it, but no result...
Please any help in this regard would be great...
Thanks in advance,
Mohit
|
|
|
|
|
I take it that the toolbar resource is in the DLL? If it is, make sure that before creating the toolbar that you have switched to the DLL's resources.
Take a look at the AFX_MANAGE_STATE() macro in the MSDN.
Roger Allen
Sonork 100.10016
If I had a quote, it would be a very good one.
|
|
|
|
|
Hi Allen,
Lemme explain a bit more... The CreateToolBar() method is a member of CPlug_In_App class within the DLL... and this method is responsible for creating the toolbar... not the EXE... I had put AFX_MANAGE_STATE(.....) macro in this function.. but in vain... still the code does not asert but toolbar is not shown... i have comented the code for docking the toolbar... is it not possible to dock the toolbar from within the DLL??? i don't think so.. something must be wrong.. here is the code... the OnCmdMsg() calls
createtoolbar() method... is something wrong????
// I am passing AfxGetApp()->m_pMainWnd->m_hWnd... to the DLL which is then casted to (CMainFrame *) ---->>> m_pFrame
// m_pFrame is CMainFrame *
BOOL CPlug_In_1App::OnCmdMsg(UINT nID, int nCode, void* pExtra, AFX_CMDHANDLERINFO* pHandlerInfo)
{
#ifdef DEBUG
TRACE("Called CPlug_In_1App::OnCmdMsg() method\n");
#endif
if (!CreatePlugInToolBar())
{
AfxMessageBox("Could not create PlugIn_1's toolbar");
}
// TODO: Add your specialized code here and/or call the base class
return CWinApp::OnCmdMsg(nID, nCode, pExtra, pHandlerInfo);
}
bool CPlug_In_1App::CreatePlugInToolBar()
{
AFX_MANAGE_STATE(AfxGetStaticModuleState());
if (!m_bIsToolBarCreated)
{
if (!m_wndPlugInToolBar.CreateEx(m_pFrame, TBSTYLE_FLAT, WS_CHILD | WS_VISIBLE | CBRS_TOP | CBRS_SIZE_DYNAMIC) ||
!m_wndPlugInToolBar.LoadToolBar(IDR_PLUGIN_1))
{
#ifdef DEBUG
TRACE0("Failed to create toolbar\n");
#endif
return false; // fail to create
}
// TODO: Delete these three lines if you don't want the toolbar to be dockable
m_wndPlugInToolBar.SetOwner(m_pFrame);
// m_wndPlugInToolBar.EnableDocking(CBRS_ALIGN_ANY);
// EnableDocking(CBRS_ALIGN_ANY);
// m_pFrame->DockControlBar(&m_wndPlugInToolBar);
m_wndPlugInToolBar.ShowWindow(SW_SHOW);
m_bIsToolBarCreated = TRUE;
}
return true;
}
Thanks in advance...
-Mohit
|
|
|
|
|
I tackled this problem in one of my own apps. Here is the code I had to load the toolbars from the main program and dock them. Note that you may need to call ShowControlBar() to cause the toolbar(s) to be displayed the first time you run your code.
CToolBar **m_pTB ;
int m_ToolbarCount ;
void CMainFrame::LoadDLLToolbars()
{
CToolBar *last = &m_wndMainToolBar ;
int count = 0 ;
for (int DLL_index = 0 ; DLL_index < refineDLLs ; DLL_index++)
{
if (refineDLL[DLL_index].DLLGetToolbarCount != 0 && refineDLL[DLL_index].DLLGetToolbar != NULL)
{
count += refineDLL[DLL_index].DLLGetToolbarCount() ;
}
}
if (count > 0)
{
m_pTB = new CToolBar*[count] ;
m_DLLIndexes = new int[count] ;
}
int index = 0 ;
for (DLL_index = 0 ; DLL_index < refineDLLs ; DLL_index++)
{
if (refineDLL[DLL_index].DLLGetToolbarCount != 0 && refineDLL[DLL_index].DLLGetToolbar != NULL)
{
for (int i = 0 ; i < refineDLL[DLL_index].DLLGetToolbarCount() ; i++)
{
m_pTB[index] = refineDLL[DLL_index].DLLGetToolbar(i, this) ;
DockControlBar(m_pTB[index]) ;
last = m_pTB[index] ;
m_DLLIndexes[index] = DLL_index ;
index++ ;
}
}
}
m_ToolbarCount = count ;
}
CMainFrame::~CMainFrame()
{
for (int i = 0 ; i < m_ToolbarCount ; i++)
delete m_pTB[i] ;
delete []m_pTB ;
delete []m_DLLIndexes ;
}
int DLLGetToolbarCount()
{
return 1 ;
}
CToolBar* DLLGetToolbar(int index, CWnd *pMP)
{
if (index != 0)
return NULL ;
HINSTANCE hInstance = AfxGetResourceHandle();
AfxSetResourceHandle(theApp.m_hInstance);
CToolBar *pTB = new CToolBar ;
if (!pTB->CreateEx(pMP, TBSTYLE_FLAT, WS_CHILD | CBRS_ALIGN_TOP, CRect(0, 0, 0, 0), IDR_TRAYTOOLBAR) ||
!pTB->LoadToolBar(IDR_TRAYTOOLBAR))
{
TRACE0("Failed to create toolbar\n");
AfxSetResourceHandle(hInstance);
return NULL ;
}
pTB->SetBarStyle(pTB->GetBarStyle() | CBRS_BORDER_3D) ;
pTB->EnableDocking(CBRS_ALIGN_ANY);
pTB->SetWindowText("TraySetup & Communication");
pTB->EnableToolTips(TRUE) ;
g_pTraySetupToolbar = pTB ;
AfxSetResourceHandle(hInstance);
return pTB ;
}
Hope it helps.
Roger Allen
Sonork 100.10016
If I had a quote, it would be a very good one.
|
|
|
|
|
Hi Allen,
I tried it, but now it asserts at CDockContext::CDockContext()...
ASSERT(pBar->m_pDockSite != NULL);
The docksite for my toolbar is NULL....
This code is called by the EnableDocking Method()....
There is really something wrong... Is it valid to pass AfxGetApp()->m_pMainWnd->m_hWnd to DLL's fucntion... and then convert it into (CWnd *) and then use it as the mainframe???
Please help in this...
Now my code is...
bool CPlug_In_1App::CreatePlugInToolBar()
{
AFX_MANAGE_STATE(AfxGetStaticModuleState());
HINSTANCE hInstance = AfxGetResourceHandle();
// set resource handle to ourselves (the DLL)
AfxSetResourceHandle(theApp.m_hInstance);
if (!m_wndPlugInToolBar.CreateEx(m_pFrame, TBSTYLE_FLAT, WS_CHILD|CBRS_ALIGN_TOP, CRect(0, 0, 0, 0), IDR_PLUGIN_1)
|| !m_wndPlugInToolBar.LoadToolBar(IDR_PLUGIN_1))
{
TRACE0("Failed to create toolbar\n");
// reset resource handle
AfxSetResourceHandle(hInstance);
return NULL;
// fail to create
}
//lose garnage pixels
m_wndPlugInToolBar.SetBarStyle(m_wndPlugInToolBar.GetBarStyle()|CBRS_BORDER_3D);
m_wndPlugInToolBar.EnableDocking(CBRS_ALIGN_ANY);
m_wndPlugInToolBar.SetWindowText("TraySetup & Communication");
m_wndPlugInToolBar.EnableToolTips(TRUE);
// reset resource handle
AfxSetResourceHandle(hInstance);
retrun true
}
-Mohit
|
|
|
|
|
3 possible things:
1. Check out your registry entries for LoadBarState()/SaveBarState(). You can have problems if your trying to load a state that is invalid for the new configuration of toolbars. Just delete all the toolbar position registry entries.
2. Are you using MFC in a DLL for both the DLL and EXE projects?
3. In my code I new the CToolbar object and return a pointer to it. In yours its part of the DLL app object. Their could be a problem accessing this memory from the exe file. Create the object on the heap and return a pointer to it.
HTH
Roger Allen
Sonork 100.10016
If I had a quote, it would be a very good one.
|
|
|
|
|
Hi Roger,
I am not saving Barstate in the registry...
Yes, i am using MFC for both DLL and EXE... is this creating probs???
and the third point you mentioned... might be the problem.. is it possible that this would create probs.... Since one thing i want to know...
In one other method.. i had created a button (appened a button) to the default toolbar) from the DLL... here also i did from DLL.. the button shows and works without probs...
But stillif this prob is not solved this way, then ithink i would be changing the code referring your code... creating a pointer and return it...
One more thing... so if your method works out, then do I assume that all of the Plug-Ins written for various apps like MS Office, Winamp, VS 7.0, etc do it this way... (i mean, that their main app takes care of calling CreateToolBar() method???)
I would be now trying your way, and would let you know of any probs...
Thanks a lot for your valuable time,
Regards,
Mohit
|
|
|
|
|
I want to access remote database(SQL Server) on a different Lan.I am working on ATL.How do I do it??
|
|
|
|
|
Read some documentation on ODBC and ADO. Look under Data Services in MSDN.
Michel
It is a lovely language, but it takes a very long time to say anything in it, because we do not say anything in it, unless it is worth taking a very long time to say, and to listen to.
- TreeBeard
|
|
|
|
|
And how the heck do you expect us to answer that when you don't say what DB API you're using (or even what you'd like to use)? With the information you have given so far I'd say you should go with Firebird.
|
|
|
|
|
Is the debugger in VC++ always indicating mem leaks, or is it necessary to change the settings ?
~RaGE();
|
|
|
|
|
VC++ debugger does not indicate the memory leaks.
You can use CRT libary programatically to check the memory leaks, but this is of not great help compred to third party tools like BoundsChecker, etc.
Thanks,
Ramy
|
|
|
|
|
Ramu Pulipati wrote:
VC++ debugger does not indicate the memory leaks.
Hem .. actually it does ... what I want is (surprisingly) not to know _where_ are memory leaks, but to know if _there are_ memory leaks ...
To be a little bit more clear, I have developped an API. In a test program for this API, I do not have any mem leaks detected by the debugger. But when I use some functions from this API into a more consequent mem leaks free application, then I get the memory leaks. So i suppose this __must_ be the API, and hence I´ve concluded that in the big application, project settings must have changed so that it indicates mem leaks . Is that clear or are you already (BTW is that a new emoticon ? Never saw it before ??)?
~RaGE();
|
|
|
|
|
Yes, it's a new emoticon. VC *tries* to detect memory leaks, third party products do it better.
Christian
I am completely intolerant of stupidity. Stupidity is, of course, anything that doesn't conform to my way of thinking. - Jamie Hale - 29/05/2002
Half the reason people switch away from VB is to find out what actually goes on.. and then like me they find out that they weren't quite as good as they thought - they've been nannied. - Alex, 13 June 2002
|
|
|
|
|
VC detects mem leaks by use of redirecting new and delete functions.
When u'r using API calls for allocation and such, VC debugger can't see that.
For these leaks use boundschecker and such..
|
|
|
|
|
OK. Thanx to all of you.
~RaGE();
|
|
|
|
|
I suspected that I had a memory leak or handle leak of some sort and have spent ages trying to find it. The other day I found a free 30 day demo for an app called GlowCode. It was really easy to use, you don't change your code, just attach it to your app while its running.
Anyway I found my problem in a couple of hours . I thought you might be interested, here's the link ....
http://www.glowcode.com/
Ali
|
|
|
|
|
Ouahh that app is great !
Thank you very much !!!!
~RaGE();
|
|
|
|
|