|
|
I have 4 DLLs as following:
CFiles.dll
CExceptions.dll
CXML.Dll
CDataFormat.dll
CExceptions contains an Object factory that follows the Loki Object Factory model as following:
It has a map containing function pointers with enteries such as following:
void CExceptionFactory::InitializeMap()
{
AddToMethodMap(CExceptionFactory::DATABASE_EXCEPTIONS, CreateDatabaseExceptions);
AddToMethodMap(CExceptionFactory::NULL_POINTER_EXCEPTIONS, CreateNullPointerExceptions);
AddToMethodMap(CExceptionFactory::READER_EXCEPTIONS, CreateReadExceptions);
}
Now, within the DataFormat DLL, depending on the type of formatting, I load different DLLs. For instance, if the type is XML, I load the XML dll as following:
case ID_XML:
{
//m_pDataFormat = new XML();
HMODULE hLibrary = 0;
DataFormatProc pfnDataFormat = 0;
GEA pfnGEA = 0;
hLibrary = ::LoadLibrary("CXML.dll");
if(hLibrary != 0)
{
DWORD dw = 0;
pfnDataFormat = (DataFormatProc) GetProcAddress (hLibrary, "CreateXMLSingletonInstance");
dw = GetLastError();
if(pfnDataFormat != 0)
m_pDataFormat = pfnDataFormat();
m_pDataFormat->LoadFile(L"Stocks.xml");
::FreeLibrary(hLibrary);
}
Now if the method LoadFile above fails, it throws an exception by calling CExcpetionFactory class above and CExceptionFactory will try to look inside its Loki map and retrieve the required method as shown below:
CExceptionFactory::CExceptionFactory(int nTypeID, const string & strMessage)
{
InitializeMap();
CreateObject(nTypeID);
if(m_pException != 0)
{
m_pException->Log(strMessage);
delete m_pException;
}
else
{
throw CExceptionFactory(CExceptionFactory::NULL_POINTER_EXCEPTIONS,"Unknown Exception.");
}
}
void CExceptionFactory::CreateObject(int nTypeID)
{
CallbackMap::const_iterator i = m_Callbacks.find(nTypeID);
if( i != m_Callbacks.end())
{
m_pException = (i->second)();
}
else
m_pException = 0;
}
Now, as soon as the code hits (i->second)(); , it leaves the exception dll all together and goes back to the beginning of that case statement above.
I am quite puzzled with this behaviour.
I am guessing I have a function pointer to begin with the loaded DLL and then I am getting a second function pointer and the compiler gets confused, but why should it?
Your help would be highly appreciated.
thanks
|
|
|
|
|
Well it sounds like you have corrupted your stack. Then you can end up any where in your code when calling function.
Magnus
|
|
|
|
|
how do i get WM_KEYDOWN for controls like a CEdit or a CComboBox (not for the window..)? In VC++ i can only use some events like a OnChange() and others.. but can i intercept other messages too?
Thanks,
Bye
|
|
|
|
|
Yes, but you need to subclass the control you're interested in. Derive your own class from CEdit (or other class as appropriate). If you're creating the control yourself using the Create() member function, use your class in place of CEdit.
If you're interested in a control that's on, for example, a dialog (or another control that's created by some piece of code you can't modify), create an object of your class with a lifetime at least as long as the control, then call SubclassWindow() on the object, passing the window handle of the control you're interested in.
Typically, if the control is on a dialog, you'll create the object that manages the control as a member variable of the dialog's class.
Alternatively using DDX_Control() in a DoDataExchange() function works well.
The change event (EN_CHANGE, a WM_COMMAND message) is actually sent by the edit control during its processing of the message that caused the control's contents to change.
--
Mike Dimmick
|
|
|
|
|
and how do i add a event handler? or do i have to write a different class for every edit control?
|
|
|
|
|
Derive your control from CEdit into CMyEdit. Replace occurences of CEdit in the Message Mapping for CMyEdit. Then, all "usual" CEdit event handlers will be available, plus the "usual" window message handler.
~RaGE();
|
|
|
|
|
To decouple things a bit, you could have your subclassed edit control send a message back to its parent window, perhaps something in the WM_APP range (e.g. WM_APP + 1).
In the parent window class, you would then handle your WM_APP message using an ON_MESSAGE() entry in the message map. See MFC Technical Note 6[^] for more information about ON_MESSAGE.
To handle a custom message, your function should be prototyped as LRESULT OnMyMessage(WPARAM wParam, LPARAM lParam).
As an alternative, you could do what the edit control normally does and send a WM_COMMAND message with a code you define (that doesn't clash with the normal edit control notification codes), the ID of your control (which you can get with GetDlgCtrlID) and the window handle of the control (m_hWnd). This does run the risk of potentially clashing with a Windows-defined message code in a future version of Windows. The existing codes are defined in WINUSER.H. If you go this way, handle the message with ON_CONTROL().
--
Mike Dimmick
|
|
|
|
|
thank you very much!
I'll try and see what i can do.
|
|
|
|
|
if i have file name, is there any function that can give me the path or diretory where the file is saved?
for example, filename = notepad.exe
then path = c:\window
thank you
|
|
|
|
|
One solution is FindFirstFile() and FindNextFile().
Kuphryn
|
|
|
|
|
Use AssocQueryString(ASSOCF_OPEN_BYEXENAME,ASSOCSTR_EXECUTABLE,...). For this to be included in your IDE you might need to download the latest SDK from MS.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
pnpfriend wrote:
for example, filename = notepad.exe
then path = c:\window
Unless I've moved Notepad.exe to c:\some\path\way\down\deep\in\windows
You'll need to use kuphryn's suggestion.
|
|
|
|
|
I'm writting an application that does several processing steps on a file, like encription, compression, checksum calculation, etc, and writes the result to another file. And this is to be done with lots of files of different sizes.
I'ld like to know if, in terms of performance, it would be better to use the CRT, the Win32 API for File I/O or the Win32API for File Mapping or another that I'm not aware .
Also I'ld like to know if using concurrent threads to write several files to disk at the same time would be a good option or would it cause havoc in the file system.
Thank you
Artur Jales Moreira
|
|
|
|
|
MC crt usually uses Win32 APIs anyway.
File mapping is useful because you work with memory and write to the file once.
If you can divide your application tasks to write several files at once, it is a great idea( it is probably one of the most efficient use of MT).
|
|
|
|
|
Win32 API would be the fastest because all the other methods use Win32 API but as I say that it does not make a lot of difference because the hard drive is much slower than memory or the CPU so a few more cpu instructions will not make a difference when the CPU executes billions of instructions a second.
jales wrote:
Also I'ld like to know if using concurrent threads to write several files to disk at the same time would be a good option or would it cause havoc in the file system.
If the OS did not cache the data this would be very bad for performance because this will cause the disk to thrash, however with cache some of this will be masked by the system. I do not recommend this however.
John
|
|
|
|
|
jales wrote:
I'ld like to know if using concurrent threads to write several files to disk at the same time would be a good option or would it cause havoc in the file system
Definitely : do not do that.
~RaGE();
|
|
|
|
|
And why not? There is no problem having several threads writing to different files the same time.
What will be a problem is having several threads writing to the SAME file at the same time.
Magnus
|
|
|
|
|
Won't that add to disk and disk cache fragmentation? My principal concern is speed, but I don't want to have to use defrag in the end 
Thank you
Artur Jales Moreira
|
|
|
|
|
If you add small chunks to the file and either closes the file or empty the cache and then adds more data and repeat. Then you will have fragmentation.
If you really is concerned you can always reserve a filesize, but I dont think it will be necessary if you have NTFS. And the windows file cache will also minimize the number of writes that actually goes to the HD.
Magnus
|
|
|
|
|
Magnus is correct. There's nothing wrong with multiple threads writing to multiple files at the same time.
Multiple threads writing to the same file is a really bad idea. It will work if you do it properly, but really, really, really, dangerous.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
I'm working on a project which is Single Document-MFC.
I'm learning database(ODBC) programing with visual c++ 6.0.
I want enter a numaric value into an EditBox.
Then this value should be stored in *.mdb table as long integer.
I chose catagory as value and variable type long from class wizard.
But I could not write any code for it.
please,help me !
|
|
|
|
|
Add a handler for IDOK using the class wizard. In your OnOk() member function add code to store your long value to the database using ODBC. I believe you have to add your code after the call to the base class.
John
|
|
|
|
|
Well, im not sure its refered to as dynamic text, but here's what i want to do.
Suppose i have a word in a text file. I input that word into a string, call it str_word. What i'd like to do is display that word in my dialog box. Just like i would a static test, but instead of creating the static text before runtime, it outputs the str_word.
ie, in a console application, i'd do something like...
cout << "You are now editing " << str_word << endl;
thats essentially what i'd like to do, but this is in a MFC dialog box, not in an edit control, listbox or anything, its just like static text.
*.*
|
|
|
|
|
Add a static text to your dialog (put anything you want in it, you can put an empty string) and rename it to another ID (say IDC_MYTEXT). Be sure the static text window is long enough to contain all the desired text.
Then read your string and use this:
GetDlgItem(IDC_MYTEXT)->SetWindowText(str_word);
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
