|
I don't understand whar you exactly want.
But generally, you can't access the base1_member from Base_Accessor, if Base_Accessor isn't derived from Base1.
Robert-Antonio
"CRAY is the only computer, which runs an endless loop in just 4 hours"
|
|
|
|
|
Note here, that access to base1_member can be enabled for the other class if the other class is declared as a friend of the class containing base1_member.
Friend class, if defined, has a complete access to all member variables and methods inside the class where the declaration is placed. See MSDN Library for many good examples on this.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
If it would be kinf of macro, it is possible to access to any future member,
due to it became like direct write code in derived class,
whem macro will be inserted.
But for template, that is called macro for compiler I can find how to do it.
|
|
|
|
|
If you say, that it's possible via macros, show me a example code, please. So I can exactly know, what is your goal.
Robert-Antonio
"A flower walked around a meadow. She saw a beatiful human and plucked off his head."
|
|
|
|
|
To the class CDialogDerived
lpszTemplateName, m_hDialogTemplate - private member of MFC CDialog
Manual creation of CDialog with custom font:
adding member by macro
# define MACROS \
\
int Create_WithHelper(int IDD, CWnd* pParentWnd, int isModal, int size, CString FontName = "MS Sans Serif")
{
CDialogTemplate dlt;
int nResult;
// load dialog template
if (!dlt.Load(MAKEINTRESOURCE(IDD))) return -1;
// set your own font, for example "Arial", 10 pts.
dlt.SetFont(FontName, size);
// get pointer to the modified dialog template
LPSTR pdata = (LPSTR)GlobalLock(dlt.m_hTemplate);
// let MFC know that you are using your own template
//dlg_T::
//pDialog->
m_lpszTemplateName = NULL;
HINSTANCE hInst = AfxFindResourceHandle(MAKEINTRESOURCE(IDD), RT_DIALOG);
BOOL bResult ;
//pDialog->
m_hDialogTemplate = dlt.m_hTemplate;
if(isModal)
{
nResult =
//pDialog->
DoModal();
}
else
{
bResult =
//pDialog->
CreateIndirect( dlt.m_hTemplate, pParentWnd);
}
GlobalUnlock(dlt.m_hTemplate);
if(m_hWnd == 0 )
ASSERT(0);//for test
//bResult = CreateIndirect(hTemplate, pParentWnd, hInst);
//FreeResource(hTemplate);
return bResult;
};
|
|
|
|
|
vgrigor wrote:
Need access to still undefined member, that will
be defined when template will be actually instatiated.
You have an undefined member in the base class, to which you need access from a derived class ? That sounds completely crazy, are you developing both the base class and the derived class simultaneously ?
If your base class has a pure virtual method, you can always create an object of the derived class, then cast a pointer into the base class, and call the virtual method. It must be defined in the derived class in order for this call to succeed.
In the case of the derived class (Derived, in this case), it derives from both Base1 and Base_Accessor template. The protected member of the base class is not derived, but it exists in the class derivation chain. This means that if you implement handling functions (Get & Set) for the base class, you can then call these functions to manipulate or get a pointer to the base class protected member, and thus modify it.
If this doesn't help, then could you explain in more detail what you mean with 'access to still undefined member'. If a member function/variable is not declared inside the class context, it does not exist, and thus cannot be accessed in any way. This means that you must at least declare all members of classes which you wish to use. This applies to both templates and standard classes.
Also, when posting a reply, and if writing code, please use a <PRE> </PRE> section to isolate the code. Also, use the 'Formatting' commands found above the smileys below the text areas. This allows you to use e.g. the < and > symbols properly, which are of key importance when writing this type of code. This makes your code much more readable and understandable.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
For some template I need some methods be defined.
To define is used other template,
si they work together.
So does in ATL, do you know such a template library?, notI invented this.
They work so.
If member would not private- llosing access right after first inheritance,
all would work?
|
|
|
|
|
There is a round-about way through this, though it breaks the rules of C++ very harshly. You can create two pure virtual methods into the base class for each variable in the derived class. The first variable sets, the second gets, the variable in question. Then implement these methods in the derived class.
Now, your base class member functions can call the virtual functions to return the variables from the derived class, thus having a rudimentary access into the members of the derived class. However, you can no longer declare objects of the base class, as it has pure virtual methods. Only the derived class is available for instantation.
This approach may, or may not work, as I have not tried it myself. I don't know. But following the C++ specification, it should be possible to implement it.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
How does that break C++ rules? That's precisely how virtual functions were designed to be used.  The fact that the abstract base class is a template makes no difference.
--Mike--
Personal stuff:: Ericahist | Homepage
Shareware stuff:: 1ClickPicGrabber | RightClick-Encrypt
CP stuff:: CP SearchBar v2.0.2 | C++ Forum FAQ
----
Four fonts walk into a bar. The bartender says "Hey - get out! We don't want your type in here."
|
|
|
|
|
Virtual functions are primarily, as far as I know, made so that you can create functions in the base class that can be safely overridden in a derived class if necessary. What we are doing here is creating a base class that is specifically meant for a certain derived class.
If you have a set of get/set function pairs in the base class, you can have only a limited type of derived classes, which follow the guidelines set by the base class. This, by itself, can be considered a breach, as C++ inheritance rules (at least in my book) says that inheritance should be available for all types of derived classes, not just specific ones. In our case, the layout of the base class already dictates some functionalities that must be implemented in the derived class in order for the class hiearchy to compile properly.
Here, the base class has a set of functions that can be used to set and change certain derived-class variables. This type of behaviour, as far as I know, is 'illegal', as if it was supposed to be possible to alter derived class variables directly, the inheritance, by itself, should already allow this. The idea of interfaces (pure abstract base class) used with COM technologies follows the same principles as I have outlined here. I am not saying that COM was illegal, though.
I won't start wrestling about this issue any more than that. In conclusion, it could be said that this is a taste issue: some people think it is 'illegal' while some people think it is completely good and well. It all comes down on what you are trying to accomplish, I guess. I, for myself, see no reason on why you should be able to tamper with derived class members from the base class. Perhaps this is because I have never needed this type of functionality 
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
It need to add functionality to many classes,
not by copy/paste,
bu just inheritance from making extension class,
to all needed classes.
But if it depends from MFC for sample, it need to access to MFC
in base - extension class.
|
|
|
|
|
I think, that you can't distinguish between interfaces and abstract base classes. Interfaces are only the extreme case of abstract base classes, where the member variables are forbidden.
If you use you own object model, you should simplify it and permit member variables to abstract base classes. But still there remain the "interface functionality" of the abstract base class, so the set-and-get virtual methods should be useful.
Robert-Antonio
"A piece of paper is an ink-lined plane.
An inclined plane is slope up.
A slow pup is a lazy dog.
Q.E.D.: A piece of paper is a lazy dog."
|
|
|
|
|
Robert A. T. Káldy wrote:
I think, that you can't distinguish between interfaces and abstract base classes
Not so, as I know the difference between these two. Apparently I just didn't explain my ideas clearly enough. An alternative point may be that the original poster is not writing very coherent questions, making it somewhat difficult to guess what he/she is after
The set/get virtual methods can be used. There's nothing wrong there. These methods can be considered an interface into the derived class methods. Just like an interface class is an interface into the derived class's methods, only that in an interface class case, all methods need to be pure virtual, and no member variables are allowed.
I am not going to wrestle about the definition terms, as that would go way off-topic. Let's just say, for peace's sake that I didn't explain myself clearly enough.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
i had read that you written pic grabber,
so can you advise where to get code for optimized download-
able to continue after break, and for multiple
sections loading?
Thanks.
I want to create fast text loader/anylizer.
|
|
|
|
|
|
how to call this method?
I have link error
pDlg->testFunc(p1);
|
|
|
|
|
Hello,
I have an MFC MDI application, that repeatedly displays a message box in the InitInstance() member function, specifically in the MFC calls after the following code is executed:
if (theCommands.m_nShellCommand == CCommLine::FileNew)
{
if (!ProcessShellCommand(theCommands))
return FALSE;
}
The message box says "Failed to Create Empty Document".
The application is using a .ocx control to create a spreadsheet document inside of the CMainFrame. This only happens on one computer. The same computer can run a similar app. with the same activeX control and it will not create this error. I don't understand it.
Can anyone help me?
Here is some useful output
'MVReport.exe': Loaded '\\dan\mvreport\Debug\MVReport.exe', Symbols loaded.
'MVReport.exe': Loaded 'C:\WINDOWS\system32\ntdll.dll', No symbols loaded.
'MVReport.exe': Loaded 'C:\WINDOWS\system32\kernel32.dll', No symbols loaded.
'MVReport.exe': Loaded 'C:\WINDOWS\system32\mfc71d.dll', No symbols loaded.
'MVReport.exe': Loaded 'C:\WINDOWS\system32\msvcr71d.dll', Symbols loaded.
'MVReport.exe': Loaded 'C:\WINDOWS\system32\gdi32.dll', No symbols loaded.
'MVReport.exe': Loaded 'C:\WINDOWS\system32\user32.dll', No symbols loaded.
'MVReport.exe': Loaded 'C:\WINDOWS\system32\advapi32.dll', No symbols loaded.
'MVReport.exe': Loaded 'C:\WINDOWS\system32\rpcrt4.dll', No symbols loaded.
'MVReport.exe': Loaded 'C:\WINDOWS\system32\SHLWAPI.DLL', No symbols loaded.
'MVReport.exe': Loaded 'C:\WINDOWS\system32\msvcrt.dll', No symbols loaded.
'MVReport.exe': Loaded 'C:\WINDOWS\system32\shell32.dll', No symbols loaded.
'MVReport.exe': Loaded 'C:\WINDOWS\system32\comctl32.dll', No symbols loaded.
'MVReport.exe': Loaded 'C:\WINDOWS\system32\ole32.dll', No symbols loaded.
'MVReport.exe': Loaded 'C:\WINDOWS\system32\oleaut32.dll', No symbols loaded.
'MVReport.exe': Loaded 'C:\WINDOWS\system32\ODBC32.dll', No symbols loaded.
'MVReport.exe': Loaded 'C:\WINDOWS\system32\comdlg32.dll', No symbols loaded.
'MVReport.exe': Loaded 'C:\WINDOWS\system32\MFC71ENU.DLL', No symbols loaded.
'MVReport.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.10.0_x-ww_f7fb5805\comctl32.dll', No symbols loaded.
'MVReport.exe': Loaded 'C:\WINDOWS\system32\odbcint.dll', No symbols loaded.
'MVReport.exe': Loaded 'C:\WINDOWS\system32\uxtheme.dll', No symbols loaded.
'MVReport.exe': Loaded 'C:\WINDOWS\system32\msctf.dll', No symbols loaded.
'MVReport.exe': Loaded 'C:\WINDOWS\system32\clbcatq.dll', No symbols loaded.
'MVReport.exe': Loaded 'C:\WINDOWS\system32\comres.dll', No symbols loaded.
'MVReport.exe': Loaded 'C:\WINDOWS\system32\version.dll', No symbols loaded.
CoCreateInstance of OLE control {B0475003-7740-11D1-BDC3-0020AF9F8E6E} failed.
>>> Result code: 0x80040154
>>> Is the control is properly registered?
Warning: could not create view for frame.
Failed to create client pane/view for frame.
Warning: CDocTemplate couldn't create a frame.
'MVReport.exe': Loaded 'C:\WINDOWS\system32\mslbui.dll', No symbols loaded.
'MVReport.exe': Loaded 'C:\Program Files\Logitech\MouseWare\system\LGMOUSHK.DLL', No symbols loaded.
The program '[3480] MVReport.exe: Native' has exited with code 0 (0x0).
-dotBomb
|
|
|
|
|
The OLE control is obviously failing on creation, leading to your other errors. If it works with another
program on the same machine, then you are missing something specific. It may be that the other piece of
software is using a similar ocx, or even an older version.
Are you running AfxOleInit in your CMyApp::InitInstance member function?
Have you looked to see what 0x80040154 means?
Another trick is to use regmon from www.sysinternals.com to see where CoCreateInstance is failing.
You may have a different version (and therefore different GUID) of the ole control on your machines.
etc.
Happy hunting,
Iain.
|
|
|
|
|
Iain,
You were correct. The OLE control was failing on creation, because although it was registered, my application could not find it. It turns out that the path of the .ocx control MUST be in the OS search path in this case, and then re-registered with regsvr32 IN THE NEW PATH.
This was a lesson to me not to drill down into valuable, working code searching for runtime errors not directly caused by that code.
Thank you,
-DK
|
|
|
|
|
Sounds like you've had a frustrating last couple of days.
Mind you, its always nice when the solution in non-obvious.
Less embarassing at least!
Glad you've cracked your problem,
Iain.
|
|
|
|
|
How to change font of Cdialog programmatically ?
I use Create(IDD, CWnd*) function.
thanks.
|
|
|
|
|
Add a CFont member variable to the dialog's declaration. In the dialog's OnInitDialog() method, use:
LOGFONT lf = {0};
lstrcpy(lf.lfFaceName, "Arial");
m_font.CreateFontIndirect(&lf);
SetFont(&m_font);
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
Your method is not work,
also
virtual OnSetFont(Font*) - for settinf font,
not works.
Works:
http://www.codeguru.com/Cpp/W-D/dislog/fonthandling/article.php/c2023
Problem now- how to acces private members of CDialog,
if I want to create reuseable class for CDialogs
for font change ???
|
|
|
|
|
vgrigor wrote:
Your method is not work,
My apologies. The code snippet I provided was from a project in my archives. Those are from many years ago and apparently do not work with newer versions of MFC.
vgrigor wrote:
file:///E:/Doc/www.codeguru.com/dialog/ChangeDefaultDialogFont.shtml
This is a file only accessible by you. From what I could find CodeGuru has no such article.
vgrigor wrote:
how to acces private members of CDialog,
The dialog itself can access all members, regardless of their privilege.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
I changed link. PLease , See above.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
