|
You can export the class from the project that implements the class:
class __declspec(dllexport) test
{
public:
static void StaticMemberFunction();
};
void test::StaticMemberFunction()
{
}
Then on the consumer side, import the class:
class __declspec(dllimport) test
{
public:
static void StaticMemberFunction();
};
...
test::StaticMemberFunction();
Note that it's nicer to use a macro that expands to __declspec(dllexport)
or __declspec(dllimport) depending on the definition of a build-type macro:
#if defined(BUILDINGDLL)
#define MYIMPORTEXPORT __declspec(dllexport)
#else
#define MYIMPORTEXPORT __declspec(dllimport)
#endif
Then both sides can share the same header file for the class, making
maintainability easier (if the class changes you don't have to remember
to change it in two places):
class MYIMPORTEXPORT test
{
public:
static void StaticMemberFunction();
};
*EDIT* I forgot to mention - you'll need to add the import library<br />
for the implementing module to the importing project's linker input settings.
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
modified on Saturday, September 20, 2008 4:33 PM
|
|
|
|
|
Thanks for the comprehensive answer Mark. Really appreciate it 
|
|
|
|
|
|
My directory structure is
Dir1
|---------file.exe
|---------angle.txt
|---------test.txt
|---------Dir2
|________Dir3
My code works like it just find the .txt files under Dir1, never find files under Dir2, Dir3 etc. Please tell me what's wrong with my code.
void CWinSearchDlg::SearchInternal(LPCTSTR path, CStdioFile *file)
{
CFileFind finder;
TCHAR szWildcard[MAX_PATH] = {0};
_sntprintf(szWildcard, MAX_PATH, _T("%s"), path);
PathAppend(szWildcard, _T("*.txt"));
BOOL bWorking = finder.FindFile(szWildcard);
while (bWorking)
{
bWorking = finder.FindNextFile();
if (finder.IsDots())
continue;
if (finder.IsDirectory())
{
SearchInternal(finder.GetFilePath(), file);
}
}
finder.Close();
}
modified on Saturday, September 20, 2008 9:51 PM
|
|
|
|
|
OF course except CfileFind you can use of FindFirstFile/FindNextFile.
|
|
|
|
|
fantasy1215 wrote: Please tell me what's wrong with my code.
Your wildcard is "*.txt".
Your subdirectories don't have a .txt extension so they won't
show up in the search.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
There are .txt files in Subdirs too.
|
|
|
|
|
But the SubDirs will be Ignored because they do not have a '.txt' extension in their name.
(For Still the best explanation about Command Line Parsing Rules, Look up any book about DOS 6.00). DOS may have died, but many of its parsing rules persist.
Bram van Kampen
|
|
|
|
|
Hi Masters!
--------------
In a MFC project, I posted some messages to an edit box as bellow:
m_ctlEditBox.PostMessage(WM_KEYDOWN, VK_A);
m_ctlEditBox.PostMessage(WM_KEYDOWN, VK_B);
m_ctlEditBox.PostMessage(WM_KEYDOWN, VK_C);
m_ctlEditBox.PostMessage(WM_KEYDOWN, VK_D);
.
.
.
The characters been recieved to the edit box are being formatted as I press SHIFT key or CAPS_LOCK toggles!
I wonder if is there something like TranslateMessage within it's procedure?
Thank you masters!
|
|
|
|
|
Jusef Marzbany wrote: I wonder if is there something like TranslateMessage within it's procedure?
Not that's documented. The edit control window proc could be
checking the key states on it's own.
TranslateMessage is being called by the MFC message loop, however.
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
You can try to send WM_CHAR.
If it works, it's very likely that it has a TranslateMessage.
professional
|
|
|
|
|
That doesn't make sense. WM_CHAR messages are produced by TranslateMessage() 
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
|
|
|
|
|
If WM_CHAR is handled by the edit's window proc, it's likely that WM_KEYDOWN are tranlated to WM_CHAR by TranslateMessage.
If not, it's likely that there is no TranslateMessage, keyboard messages are handled
all in WM_KEYDOWN.
professional
|
|
|
|
|
I guess I see what you're getting at....
A window proc may process a WM_KEYDOWN message without ever touching
a WM_CHAR message, true. What I was saying is that it will not use
the TranslateMessage API (which is what I thought the OP was referring to)
to do so - that would be redundant in most cases since TranslateMessage is
usually called from a thread's message loop.
Cheers ![Beer | [beer]](https://www.codeproject.com/script/Forums/Images/beer.gif)
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
So the edit's window proc might use the essential function inside TranslateMessage directly
when handling WM_KEYDOWN.
professional
|
|
|
|
|
I think you're wrong! cause WM_CHAR itself is produced by TranslateMessage()
Thank you masters!
|
|
|
|
|
If WM_CHAR is handled by the edit's window proc, it's likely that WM_KEYDOWN are tranlated to WM_CHAR by TranslateMessage.
If not, it's likely that there is no TranslateMessage, keyboard messages are handled
all in WM_KEYDOWN.
professional
|
|
|
|
|
Jusef Marzbany wrote: WM_CHAR itself is produced by TranslateMessage()
Correct.
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Iam developed one appication in MFC in my system which is having OS as XP 2000.its working fine.in my application iam maintaining some database connection and playing functionality(using some special Audio card).
its working well.
but iam facing problem in Xp systems.for database maintaining its working fine.but iam facing problem in playing functionality.while clicking play iam getting error.
note: i kept All DLLs in XP system what ever required for my application.
|
|
|
|
|
Have you tried to use dependency walker to find out the resources that your app depends on? More importantly, Have you installed the Visual C++ redistributables on the target machine?
Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche
.·´¯`·->Rajesh<-·´¯`·.
[Microsoft MVP - Visual C++]
|
|
|
|
|
initially i tried by registering required DLLs in XP system.later i installed VC++6 then also i shows the same error. 
|
|
|
|
|
????????????
What's the Problem. Language Country or Culture dependent Resources?
Or,
Is the problem: 'Will it run on any computer rather the one I compiled it on'
If the latter is the case, buy one and try!
Bram van Kampen
|
|
|
|
|
Hi all,
i m using CDateTimeCtrl in MFC,
here when i set a year before 1970 than it gives number of times this error message
Error is :: "The Parameter is incorrect."
please tell me how can i resolve this error.
thanks in advance.
IN A DAY, WHEN YOU DON'T COME ACROSS ANY PROBLEMS - YOU CAN BE SURE THAT YOU ARE TRAVELLING IN A WRONG PATH
|
|
|
|
|
You are probably using a CTime object to set the time, and according to MSDN, the earliest date for a CTime is 1/1/1970.
If you use a COleDateTime object instead, the dates can be from 1/1/100 to 12/31/9999.
Hope that helps.
Karl - WK5M
PP-ASEL-IA (N43CS)
PGP Key: 0xDB02E193
PGP Key Fingerprint: 8F06 5A2E 2735 892B 821C 871A 0411 94EA DB02 E193
|
|
|
|
|
I m try this
COleDateTime dtMin;
COleDateTime dtMax;
dtMin = COleDateTime(100, 1, 1, 0, 0, 0);
dtMax = COleDateTime(9999, 12, 31, 0, 0, 0);
CDateTimeCtrl m_date;
m_date.SetRange(&dtMin, &dtMax);
but after using this the problem remains same.
IN A DAY, WHEN YOU DON'T COME ACROSS ANY PROBLEMS - YOU CAN BE SURE THAT YOU ARE TRAVELLING IN A WRONG PATH
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
