|
Michael Dunn wrote:
Please see my two articles on the string wrapper classes, where I cover all these details
This is what you should have said in the first place. 
Frankly, I believe Chris should show a spanking and blinking STRING CONVERSION article link in the "new message" form. This would avoid many posts...;P
Back to real work : D-27.
|
|
|
|
|
Hi,
Using MFC DLL, no enter point such as "WinMain" in Win32 DLL, I find it's difficult to begin a thread at the beginning of MFC DLL and terminate the thread before Termination of DLL. Because of using a lot of MFC class, I have to use MFC DLL, but I also have to use a thread at the beginning of DLL and terminate it just before the end of DLL. Tell me how to deal with this dellima.
Thanks in advance.
Extreme programming. Do the No.1
|
|
|
|
|
The entry point for DLLs is, by default DllMain, unless you specify otherwise in the linker settings.
In your DLL Main you're handling a DWORD reason code for something calling DllMain. Depending on what you're doing, you may want to start your threads when a process attaches, or more safely, when a thread attaches; and end it when the thread or process unloads the DLL (See DllMain[^]):
BOOL WINAPI DllMain(HINSTANCE hModule, DWORD dwReason, LPVOID lpvIgored)
{
switch (dwReason)
{
case DLL_PROCESS_ATTACH:
break;
case DLL_THREAD_ATTACH:
break;
case DLL_THREAD_DETACH:
break;
case DLL_PROCESS_DETACH:
break;
default:
return FALSE;
}
return TRUE;
}
Please note, that if you fail to create your thread, you should probably return FALSE, and not break out of the switch. Also, calling TerminateProcess or TerminateThread may not be a good idea since it won't do it gracefully. You'll be safer setting a flag for your thread to terminate (such as a boolean bStillRunning = false.) If you need to do work after the thread finishes, you should probably use WaitForSingleObject with an event handle which is "set" by your created thread when it exits:
while()
{
}
SetEvent();
return 0;
Take a look at Using Event Objects[^] on MSDN.
You will have to keep a "list" of event handles, and WaitForSingleObject on the thread event handle in question. You can't just create one handle for signalling the exit of your thread because you may have multiple threads exiting and not know which one was the one you were concerned with.
When you create the thread, you can pass the specific event handle you create for the thread to your "worker" thread through the parameters part of whatever you're using to create the thread (e.g., AfxBeginThread())
|
|
|
|
|
A regular MFC DLL has a CWinApp object, so you use its InitInstance() and ExitInstance() functions to do your init and cleanup tasks.
--Mike--
"I'd rather you just give me a fish today, because even if you teach me how to fish, I won't do it. I'm lazy." -- Nish
Just released - 1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click!
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
Oh yeah, oops, I'm stuck in Win32 somewhere, I haven't used MFC for DLLs in over two and a half years 
|
|
|
|
|
Hi,
There should be a main function, and in it's space can i use theApp object as well as it's member functions. My problem is, there is only a theApp object and nothing else.
If I use Message queue in this thread, WaitForSingleObject will be used to wait for the end of thread in the main function.
No main function, where can I write this code for wait for the termination of this thread?
thanks
Extreme programming. Do the No.1
|
|
|
|
|
You're not seeing the big picture with DLLs. The Main() function you're thinking of is wrapped in calls for loading and unloading the DLL. When a process or thread wishes to use your DLL, it calls (eventually) LoadLibrary. At this point, the DLL entry DllMain() is called. In the case of MFC, it eventually gets to CWinApp::InitInstance. When a process or thread that's using your DLL exits, it "detaches" from the DLL, calling DllMain(), with the detach reason (dwReason in my example earlier.) Eventually, in MFC, ExitInstance will be called, and that's where you'd do the WaitForSingleObject stuff, of course waiting on the thread/process-specific event handle.
It's a bit daunting and confusing at first, but you have to realize that the entry point (DllMain) is your "main" function, and it gets "called" at least twice. Once when the DLL is loaded, and once when it's "let go."
MFC wraps all of this in a CWinApp, where in your implementation you can override the behaviour of InitInstance and ExitInstance. That's where you'd do your "work." InitInstance to create your thread, ExitInstance to signal the thread should "shut down" and where your WaitForSingleObject would take place.
If you were going the ATL or straight Win32 way, you'd write your own DllMain() as I had shown in an earlier response to this thread. It amounts to the same thing: when loaded, create your thread, specific to the process/thread at hand; when unloaded, you stop (hopefully gracefully) the thread, specific to the process/thread at hand.
The "end" of your "main function" is the same, when dwReason is the process/thread detaching, or when ExitInstance() on your CWinApp derived class is called.
|
|
|
|
|
Hello,
I am doing the following to shake a window (kinda like Yahoo! messenger's BUZZ friend).. Mine doesn't look as clean as theirs, any ideas on how I can do this better?
CRect pRect;
pMain->GetWindowRect(pRect);
int iH = pRect.Height();
int iW = pRect.Width();
pRect.InflateRect(-10,10);
pMain->MoveWindow(pRect,TRUE);
Sleep(10);
pRect.InflateRect(10,-10);
pMain->MoveWindow(pRect,TRUE);
Sleep(10);
pRect.InflateRect(20,20);
pMain->MoveWindow(pRect,TRUE);
Sleep(10);
pRect.InflateRect(-20,-20);
pMain->MoveWindow(pRect,TRUE);
Sleep(10);
and so on and so on.....................................
|
|
|
|
|
Try smaller increments instead of a 10 pixel jump:
#define MAX_INFLATE_ITERATIONS 20
#define MAX_BOUNCE_ITERATIONS 3
#define INFLATE_INCR 2
#define INFLATE_SLEEP 5
CRect rc;
int i, j;
pMain->GetWindowRect(&rc);
for(j = 0; j < MAX_BOUNCE_ITERATIONS; j++
{
for(i = 1; i <= MAX_INFLATE_ITERATIONS; i++)
{
rc.InflateRect(-INFLATE_INCR, INFLATE_INCR);
pMain->MoveWindow(&rc, TRUE);
Sleep(INFLATE_SLEEP);
}
for(i = MAX_INFLATE_ITERATIONS; i > 0; i++)
{
rc.InflateRect(INFLATE_INCR, -INFLATE_INCR);
pMain->MoveWindow(&rc, TRUE);
Sleep(INFLATE_SLEEP);
}
}
Of course you won't be processing any windows messages at the time 
|
|
|
|
|
OOps, Shake, not expand, you could alter the top and left of the rect before moving the window, oh well, you get the point SHouldn't give advice when passing through paint fume filled lobbies...
|
|
|
|
|
imariano wrote:
SHouldn't give advice when passing through paint fume filled lobbies...
Too funny! Thanks for the reply, I'll give that a shot 
|
|
|
|
|
I was reading thru the GDI region docs a couple of days ago, and saw that you can select a HRGN into a DC. MSDN says "After a region is selected into a device context, the application can perform various operations on it" however AFAICT all the region APIs take a HRGN to operate on, instead of operating on whatever is currently in a DC.
So, riddle me this... what does selecting a region into a DC actually do?
--Mike--
"I'd rather you just give me a fish today, because even if you teach me how to fish, I won't do it. I'm lazy." -- Nish
Just released - 1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click!
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
Michael Dunn wrote:
what does selecting a region into a DC actually do?
It is basically like calling SelectClipRgn. It makes the current clipping rgn for the DC the region that you select into the DC.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
What the heck does that mean? I've never seen this error before, but Explorer.exe is crashing and reporting it, then when VC++ tries to debug it, the whole system goes unstable. What is a "First-chance Exception"? I don't understand the reference.
"When in danger, fear, or doubt, run in circles, scream and shout!" - Lorelei and Lapis Lazuli Long
|
|
|
|
|
From what I recall, first chance exceptions are "expected" failures within the Windows API (eg: at the network and file system layers). Here's[^] a link that may (not) shed more light on the subject.
/ravi
Let's put "civil" back in "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Thanks, Ravi! That does shed some light on it, and adds it to a list of clues I've been accumulating until a pattern appears. The first chance exception refers to an error state available to the debugger; for a few weeks now my server has had stability problems, and when attempting to shut down the system, has reported that certain processes could not be shut down as they were being debugged. This occurs when the debugger is not running, and this episode appears to be related. Thanks for the tip!
"When in danger, fear, or doubt, run in circles, scream and shout!" - Lorelei and Lapis Lazuli Long
|
|
|
|
|
When I UpdateData(TRUE) to set the value in my Calendar Control to its corresponding CTime object it arbitrarily adds a fixed number of days to the selected date. Example:
If the the user selected November 5, 2002 the date that would be stored in the CTime object would November 12, 2002. Likewise if they choose December 8, 2002 the date that would be stored would be December 20, 2002.
Fairly annoying. Any ideas?
|
|
|
|
|
I thought the following would read in blocks of 15 floats from a binary file but after a bunch of correct reads all the output numbers are giberish, numbers like 1E-20 type stuff..
I have to use stdio routines like fread, I have written the same code with fstreams and it works fine. I am missing some stdio quirk or something.. It seems to get hosed when the _cnt variable in the FILE structure becomes < then the size of 15 floats (60).. I believe it has to do with the buffering of the file, which is the system 4096 size.
float CPDATA[15];
do{
fread((char*)CPDATA,sizeof(float)*15, 1, thO->fd);
//outfile read info to a file
outfile<<ftell(tho->fd)<<" ";
for(int i=0;i<15;i++)
outfile<
|
|
|
|
|
Anonymous wrote:
fread((char*)CPDATA,sizeof(float)*15, 1, thO->fd);
Just an idea, try with fread((unsigned char*)CPDATA,sizeof(float)*15, 1, thO->fd); instead...
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
Hello,
I need to display the progress during a file open (serialization) process. I have looked for some examples of how to do this and havent found any. Has anyone worked on this? The easiest approach might be to use the file size and the number of bytes read?
Ted
|
|
|
|
|
That's the easiest approach:
m_wndProgress.SetRange32(0, nFileSize);
m_wndProgress.SetPos(0);
while()
{
m_wndProgress.SetStep(nReadSize);
m_wndProgress.StepIt();
}
Here's a cool way to add the progress bar to the status bar: Showing progress bar in a status bar pane[^]
"The greatest danger to humanity is humanity without an open mind."
- Ian Mariano
http://www.ian-space.com/
|
|
|
|
|
if you have a file, foo.cpp, which contains the implementations of some (C-style, not classes) functions used elsewhere in the app, and a header file, foo.h, which defines those functions, would you #include "foo.h" inside foo.cpp ?
assume there's nothing in foo.h that foo.cpp needs: no constants, struct definitions, etc. foo.h simply provides an external definition of the functions in foo.cpp.
strictly, i think it's unnecessary, because the functions aren't really dependent on the external definitions - that association doesn't happen until the linker gets involved and it needs to match what callers of foo's functions think those functions are to the functions that the linker has available.
on the other hand, it seems logically 'right' to associate them somehow.
opinions?
-c
“losinger is a colorizing text edit control”
-- googlism
|
|
|
|
|
if foo.h defines those functions as 'extern "C"', you actually have to #include the header with the functions, or else the compiler will define them as C++ functions, and you'll get linker errors.
carry on, my wayward sons.
-c
“losinger is a colorizing text edit control”
-- googlism
|
|
|
|
|
You don't have to even #include an .h (in C or C++) if you define the prototypes of any functions used in your implementation file
I, personally, include the header for readability. And besides, you can write the functions in any order since all their prototypes are defined ahead of time.
Of course, if you want "C" linkage you have to define them as extern "C".
"The greatest danger to humanity is humanity without an open mind."
- Ian Mariano
http://www.ian-space.com/
|
|
|
|
|
Why then would foo.h exist at all ?
Shouldnt foo.cpp be foo.c to distinguish itself ?
IMHO if you use .cpp as an extension you should hold the relevant .h header as per normal usage.
But if it's C you should name it as such as well.
Sure it won't make any differences to compiling but it becomes easier to have conventions to follow.
Regardz
Colin J Davies
Sonork ID 100.9197:Colin
You are the intrepid one, always willing to leap into the fray! A serious character flaw, I might add, but entertaining.
Said by Roger Wright about me.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
