|
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
|
|
|
|
|
Chances are the problem is in the dll code since you are not doing any heap allocations in this code. I take it that APM_DLL is a class that is exposed from the dll (that is, it should have AFX_EXT_CLASS or __declarspec(dllexport) prior to the class name)? That being the case, what is it trying to do? The code relating to your GetSomething call would be helpful to debug your problem.
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
|
|
|
|
|
wellllllll... I had all of what you wanted typed in here and i accidently clicked on one of the stupid adverts in the left collum and lost it all...
If you send me your phone number at pblais@comcast.net, I can call you with all the details...
Thanks
|
|
|
|
|
pblais wrote: If you send me your phone number at pblais@comcast.net, I can call you with all the details...
Are you serious? Why would you even consider calling Zac on the phone? Post your Q&A here so that everyone can contribute and benefit.
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|