|
Hi,
It's very late here, so I have to be brief: probably you hit the problem with order of constructors called. Your list and list builders are global. There's no way to guarantee that list c'tor will be invoked first. Just put the breakpoints in list constructor to check it out.
Hope it helps and goodnight 
Tomasz Sowinski -- http://www.shooltz.com.pl
|
|
|
|
|
I think its a problem of visibility. Now that you have several declarations of g_List, there's some subtlety of the linkage that isn't tying them to one object. Almost as if there's no defining object, though intuitively I would think there is (the one without the extern).
To test, you might look at the address of the g_List at the points when g_List.AddNode is called. If you get different addrs, I'd say its not a DLL specific problem, but rather falls under the category of storage class specifiers.
-----
#include "just_a_theory_disclaimer.h"
|
|
|
|
|
Hey!
I checked it out. It's the same address all around. So they are pointing
to the same instance of g_List.
Also, it looks like the g_List's contructor only gets called before
DllMain(), even though it AddNode() gets called twice (in cListBuilder
and cListBuilder2). I just find that odd.
What I don't understand is how this method seems to work within an .exe
but not inside a DLL.
Another question would be, is there another way to accomplish this?
The whole goal of this is to have a linkedlist of information that
can be got from a DLL, but the linkedlist can only be built inside
.h files. Almost like building a linkedlist at compile time.
The only place I've seen this done is inside Monolith's Lithtech 3d engine.
They use a similar method to build an array of actor classes that can
be exported from a DLL so that the game client knows about what kind of
objects/enemies it can create. For them, to add a new class to the
array they just create the .cpp and the. h file for the new actor class and
call various macros in the actor's .h file. These macros, from what I've
understood, automatically add the new actor class to this actor "database".
They don't need to modify any other file, or modify any "factory" functions
to able to create an instance of the new actor class. I find their method
to be incredibly elegant, but I just can't totally figure out how they did it.
To find out what I mean, you can download the source code to Shogo in the
"files" section of PlanetShogo.com. Look at any of the actor classes inside
of the "server/objects" workspace, and you'll see what I mean.
Shawn
|
|
|
|
|
The problem is the 'order of construction' problem for global variables.
If the global/static 'cListBuilder1' and 'cListBuilder2' objects are constructed BEFORE the global 'g_list' object, then the calls to 'g_list.AddNode' are most likely failing (because g_list does not yet exist, so you can't add to it). Note that this means you can call a member function of an object that has not yet been constructed!! This is perfectly valid C++ code, but not likely to be what you want. You are probably lucky that you are getting just 'failed function call' - often this behaviour will lead to crashes.
Why would the 'listBuilder' objects be created before 'g_list'? Well, since they are all global objects in different compilation units, the order of construction is undefined - the compiler/linker can schedule the calls to the required constructors in any order they like - as long as all global objects get constructed before the 'main' is called. What makes this kind of problem even worse is that the order of construciton can change simply by adding a new global variable into some file in the project - in this case, the compiler/linker can totaly change the order of global constructions, causing previously "working" code to now fail.
The solution is to use "Create On First Use" semantics for the g_list object. This means you don;t make it a global - you create it the first time it is used (the first call to "AddNode" from a global 'cListBuilder' object constructor, for example. To implement this, put the variable into a function, like this :
cLinkedList& g_List()
{
static cLinkedList theList_;
return theList_;
}
Now, your constructors for the cListBuilder become :
class cListBuilder {
cListBuilder()
{
cData* poData = new CData;
g_list().AddNode("NodeName", poData);
}
};
Since the ListBuilder construtor is now calling a function 'g_list()' rather than a variable 'g_list' you do not have to worry about the order of construction. The rules for static variables inside functions means that the internal 'theList_' object is created only once, and only when the function is called. The function cannot be called without creating the static variable, unlike memeber functions of global variables (which can be called from constructors of other objects before the 'owning' object's constructor!).
I think the reason this was working in an EXE and not the DLL is just blind luck - although, you should note that if all 3 global varaibles are in the same compilation unit (eg, the same cpp file) then the order of construction is normally fixed at the order of the variable declarations (but I'm not sure if the language guarantees this!)
|
|
|
|
|
Aaaah, now I get it. I tried your suggestion and now it works like
a charm (woohoo!) Thanks for the help!
Steve The Plant
|
|
|
|
|
Hello all,
I know that when you export a function from a dll that uses MFC dynamicaly, you have to use the AFX_MANAGE_STATE() macro.
If you export a class from a dll that links to MFC dynamically , do you have to use the AFX_MANAGE_STATE() macro in each member function of the class? If so, what about protected and private functions that won't be called by the client app???
Thanks!
|
|
|
|
|
Hi all,
I'm in the process of writing a Text Viewer application. Notepad does not open large files, and Wordpad opens them but reads them all into RAM and brings the OS to its knees with the swap files, etc.
What I want to do is to open a text file and just read in the portion of the file that should be showing (and some extra for caching, but not terribly urgent right now). Then as the user runs the scroll bar, I would redraw the text that I need to redraw.
A future addition to this program will be for other file types, so I wil have a class to work with Text drawing, and then add other classes as necessary to draw TIFF's or our own file format, etc.
Unfortunately, as I work with this, I keep running into problems with MFC.
I'm working with MS Visual C++ 6.0, SP 4, MFC 6.
Using CScrollView I can print the file, and print preview, but when I try to scroll the file on the screen, it chops off the top, or the bottom, or chops the bottom off lines of text, etc.
Any thoughts about a good way to go about this? Is ScrollView too much of a "helper" if you're not planning on reading the whole file into RAM? Would CView be better? Should I just scrap MFC and write it using the APIs myself?
Any thoughts would be appreciated.
Jeff
|
|
|
|
|
Oops, additional info.
I'm currently working on Windows 98, but any solution would need to work on Windows NT and Windows 2000 as well.
Thanks for any info
Jeff
|
|
|
|
|
Thanks for who that answer me on this question. ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
But I have still problem with it.
my code is so :
-------------------------------------------------------
CFile file;
CFileException ex;
if(!file.open(str_pathName, CFile::modeRead, &ex))
{
//error
}
else
{
//open
}
.
-------------------------------------------------------------------------
when I run it I gets this error:
: error C2039: 'open' : is not a member of 'CFile'
c:\program files\microsoft visual studio\vc98\mfc\include\afx.h(1202) : see declaration of 'CFile'
Error executing cl.exe
-----------------------------------------------------------------------------
------ WHY ???????????????????????
|
|
|
|
|
Is Open, no open, with Capital 'O'
Cheers!!!!
Carlos Antollini.
|
|
|
|
|
detail , please! 
|
|
|
|
|
Incorrect Case:
file.open(str_pathName, CFile::modeRead, &ex)
Should be:
file.Open(str_pathName, CFile::modeRead, &ex)
|
|
|
|
|
thank you very much !!!!!!!!!!!!!!!!!!!!!!! 
|
|
|
|
|
Hi *.*
I have written an MFC application in MS Visual C++6. Now I want to compile it with a different compiler but the one from MS. Is there a way to compile the whole project with borland's c++ compiler?
Are there any other good (or even better) compilers you can recommend?
thanks
|
|
|
|
|
I once used the Borland CPP Builder 4 VC++ Project Conversion Utility on a simple VC6 MDI project just to test. Worked well. My version of Builder has MFC files that corespond to VC5, but that wasn't a big issue for the simple test app.
|
|
|
|
|
I'm looking for some documentation on serial port communication in VC++. Does MFC support it?
- john
|
|
|
|
|
Never mind, I'm a moron. However it wouldn't let me delete my previous message, so I'm just saying I figured it out (and feel stupid)
|
|
|
|
|
Now I really wonder what I missed. Is there a nice class for this?
Eric Hansen
ehansen@pmsi.cc
|
|
|
|
|
Is there a nice class for this?
Look at P.J. Naughter's Serial Port class right here on CodeProject.
|
|
|
|
|
I couldn't find any classes in MFC for Serial Port Comms back when I was looking (about one year ago) so I started to write one...but that project has been on hold for a LONG while now. Unfortunately I'm a bit short on time right now so I'm just going to cut up some of my code send it along, hope it helps (I've never posted code to one of these but I have a feeling this isn't going to be that easy to read ).
Opening a port:
if (portOpen)
{
return portHandle;
}
else
{
// Try to open the comm port
char str[30];
sprintf( str, "\\\\.\\COM%d", portNum );
HANDLE hCom;
DWORD dwError;
hCom = CreateFile( str,
GENERIC_READ | GENERIC_WRITE,
0, // comm devices must be opened w/exclusive-access
NULL, // no security attributes
OPEN_EXISTING, // comm devices must use OPEN_EXISTING
0, // not overlapped I/O
NULL // hTemplate must be NULL for comm devices
);
if (hCom == INVALID_HANDLE_VALUE)
{
dwError = GetLastError();
TRACE0("Invalid Comm Handle in openPort()\n");
// handle error
return NULL;
}
else
{
portOpen = true;
portHandle = hCom;
return hCom;
}
}
Example of writing to and reading a response from a comm port (setting baud rate etc):
DCB dcb;
fSuccess = GetCommState(portHndl, &dcb);
if (!fSuccess)
{
// Handle the error.
}
dcb.BaudRate = 9600;
dcb.ByteSize = 8;
dcb.Parity = NOPARITY;
dcb.StopBits = ONESTOPBIT;
fSuccess = SetCommState(portHndl, &dcb);
if (!fSuccess)
{
// Handle the error.
}
//unsigned char lpData[140] = {1,0,0,16,85,0,1,0,0,0,0,0,0,0,0,103 };
DWORD numActual = 0;
OVERLAPPED osWrite = {0};
BOOL succ;
DWORD error;
succ = WriteFile(portHndl,
sendBuffer, //Data to write to comm port
sendBytes, //number of bytes to write
&numActual, //pointer to number of bytes written
&osWrite // pointer to structure for overlapped I/O
);
if (!succ)
{
error = GetLastError();
TRACE("Bad Comm Write: %d,%d\n",portHndl,error);
}
else
TRACE("Good Comm Write: %d,%d\n",portHndl,error);
succ = ReadFile(portHndl, // handle of file to read
receiveBuffer, // pointer to buffer that receives data
receiveBytes, // number of bytes to read
&numActual, // pointer to number of bytes read
&osWrite // pointer to structure for data
);
if (!succ)
error = GetLastError();
Eric Hansen
ehansen@pmsi.cc
|
|
|
|
|
I have found how to replace the file type combo in the File "Open" dialog with a new one graphically. I want to replace the standard combo box with CComboBoxEx so I can put icons next to the types. But once I do that - how do I communicate to the common dialog when the user selects a new file type? The original file type combo box of the common dialog is still available but invisible. Both combos have the same text. I have tried to programatically set the selection of the original combo to that of the extended combo thinking that that action would cause the appropriate updates but it does not work. Any ideas?
|
|
|
|
|
> I have tried to programatically set the selection of the original combo
> to that of the extended combo thinking that that action would cause
> the appropriate updates but it does not work.
I don't think hidden windows send notifications, so you could try changing the selection and the explicitly sending the CBN_SELCHANGE notification to the dialog using the original combo-box's window handle.
UINT nID = ::GetDlgCtrlID ( hOldCombo );
SendMessage ( WM_COMMAND, MAKELPARAM ( nID, CBN_SELCHANGE ), hOldCombo );
Not sure if this will work, since I've never tried it.
-Ben
"Its funny when you stop doing things not because they’re wrong, but because you might get caught." - Unknown
|
|
|
|
|
Looks like the reply here is for another topic. Anyone with any ideas for the original question? 
|
|
|
|
|
It looks like the response here is for another thread. Getting back to this now and no luck yet. Any responses still greatly appreciated 
|
|
|
|
|
I want to record a sound and play a sound in MFC! How will I do that....
Is there any classes that supports multimedia? I know about the MCI.... but I only have code in Win32 
HELP!!
/*
BETA
*/
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
