|
People ask this question three times a week
There are many articles here on CP how to describe it. You might want to take a look at "Dialog box tricks" by Nishant S
modified 12-Sep-18 21:01pm.
|
|
|
|
|
Locked Ghost wrote:
Why is that?
A window should come on top only if explicitely asked by the user. Otherwise, it's like a annoying popup on the web : it may interrupt you while you were entering text somewhere, or clicking somewhere.
That's basic UI guidelines. I don't think further explanations are required.
Back to real work : D-27.
|
|
|
|
|
|
You will be my best friend if you can help me on this one
line of code for error 2440:
CString str_somedata;
TCHAR Data[] = str_somedata;
then I tried
TCHAR Data[] = str_somedata.GetBuffer(0);
results in cannot convert from 'char *' to 'char [] error
Please Help Me?? I have been wasting at least 2 hours
|
|
|
|
|
try TCHAR * instead of TCHAR []
-c
“losinger is a colorizing text edit control”
-- googlism
|
|
|
|
|
I still get same errors.
The reason why I need to convert is that TCHAR Data[] gets past to a function, that would be a hasle to change
|
|
|
|
|
I take that back, it works with
TCHAR* Data= str_somedata.GetBuffer(0);
Thanks!!!
|
|
|
|
|
Two problems. One, you can't declare a TCHAR[] on the stack unless it is initialized with a string literal, such as:
TCHAR szBob[] = _T("hello!"); Two, you are trying to put a CString into a character array. A CString is a wrapper class that manages its own character buffer. You can do this:
TCHAR* psz = str_somedata.GetBuffer(0); as long as you understand what that means - you're temporarily getting control over the character buffer.
Please see my two articles on the string wrapper classes, where I cover all these details.
--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
|
|
|
|
|
TCHAR* psz = str_somedata.GetBuffer(0);
Perfect!!
|
|
|
|
|
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
|
|
|
|
|