|
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
|
|
|
|
|
Hello!
This is my first post on the Code Project, maybe you can help me.
In my dialog box I have a list view and a check box.
If the check box is unselected, the user should be able to select any list item they wish.
However, if the check box is selected, and there are only two list items, I want both list items automatically selected as it is a requirement of my application (right now, the user has to Shift select both list items before proceeding, and I want to remove this ambiguity by having both required list items selected for them).
However if there are more than two items in the list, there should be no automatic highlighting.
That said, I'm not sure how to go about this in Visual C++ .NET. Any suggestions?
Thank you. 
|
|
|
|
|
|
Mike, where the FAQ says:
Here is how to select an item whose index is nItemToSelect:
wndYourList.SetItemState ( nItemToSelect, LVIS_SELECTED,<br />
LVIS_SELECTED );
does "index" refer to an actual number? for example, if I have 2 items in my list, would the first item be index "0", then index "1"?
any others have alternative suggestions? (sorry, I am a novice)
|
|
|
|
|
aafcls wrote: does "index" refer to an actual number? for example, if I have 2 items in my list, would the first item be index "0", then index "1"?
Index refers to the item number, but it isn't necessarily in order (if you allow sorting your list items, it will be highly random). You should just need to call CListCtrl::GetItemCount to see how many items there are in the list and if there are 2 or fewer, use CListCtrl::GetNextItem with the default flags to get the item index. After that, use the index in your CListCtrl::SetItemState call.
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, this works.
However, instead of selecting each item by index number, is there a way to "select all"? (instead of having to do individual SetItemState)
|
|
|
|
|
|
Does anyone know what is going on here???
typedef void UpdateHandler(ObjectRootPtr, const RTI::AttributeHandleValuePairSet&);
|
|
|
|
|
|
Why do we have a typedef in front of this function of type void
typedef void UpdateHandler(ObjectRootPtr, const RTI::AttributeHandleValuePairSet&);
|
|
|
|
|
It is defining a function pointer. The syntax is a bit quirky since most people try to write it like this:
typedef (void UpdateHandler)(ObjectRootPtr, const RTI::AttributeHandleValuePairSet&);
It is basically declaring a type called UpdateHandler that will be able to point to functions with the following signature:
void f(ObjectRootPtr, const RTI::AttributehandleValuePairSet&);
These are typically used as callback functions.
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
|
|
|
|
|
Jay03 wrote: typedef void UpdateHandler(ObjectRootPtr, const RTI::AttributeHandleValuePairSet&);
That is odd, usually you'd write it as:
typedef void (*UpdateHandler)(ObjectRootPtr, const RTI::AttributeHandleValuePairSet&); which makes the new function pointer type UpdateHandler
--Mike--
Visual C++ MVP 
LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
VB > soccer
|
|
|
|
|
It might be useful to declare the calling convention if you are exporting these pointers from DLLs for example.
typedef void (__cdecl *UpdateHandler)(ObjectRootPtr, const RTI::AttributeHandleValuePairSet&);
typedef void (__stdcall *UpdateHandler)(ObjectRootPtr, const RTI::AttributeHandleValuePairSet&);
...
Don't try it, just do it! 
|
|
|
|
|
Hello everyone,
I have a question concerning the long data type. Using a 32-bit compiler, sizeof(long) = 4.
But what about 64-bit?
Regards,
Alex
Don't try it, just do it!
|
|
|
|
|
long is still 32-bits in a 64-bit compiler. If you want to have a 64-bit integer, use long long (platform independent) or __int64 (Windows).
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
