|
No duh, I mean mfc42, mfc42u, mfco42, etc.
__________________________________________
Let's push Satan
|
|
|
|
|
that depends on your Unicode, Debug/Release, and static/dynamic CRT settings.
see the big #if/#else block near the top of AFX.H (C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\VC98\MFC\Include\AFX.H, on my installation)
Cleek | Image Toolkits | Thumbnail maker
|
|
|
|
|
I am building an open-source project, where first I have to build the base library(INDRI.lib). I successfully generate the base library file without any error. However, when I run the samples use that lib file, it creates LNK 2019 errors,
indri.lib(File.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) void * __stdcall CreateMutexA(struct _SECURITY_ATTRIBUTES *,int,char const *)" (__imp_?CreateMutexA@@YGPAXPAU_SECURITY_ATTRIBUTES@@HPBD@Z) referenced in function "public: unsigned int __thiscall indri::file::File::read(void *,unsigned __int64,unsigned int)" (?read@File@file@indri@@QAEIPAX_KI@Z)
indri.lib(KrovetzStemmer.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) unsigned long __stdcall WaitForSingleObject(void *,unsigned long)" (__imp_?WaitForSingleObject@@YGKPAXK@Z)
indri.lib(Thread.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) int __stdcall CloseHandle(void *)" (__imp_?CloseHandle@@YGHPAX@Z)
Can anyone suggest the solution of the problem?
Is it related socket library?
SKP
|
|
|
|
|
Are your samples being build as UNICODE builds?
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
No.
All samples are being build as MultiByte Character Set(MBCS) builds.
Sac
|
|
|
|
|
Hi,
I am new to the forum. I am working on VC++ programming without using MFC... the code goes as follows
<the following="" code="" is="" inside="" the="" callback="" function="" of="" a="" dialogbox="" and="" run="" when="" start="" button="" pressed="">
<br />
<br />
for (frm=0;frm<frames;frm++){
<br />
sprintf(Messages, "Processing Frame... %d",frm+1);<br />
SendDlgItemMessage(hDlg,IDT_PROCESS_STATIC2,WM_SETTEXT,0,(LPARAM) Messages);<br />
SendDlgItemMessage(hDlg, IDP_PROCESS_PROGRESS, PBM_SETPOS, (WPARAM)frm+1,0);<br />
UpdateWindow(hDlg);<br />
<br />
<more processing code that has nothing to do with the dialog box><br />
}<br />
when the program runs the progress bar and the text gets updated when the dialog box is in focus. when I open another application or when I minimize the dialog box when it is running(i.e. when it looses focus) and then return back, it doesn't get updated. Can someone tell me what property of the dialogbox I might have missed...
Thanks,
Naresh.
|
|
|
|
|
When the application is obscured by another, and the for loop exits, does the progress bar and text update one last time? If so, this indicates your primary thread is too busy with the processing to handle the paint-related messages. You'll need to employ a secondary thread to do the processing so the primary thread can remain responsive.
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
There are other lines of code within the for loop which are not related to paint-related messages and they are getting executed when the application is obscured. As you say, the progess bar and text are updated for about a second or so before it stops. I probably should start a secondary thread. Which of them should I move to the secondary thread? the process or the paint related messages?
|
|
|
|
|
Shrinaresh wrote: Which of them should I move to the secondary thread? the process or the paint related messages?
See here for a better understanding of "worker" threads.
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Thanks for the link... I shall read that and get back to you. Meanwhile, I am having one more problem. After WM_DIALOG is sent and the DialogBox is initialized, i want a button to be triggered automatically and the control to be transfered to the statements written for the button. How can I do that.
|
|
|
|
|
Shrinaresh wrote: After WM_DIALOG is sent...
Is this a user-defined message (UDM)?
Shrinaresh wrote: ...i want a button to be triggered automatically and the control to be transfered to the statements written for the button. How can I do that.
At the end of handling the WM_INITDIALOG message, post a message to the dialog. In the handler for that message, simply call the same function that clicking the button would call.
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I meant WM_INITDIALOG. I am sorry. I tried posting the message within WM_INITDIALOG but the button is called even before the dialogbox is displayed and the processing starts... I want the button to be invoked after the dialogbox is displayed. How do I do that?
|
|
|
|
|
Show the WM_INITDIALOG code.
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
case WM_INITDIALOG:<br />
SetDlgItemText(hDlg, IDT_PROCESS_STATIC2, "Waiting for input...");<br />
SendDlgItemMessage(hDlg, IDP_PROCESS_PROGRESS, PBM_SETRANGE, 0, MAKELPARAM(0, frames)); <br />
SendDlgItemMessage(hDlg, IDP_PROCESS_PROGRESS, PBM_SETSTEP, (WPARAM)1,0);<br />
return TRUE;
now, if i add PostMessage(hDlg, WM_COMMAND, MAKEWPARAM(BN_CLICKED, IDB_PROCESS_START), LPARAM(hDlg)); before return TRUE; the button is clicked and the processing starts even before the Dialog Box is displayed... i tried SendMessage too, didnt work 
|
|
|
|
|
Is the code that responds to the BN_CLICKED message in a separate thread?
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
No its in the same thread...
|
|
|
|
|
See my suggestion here about employing a secondary thread.
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
How can I get millisecond time? CTime::GetCurrentTime() only return second precise.
Thank you.
|
|
|
|
|
Use ::GetSystemTime(SYSTEMTIME* lpSystemTime);
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Thank you. But how accurate can I trust it?
|
|
|
|
|
Its only as accurate as Windows will let it be, and how accurate your system clock is set to. It updates itself about ever 10 milliseconds, if memory serves me correct.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac Howland wrote: It updates itself about ever 10 milliseconds...
For Windows NT. For Windows 9x, it's much less accurate at 55ms.
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
hello,
for the last day or so, every time i make a change to any source file, the compiler (msvc 6) asks to make all .sbr files and the main .bsc file. i know they're up to date--i can see that from windows. i've tried turning on and off "generate browse info" and rebuilding all, but to no avail. any suggestions?
thanks,
edward
|
|
|
|
|
Check the date and time of your stdafx.h file and any files that it includes. One of these files probably has it's time set to some point in the future.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
I have a strange problem.. Well, strange for me.
I have written a dll called APM_DLL.cpp and its header APM_DLL.h.
I am using this dll in a dialog app calle CAPM_CPDlg.cpp and CAPM_CPDlg.h.
I declare the dll in the dialog as a pointer as follows..........
In CAPM_CPDlg.h, I have the following:
#include "APM_DLL.h"<br />
<br />
class CAPM_CPDlg : public CDialog<br />
{<br />
public:<br />
CAPM_CPDlg(CWnd* pParent = NULL);
<br />
APM_DLL *MYDLL;<br />
Then in CAPM_CPDlg.cpp, I do the following:
BOOL CAPM_CPDlg::OnInitDialog()<br />
{<br />
CDialog::OnInitDialog();<br />
<br />
ASSERT((IDM_ABOUTBOX & 0xFFF0) == IDM_ABOUTBOX);<br />
ASSERT(IDM_ABOUTBOX < 0xF000);<br />
<br />
CMenu* pSysMenu = GetSystemMenu(FALSE);<br />
if (pSysMenu != NULL)<br />
{<br />
CString strAboutMenu;<br />
strAboutMenu.LoadString(IDS_ABOUTBOX);<br />
if (!strAboutMenu.IsEmpty())<br />
{<br />
pSysMenu->AppendMenu(MF_SEPARATOR);<br />
pSysMenu->AppendMenu(MF_STRING, IDM_ABOUTBOX, strAboutMenu);<br />
}<br />
}<br />
MYDLL = new APM_DLL;<br />
Don't ask me why, I inherited this code.
I have also have the following declaration inside APM_DLL.h.
byte RxBuffer[256];<br />
Anyways... in the main app, I make a call like MYDLL->GetSomething(). GetSomething() stores values in RxBuffer[0..n]. Then when I want to access this in the main app, I use MYDLL->RxBuffer[0..n]. This has worked great until this morning when I did the following in APM_DLL.h
byte ROM_Buffer[100];<br />
byte RxBuffer[256];<br />
Now, if I put a break inside the actual dll and look at RxBuffer, it is ok. Then when I put a break in the main app right after MYDLL->GetSomething, MYDLL->RxBuffer is trashed. If I comment out the ROM_Buffer declaration, everything works fine inside the dll and out It only gets slammed if I compile the ROM_Buffer declaration. I have moved that declaration after the declaration of RxBuffer and ahead of a variable that I don't need to access from the main app. Everything seems to be working. But, I think this is only a band-aid and I am still walking over something important.
By the way... if I make ROM_Buffer[200], I get the following crash error
---------------------------
Microsoft Visual C++ Debug Library
---------------------------
Debug Assertion Failed!
Program: D:\Projects\Motorola\GS Iden APM\Software\Release\APM_CP.exe
File: dbgheap.c
Line: 1099
Expression: _pLastBlock == pHead
For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.
(Press Retry to debug the application)
---------------------------
Abort Retry Ignore
---------------------------
Any ideas and/or suggestions?
Regards
Pierre
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
