|
In the OnStart handler, you should start the thread, then loop the PeekMessage function until the thread exits or the user presses STOP.
void CThreadTestDlg::OnStart(){
MSG msg;
DWORD threadec;
g_bAbort = FALSE;
m_pThread = ::AfxBeginThread(ThreadProc, NULL);
while(::PeekMessage(&msg,NULL,0,0,PM_REMOVE)){
if(msg.message==WM_QUIT){
::PostQuitMessage(msg.wParam);
break;
}
::TranslateMessage(&msg);
::DispatchMessage(&msg);
if(!::GetExitCodeThread(m_pThread->m_hThread,&threadec))
return;
if(threadec!=STILL_ACTIVE)break;
}
}
I apologize it this isn't right; I'm much used to programming in C.
Peter O.
|
|
|
|
|
I think you should do like this...
void CThreadTestDlg::OnStop()
{
// wanna stop the thread...
g_bAbort = TRUE; DWORD dwExitCode = 0;
}
Thus you can abort the thread.
No pains, no gains.
|
|
|
|
|
I think you should do like this...
void CThreadTestDlg::OnStop()
{
// wanna stop the thread...
g_bAbort = TRUE;
}
Thus you can abort the thread.
No pains, no gains.
|
|
|
|
|
1) you should use WaitForSingleObject instead of Sleep/GetExitCodeThread in OnStop.
2) try marking g_bAbort with 'volatile' modifier
Tomasz Sowinski -- http://www.shooltz.com
- It's for protection
- Protection from what? Zee Germans?
|
|
|
|
|
Hello all,
I have a Win32 Application that uses standard C and Win32 API calls (creating directories and setting security permissions) along with a single DialogBox.
The program executes fine in Visual Studio, but when I go to run it from the .exe file outside of VS, nothing happens.
Double-clicking the .exe I get no response.
Any help in getting this Application to standalone would be greatly appreciated.
Sincerely...
Trish
|
|
|
|
|
As long as you have the source code you should be ok.
The first thing that I would do is make liberal use of ASSERTs or at least popup some message boxes in your WinMain to see how far it gets before it crashes. Do this every place that could possibly make your app exit.
One more thing that I would like to ask is are you trying to use the same type of build to run it inside and outside of the debugger.
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!
|
|
|
|
|
Hi kilowatt,
Thanks for the response. I did read somewhere to move my .exe outside of the Debug folder and into the directory with all other project files.
I did this and now the .exe responds to the double-click.
Have a good one!
Trish
|
|
|
|
|
Hello,
Trying to decode a tiff file from eFax with libtiff. I noticed that the decoded image is shorter. How do I detect and handle a tiff-fax file has horizontal ratio of 2:1? I noticed that acdsee and irfanview can decode the fax file with the right ratio.
Thanks!
|
|
|
|
|
Hello all, I was wondering if anyone can help me with this little problem. I have a project in which I use MDI. When it starts up the program opens a blank document. I would like it NOT to open any document at all and rely on the use the open a file. Any idea how to do that? Thanks
|
|
|
|
|
plonk this in your app's InitInstance() function where the original version is:
// Dispatch commands specified on the command line
cmdInfo.m_nShellCommand = CCommandLineInfo::FileNothing;
if (!ProcessShellCommand(cmdInfo))
return FALSE;
"... and so i said to him ... if it don't dance (or code) and you can't eat it either f**k it or throw it away"
sonork: 100.18128 8028finder.com
|
|
|
|
|
I'm using MAPi to email attachments (thanks to a couple articles here on CodeProject!), But I think the behavior I want is not available in MAPi.
I want the application to open the default mail program (i.e. Outlook) with the attachment added then in Outlook the user can then add comments, select address etc. the problem is MAPi sends the email directly to the outbox bypassing Outlook.
I've seen this behavior, opening Outlook and adding an attachment, in many programs and assumed it was part of MAPi.
What am I missing?
|
|
|
|
|
Hi, how can I access a file in home directory of current user? Can I use a filename like "~/appname/file.ini" or what do I need to do? It should work with WinME/2000/XP? Thanks in advance!
|
|
|
|
|
XP and 2000 have a environmental variable %user% that will give you the name of the logged in user. I guess that should be able to put used in a filename.
Michael 
Time flies like an arrow. Fruit flies like a banana
|
|
|
|
|
Hello there,
<blockqoute> is there a way to programmatically add user-accounts in NT?
- YES!
- How?
And why aren't the lsa* functions like lsaopenpolicy and such documented (in MSDN)?
(Where is it documented?)
Georg Haan
|
|
|
|
|
Georg Haan wrote:
is there a way to programmatically add user-accounts in NT?
Yes
Georg Haan wrote:
- How?
Sorry, don't remember right now 
Georg Haan wrote:
And why aren't the lsa* functions like lsaopenpolicy and such documented (in MSDN)?
(Where is it documented?)
They are documented in the latest MSDN Library (It's the one I have installed, so it's the only one I have checked)
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
Start with NetUserAdd() function and read documentation around it, it's quite easy to get it working.
Martin
--------------------------------------------
C'mon we all know computers are experimental devices and should only be used for playing games.
Using them for alternative stuff like business, is clearly not using them for what they are intended.
Colin Davies
|
|
|
|
|
Hello all,
I have an MDI application that displays bitmaps on the MDI child windows.
I made a new Dialog window class. How can I get OnDraw to draw the bitmaps to these dialog window instead of the MDI Child Windows?
I read something about switiching View Classes, but I am lost as to why I would/what that really means/and what it is for.
Do I have to do something to have OnDraw draw to the Dialog windows instead of the MDI Child Windows?
Pleae help,
NickOne
|
|
|
|
|
you'll have to handle the OnPaint function in the dialog class. you can really redirect OnDraw/OnPaint fromone window to another - each window (wether view, dialog, button, or whatever) draws itself.
-c
To explain Donald Knuth's relevance to computing is like explaining Paul's relevance to the Catholic Church. He isn't God, he isn't the Son of God, but he was sent by God to explain God to the masses.
/. #3848917
|
|
|
|
|
Cool! Thanks!
Does this apply as well (making an OnDraw/OnPaint handler) if I make a new MDI child class?
NickOne
|
|
|
|
|
yep. pretty much anytime you want a view window to show something, you have to draw it yourself in OnDraw. the exceptions are the formview and tree/listview things where you're really just using standard controls as a view.
for dialogs and most other controls, you do the drawing in the OnPaint function.
i find the best way to do image drawing in a dialog is to take a static rectangle control and fence off an area within the dialog. then, when it's time to draw (in nPaint) i find that control's rectangle, deflate it a little and draw inside of it. that way, you a) have a nice rectangluar border around the image and b) you can design around the image area, if you need other controls in the dialog.
-c
To explain Donald Knuth's relevance to computing is like explaining Paul's relevance to the Catholic Church. He isn't God, he isn't the Son of God, but he was sent by God to explain God to the masses.
/. #3848917
|
|
|
|
|
I would like to give you one more piece of information that you might find helpful as to why the OnDraw and OnPaint methods exist and when to use them.
OnPaint is a message handler that handles an actual message from windows (WM_PAINT). Every window will get a WM_PAINT message, and in turn the OnPaint handler will be called when a window needs to be repainted. This includes buttons, static controls, treeview controls, dialogs and so on, even the MDI children that you are handling the OnDraw method.
The OnDraw method is a method in MFC that is usually used for windows that represent documents. The default action for the OnPaint handler of a document window prepares a HDC and calls the OnDraw handler. All of your painting that is required for your document should go in the OnDraw handler. This is because MFC also has the OnPrint or WM_PRINT message call the same OnDraw handler that you used to draw your window. The only difference is that it passes you a HDC that is for a printer rather than your monitor. This allows you to perform the painting code for your document in one place, and the MFC framework can take advantage of that.
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!
|
|
|
|
|
Hi everyone, l'm currently working on linking a program to its GUI application. And l was wondering if executing the program from within the GUI code is the correct way to approach it. lf it is, can someone give me some suggestions as to how l should go about it? l've tried calling the system command in my code (eg. system("program < inputDataFile") ), but doing so will result in a black window popping up. l do not want to see a black window flash for a couple of seconds everytime l run my program, so l hope there is another way to do this.
Any comments will be appreciated, thanks!
|
|
|
|
|
See this article.
/ravi
Let's put "civil" back into "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
To keep the black window from popping up, try WinExec with the SW_HIDE flag.
Even better would be to redirect output entirely, not to a file, but to a pipe. Nothing gets written to a drive this way... Microsoft has sample code for this, you'l find ithere.
Georg Haan
|
|
|
|
|
Try CreateProcess
Todd Smith
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
