|
You have to export it all because the fact that your exported class derives from another one affects the object layout: the client must know the details of base classes in order to be able to handle this.
A possible solution is to resort to C++ classic ways to provide data encapsulation: Define the member functions of interest to the client as virtual in an abstract class and do not export your class, but rather a function that returns a pointer to it (through the abstract class interface). I guess this could not be feasible in your case, as MFC is often too rigid to allow this kind of technique to be applied.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
So this means that if I have tons of classes and inherited classes, they will all need to be exported in the DLL.
It seems you would need to rebuild the client everytime the DLL changes (add function to a class). But I know this is one advantage of the DLL is that it doesn't. Under what circumstance would you not need to recompile the client and can continue to use an updated DLL?
Last question. Am I correct to say that the classes in the DLL can only use the resources declared in the DLL?
THanks.
|
|
|
|
|
So this means that if I have tons of classes and inherited classes, they will all need to be exported in the DLL.
Alas, yes. Unless you apply some data hiding technique like the one I described earlier or some sort of the so called pimpl idiom.
It seems you would need to rebuild the client everytime the DLL changes (add function to a class). But I know this is one advantage of the DLL is that it doesn't. Under what circumstance would you not need to recompile the client and can continue to use an updated DLL?
In a strict sense, client recompilation is needed everytime an exported class changes. However, you can (more o less safely) avoid client recompilation when you add static or non-static, non-virtual member functions to a class. As for message handlers, my hunch is that adding new handlers does ot require client recompilation.
Last question. Am I correct to say that the classes in the DLL can only use the resources declared in the DLL?
No. You're entering dangerous territory here, but in general MFC Extension DLLs do need to explicitly state that they're using their own resources with AFX_MANAGE_STATE. This implies that if AFX_MANAGE_STATE is not invoked, resources from the client .EXE will be used instead.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
You can manage the export of the dll functions (classes I dont know) via number (def-file). Then must must not recompile because the interface of the dll is fixed.
Resources is a tricky field. The other response is correct. But you can also load resources directly. You must than use the handles and work with FindResource (MSDN) etc.
Another way coud be that you load the resources somewhere and give the handles (!!!) or copies of them to the dll to work with.
I think if you need resources in the dll, they have to be coded in it.
|
|
|
|
|
I was trying something else and now things seems to get more convoluted. In this one class I want to export, it has many classes that it uses and thus is declared in the header file of the exported classes. From the previous responses, it seems that I have to then exported everything. It almost seems like I have to export every class I have in the DLL.
In one of these classes, I create a non-modal dialog in the one of my classes. Now, I had to export this as well. But then it also came up with that the IDD = IDC_TEST is a undeclared identifier. At this point, I had to take a step back. It seems like it is getting more and more complicated and that the reason to use a DLL is gone.
Anything else I can do?
Thanks.
|
|
|
|
|
Hello, I'm trying tho inherit from a PropertySheet and from a property page...
INTRODUCTION:
I'm trying to be able to resize all the property sheets that need to be resized and in order to avoid all the work for each property sheet and property page, I've decided to inherit from one Property sheet/page that has that function implemented.
PROPERTY SHEET INHERITHANCE FOLOWED STEPS:
In order to inherit from the property sheet I've followed those steps:
1. create the new PopertySheet class.
2. add the member variables, functions and methods.
3. include the header of the class that have all those new methods... into the header file of one of my property sheets.
4. inherit from that new class (see below):
<br />
class CPSEstacio : public CPSAutoRedimensionable
5. change the contructors:
<br />
CPSEstacio::CPSEstacio(UINT nIDCaption, CWnd* pParentWnd, UINT iSelectPage)<br />
:CPSAutoRedimensionable(nIDCaption, pParentWnd, iSelectPage) <br />
RELATED QUESTIONS:
- Why do I need to change the contructors...
- Are these the right steps?
-----------------------------------------------------------------------------
In the property pages I don't understand how to do it:
what happens to the dialog resource that's asked in the creation of the new class?
In VC++6 when you make a new class that's a CPropertyPage, you must tell which dialog resource will it use...
If I don't know which I will use, what do I have to type there?
-----------------------------------------------------------------------------
As always thank you very much...
|
|
|
|
|
Joan Murt wrote:
RELATED QUESTIONS:
- Why do I need to change the contructors...
You want to call the base class constructor at the construction of the page. This way, every class in the hierarchy gets its turn to look at the parameters involved. Only Heaven (and maybe the programmer) knows what information it needs from the parameters, but fact is that CPSAutoRedimensionable in turn will have to call the ctor of CPropertySheet with these parameters.
Joan Murt wrote:
what happens to the dialog resource that's asked in the creation of the new class?
EveryPage has something like
enum { IDD = IDD_PROPPAGE_ASSAY };
in its header file. In the code file IID is handed over to the CPropertyPage ctor, which in turn loads the resource.
Joan Murt wrote:
In VC++6 when you make a new class that's a CPropertyPage, you must tell which dialog resource will it use...
If I don't know which I will use, what do I have to type there?
Normaly, I work the other way round: I create a page with the resource editor and after it looks like my design, I let the code wizard produce a class for it. The resource can be freely modified afterwards, but the connection to the class remains (via the resource name in the enum-statment above).
|
|
|
|
|
Hi Joan,
Steps 4 and 5 are right, but do not suffice: additionally, you've got to replace CPropertySheet with CPSAutoRedimensionable everywhere where CPropertySheet appears, notably in BEGIN_MESSAGE_MAP.
As for why you should change the ctors, it's basic inheritance stuff: a derived class is responsible to call ctors of its base class(es) (except if the default ctor applies); as you've changed the base class, this has to be propagated to the ctors as well.
what happens to the dialog resource that's asked in the creation of the new class?
Property pages are nothing but special dialogs embedded into a property sheet. As dialogs, they must be attached to a dialog resource. If this is not very clear to you, look for some tutorial on property sheets.
Also, I'd like to recommend you Erwin Tratar's Layout Manager for Dialogs, Formviews, DialogBars and PropertyPages
[^], which turns managing resizing into a child's play.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I've created a project and link is statically with MFC. (I always prefer to link statically with MFC so that i can easily survive from distributon problems).
Well, now i want to make few enhancements in this project. For this purpose i've reated an "Extension DLL". But what documented is that Extension Dlls must be linked dynamically with MFC. Suppose i use this dll in my project that is already linked statically with MFC, then do i need to distribute MFC dlls with this project ???
|
|
|
|
|
MFC Extension DLL is an add-on for MFC DLL, it requires it by design. You need to distribute the MFC DLL with your extension DLL. Also it's not good practice to use statically linkëd app with the extension DLL - you should link your main app with MFC dynamically if you are using MFC extension DLLs.
Pavel
Sonork 100.15206
|
|
|
|
|
Not if you still have MFC statically linked.
Also, it is possible to convert DLLs to LIBs (can't remember the name of the tool offhand) which can simplify matters even though it meants the .EXE file gets larger.
Elaine
Would you like to meet my teddy bear ?
|
|
|
|
|
According to MSDN:
Because the new block can be in a new memory location, the pointer returned by realloc is not guaranteed to be the pointer passed through the memblock argument.
Does this mean I have to manually delete the previous pointer or will this stomp on the memory just allocated...?
I'm thinking freeing the previous pointer would cause serious problems...but i'm unsure...
Could you fill me in please...?
Thanx! 
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
You have truncated the text where it says the buffer is potentially reallocated, which means a balance free.
Now you have the CRT code, in realloc.c, it executes this :
if ( (retp = _malloc_base(newsize)) != NULL ) {
memcpy(retp, pblock, oldsize);
_free_base_lk(pblock);
}
Which is the answer to your question.
There is also another way of seeing whether the previously allocated block has been freed or not : the dummy characters. In DEBUG mode, your block will be filled with either of these :
<br />
char _bNoMansLandFill = 0xFD; <br />
char _bDeadLandFill = 0xDD; <br />
char _bCleanLandFill = 0xCD; <br />
In your case, that's DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD.
How low can you go ?
(MS rant)
|
|
|
|
|
So in laymen terms, thats a NO...i don't have to free the previous pointer...? 
Cheers!
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
Exactly.
I wanted to have a neat post about that, so to reference it whenever someone ask the same question. That said, I am pretty sure next time I'll have to rewrite the whole sh*t again.
How low can you go ?
(MS rant)
|
|
|
|
|
I use Spy++ "window Search" dialog. I drag and drop mouse pointer over target window. In result Spy++ shown me the handle of window, caption and class name.
Suppose I got class name like "sysListView32". Now i want to know that which system dll is exporting this class. How can i find that ??
|
|
|
|
|
Well Spy++ won't help you there. I think your best shot is to check MSDN - I think in this case it's commctrl32.dll (not sure about the spelling though )
Wenn ist das Nunstück git und Slotermeyer? Ja! Beierhund das oder die Flipperwaldt gersput!
|
|
|
|
|
Class shown in Spy++ is result of RegisterClassEx call made when window is created. This is not class exported from Dll.
|
|
|
|
|
Hi, This is a problem about DLL and EXE. The DLL was past debugging and made a *.dll and *.lib. Everything is wrong in Exe.
In DLL:
First, I made a class named CDecoder.
Inside it I declare member m_FormatTable
CFormatTable m_FormatTable;
I followed wizard to make a class CFormatTable which wrapped a table named "Format" in my database.
CDecoder's member function Initialize() use CFormatTable to load necessary data from the database.
In Exe,
I wrote:
CDecoder Decoder;
Decoder.Initialize();
and got the following:
------------------Configuration: HydroExe - Win32 Debug--------------------
Linking...
Creating library Debug/HydroExe.lib and object Debug/HydroExe.exp
Decoder.obj : error LNK2001: unresolved external symbol "public: __thiscall CFormatTable::CFormatTable(class CDatabase *)" (??0CFormatTable@@QAE@PAVCDatabase@@@Z)
Debug/HydroExe.exe : fatal error LNK1120: 1 unresolved externals
Error executing link.exe.
HydroExe.exe - 2 error(s), 0 warning(s) What's wrong?
Extreme programming. Do the No.1
|
|
|
|
|
Did you export the class CFormatTable from the DLL ?
Check out
|
|
|
|
|
Link did not show up
http://www.codeproject.com/dll/dllexport.asp
|
|
|
|
|
I am getting a wierd error and I think it is because something may be declared wrong, I guess I am just not sure where:  Any clues?
Inside header file:
friend ostream &operator << (ostream &, ListNode &);
Inside .cpp file:
ostream &operator << (ostream &strm, ListNode& *Node)
{
while(Node != NULL)
{
...
}
return strm;
}
Errors:
<br />
--------------------Configuration: records - Win32 Debug--------------------<br />
Compiling...<br />
records.cpp<br />
C:\Documents and Settings\User\Desktop\cs208\hw6\records.cpp(101) : error C2061: syntax error : identifier 'ListNode'<br />
C:\Documents and Settings\User\Desktop\cs208\hw6\records.cpp(102) : error C2805: binary 'operator <<' has too few parameters<br />
C:\Documents and Settings\User\Desktop\cs208\hw6\records.cpp(104) : error C2065: 'Node' : undeclared identifier<br />
Error executing cl.exe.<br />
<br />
records.obj - 3 error(s), 0 warning(s)<br />
Nick Parker
May your glass be ever full.
May the roof over your head be always strong.
And may you be in heaven half an hour before the devil knows you’re dead. - Irish Blessing
|
|
|
|
|
 It seems like the compiler doesn't recognize the ListNode type. Make sure that you have included the header file that contains the declaration for ListNode.
- Anatari
|
|
|
|
|
Anatari wrote:
Make sure that you have included the header file that contains the declaration for ListNode
This is in the same file that the implementation of the list exists.
Nick Parker
May your glass be ever full.
May the roof over your head be always strong.
And may you be in heaven half an hour before the devil knows you’re dead. - Irish Blessing
|
|
|
|
|
in the line:
<br />
ostream &operator << (ostream &strm, ListNode& *Node)<br />
are sure you didn't mean to write:
<br />
ostream &operator << (ostream &strm, ListNode& Node)<br />
Just trying to help even if i'm way off =)
- Anatari
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
