|
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
|
|
|
|
|
Ok... David.. I'll retype the whole thing again
In the header file for the main dialog app, I have the following code:
#include "APM_Driver.h"<br />
<br />
<br />
class CAPM_CPDlg : public CDialog<br />
{<br />
public:<br />
CAPM_CPDlg(CWnd* pParent = NULL);
<br />
APM_Driver *MYDLL;<br />
In the main cpp file for the dialog app, I have the following code:
<br />
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 />
<br />
SetIcon(m_hIcon, TRUE);
SetIcon(m_hIcon, FALSE);
<br />
MYDLL = new APM_Driver;<br />
In the dll header file I have the following code:
<br />
#if !defined(AFX_APM_Driver_H__C456738C_8198_48CC_8DE2_25874D70899F__INCLUDED_)<br />
#define AFX_APM_Driver_H__C456738C_8198_48CC_8DE2_25874D70899F__INCLUDED_<br />
<br />
#if _MSC_VER > 1000<br />
#pragma once<br />
#endif // _MSC_VER > 1000<br />
<br />
<br />
#include "APM_exportheader.h"<br />
.<br />
.<br />
.<br />
class APM_API APM_Driver <br />
{<br />
public:<br />
APM_Driver();<br />
virtual ~APM_Driver();<br />
<br />
char GetGetSomething();<br />
<br />
byte ROM_Buffer[100]; <----BAD LINE<br />
byte RxBuffer[256];<br />
byte TxBuffer[256];<br />
.<br />
.<br />
.<br />
};<br />
<br />
#endif // !defined(AFX_APM_Driver_H__C456738C_8198_48CC_8DE2_25874D70899F__INCLUDED_)<br />
in APM_exportheader.h, I have the following code:
<br />
#ifdef EXPORT_FUNCTIONS<br />
#define APM_API __declspec(dllexport)<br />
#else<br />
#define APM_API __declspec(dllimport)<br />
#endif<br />
In the dll cpp file, I have the following code:
#include "APM_Driver.h"<br />
.<br />
.<br />
.<br />
char APM_Driver::GetGetSomething()<br />
{<br />
char data_1[] = {1,1,12,0};<br />
<br />
char i_loop1 = 0;<br />
for(i_loop1 = 0; i_loop1 <= data_1[1] + 1; i_loop1++)<br />
data_1[3] ^= data_1[i_loop1];<br />
<br />
comms1->Output(data_1, 4);<br />
comms1->FlushRxBuffer();<br />
<br />
data_byte_recieved = false;<br />
<br />
Timeout = 100;<br />
while(data_byte_recieved == false)<br />
{<br />
RX_Handler();<br />
Sleep(5);<br />
if(Timeout-- == 0)<br />
return 1;<br />
}<br />
<br />
char c_CRC = 0;<br />
<br />
RxBuffer[0]--;<br />
c_CRC ^= RxBuffer[0];<br />
for(i_loop1 = 1; i_loop1 <= RxBuffer[0]; i_loop1++)<br />
c_CRC ^= RxBuffer[i_loop1];<br />
<br />
c_CRC ^= RxBuffer[i_loop1];<br />
<br />
if(c_CRC)<br />
return 1;
else<br />
return 0;
}<br />
The only reason I have for why it is so spaghetti like this, other than the fact that I inherited this is as follows. We, the Microelectronics people, design hardware that has to be tested with a PC. We try to keep the items that are specific to the hardware only in a DLL so we can turn it over to the test group later. We build our own Control Panels, hence the CP in the main dialog name to test and debug our designs. The test group, in turn uses the DLL in a "big picture" to test a complete system.
That being said, I have a piece of hardware "hanging" off the PC's come port. In this case, this hardware is an APM. In this particular example, the control panel needs to read the version of the firmware that is in the APM so it has to call GetSomething(). It does this as follows:
void CAPM_CPDlg::OnConnect() <br />
{<br />
CString Display_Data = "";<br />
unsigned int iTemp = 0;<br />
<br />
Display_Data += " D E B U G - I N F O";<br />
Display_Data += "\r\n";<br />
Display_Data += "----------------------------------------------------";<br />
Display_Data += "\r\n";<br />
<br />
<br />
if(DUT->GetSomething())<br />
{<br />
Display_Data += "APM PIC : ";<br />
Display_Data += MYDLL->RxBuffer[1];<br />
Display_Data += MYDLL->RxBuffer[2];<br />
Display_Data += MYDLL->RxBuffer[3];<br />
Display_Data += MYDLL->RxBuffer[4];<br />
Display_Data += MYDLL->RxBuffer[5];<br />
Display_Data += MYDLL->RxBuffer[6];<br />
Display_Data += MYDLL->RxBuffer[7];<br />
Display_Data += MYDLL->RxBuffer[8];<br />
Display_Data += MYDLL->RxBuffer[9];<br />
Display_Data += MYDLL->RxBuffer[10];<br />
Display_Data += MYDLL->RxBuffer[11];<br />
Display_Data += MYDLL->RxBuffer[12];<br />
Display_Data += MYDLL->RxBuffer[13];<br />
Display_Data += "\r\n";<br />
}<br />
else<br />
Display_Data += "Not Connected";<br />
SetDlgItemText(IDC_DISPLAY, Display_Data); <br />
}<br />
If I comment the BAD LINE indicated above in the dll header file, everything runs fine. If I dont comment it out the following happens:
When I put a break in the GetSomething() function inside the DLL, RxBuffer is good but if I put a break in the control panel, MYDLL->RxBuffer is trashed.
If I move the declaration of ROM_Buffer below RxBuffer a few lines below the TxBuffer declaration, it works. But, I have a feeling I am trashing something else.
ALLLLLLLLLLLSO....
if I increase the size of ROM_Buffer to 200 I get this when I try to run it.....
---------------------------
Microsoft Visual C++ Debug Library
---------------------------
Debug Assertion Failed!
Program: D:\Projects\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
---------------------------
There David... is that enough information????
Regards
Pierre
|
|
|
|
|
Despite the fact that there are a few less than desirable lines of code in there (that is, if the person who originally wrote it was in a code review with me, they wouldn't be enjoying it at the moment), there really doesn't seem to be anything out of the ordinary going on (especially with reference to the heap). My guess is that there are a couple things likely causing your problem:
1) Somewhere, a string operation (sprintf, printf, sscanf, etc) is being used with the wrong type. After a while, your stack gets blown up and overruns your heap (which is where you notice the problem).
and/or
2) Somewhere a block of memory is being placed on the heap (your Dll class maybe), and at some point is being deleted by someone else, but the pointer is never null'ed, so you end up accessing invalid memory. You won't notice a major problem with that until you go to access a section in that memory that has been reallocated for something else (which will make your DLL class look like it is trashed, when in reality it is trying to trash something else).
To debug this, I would start commenting out sections of code to get down to a bare minimal application that works completely. Then, slowly uncomment a section at a time and see when you notice the problem. It is a slow process, but will likely be the most effective in this case.
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
|
|
|
|
|
Thanks Zac...
I have a couple of questions... one general and one specific to this problem....
First... Maybe you could tell us what "less than desirable lines of code" you are talking about. We microelectronics folks would be open to a code review from you and maybe learn a thing or two... Please feel free to review if you have time...
Second... I did some playing today and found that the RxBuffer array declared in the APM_Driver.h dll file gets shifted/trashed by the size of ROM_Buffer array. I say shifted/trashed because. In the constructor for the class, I initialize RxBuffer[x] to 0 to 255. If I don't compile ROM_Buffer then MYDLL->RxBuffer contains 0,1,2,3...255. If I make ROM_Buffer[3] then MYDLL->RxBuffer contains 205,205,205,0,1,2,3... but RxBuffer is still correct. So, you can see MYDLL->RxBuffer got shifted by the size of ROM_Buffer and the first n values were trashed by 205. I see this when I put a break in the main dialog right after the line.... MYDLL = new APM_Driver; in the on initdialog function
Once again.. thanks for the help Zac
Pierre
|
|
|
|
|
pblais wrote:
char data_1[] = {1,1,12,0};<br />
<br />
char i_loop1 = 0;<br />
for(i_loop1 = 0; i_loop1 <= data_1[1] + 1; i_loop1++)<br />
data_1[3] ^= data_1[i_loop1];
This isn't the best way to initialize an element of an array (nor declare one actually). It likely isn't the cause of your problem, but very well could be if you ever changed the size of the array. A better way to write it would be:
<br />
char data_1[4] = {1, 1, 12, 12};<br />
It is more efficient and decreases the chance for an error to sneak in the code.
For your second issue, if the next area in memory is getting trashed when you change the size of the array, look for something that is assuming a memory location (since this is a hardware simulation, I wouldn't be surprised to see a few). Also look for code similar the the segment above that writes to something out of bounds when dealing with the ROM_Buffer of a different size.
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: For your second issue, if the next area in memory is getting trashed when you change the size of the array, look for something that is assuming a memory location (since this is a hardware simulation, I wouldn't be surprised to see a few). Also look for code similar the the segment above that writes to something out of bounds when dealing with the ROM_Buffer of a different size.
Hi again Zac... I've been playing around since I posted.... By the way thanks for the help on the first part...
Anyways... The array below ROM_Buffer (RxBuffer) is affected but not really any code is run
In the main dialog:
MYDLL = new APM_Driver;<br />
bTestVal = DUT->RxBuffer[1]; <------BREAK ONE HERE<br />
Then in the APM_Driver.cpp file:
<br />
APM_Driver::APM_Driver()<br />
{<br />
baud_rate = 19200;<br />
SelectComms();<br />
}<br />
<br />
APM_Driver::~APM_Driver()<br />
{<br />
delete comms1;<br />
}<br />
<br />
void APM_Driver::SelectComms()<br />
{<br />
int i_c;<br />
<br />
<br />
for(i_c = 0; i_c <=255; i_c++)<br />
RxBuffer[i_c] = unsigned char (i_c);<br />
<br />
for(i_c = 0; i_c <=255; i_c++)<br />
TxBuffer[i_c] = unsigned char (i_c);<br />
i_c = 1; <------BREAK TWO HERE<br />
}<br />
As you can see comms1 = new CCommsDriver1; has been commented out. SO the only code that is executed are the two small loops that initialize RxBuffer and TxBuffer to 0->255. Yet when I break the code at BREAK TWO, both buffers are ok but when I stop at BREAK ONE, MYDLL->RxBuffer is trashed.
Thanks
Pierre
|
|
|
|
|
Its hard to say. Nothing in the code you've shown sticks out as a potential problem. Your best bet is to start commenting out code in your application code (not the dll) to get to a point where absolutely everything "works" (that is, no memory problems), and then to slowly umcomment blocks until you see the problem. With these types of issues, sometimes that is the only way to track it down.
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
|
|
|
|
|
well this is mine problem so far. i have some papers(formulars), and i want to print into them preciesly. what should i do since i can't change them 'cos they are allready printed and cannot be changed in any way. pls anyone who has some knowledge, help. btw mine application has some edit boxes, and i want to print their contents into my papers(formulars). pls help and many thanks
ivan
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
