|
it is vector of BYTE, sorry the code got modified when entered in the editor
Kings
|
|
|
|
|
My apologies also, I think your code got mangled by the HTML tags, you need to use <pre> tags around it (use the code button above the edit window) so it shows up, like:
std::vector<BYTE> m_v_Data;
int X;
int Y;
There is obviously some difference between your application and your DLL. Are they both compiled with the exact same definition for your structure, i.e. using a common header file?
|
|
|
|
|
No they are not, the DLL contains a Util method which is exposed using DLLExport and the COM loads the DLL and creates a method pointer out of it and asks it to fill the data.
Kings
|
|
|
|
|
Well you need to show us the exact code in the application and the DLL, so we can try to figure out what the difference may be.
|
|
|
|
|
I am afraid that could not be done, however if you could point me to the direction where I can start digging through or help me with how you wud have approached this issue it wud be helpful.
Kings
|
|
|
|
|
Sorry, but without seeing your code I have no idea what to suggest, other than some careful reviewing of your code, and use of your debugger.
|
|
|
|
|
It's very bad idea to use the complex types from one DLL to another. Firstly your DLLs can use different "packing size". Secondly these STL types can use own allocators which can be different. Thirdly these STL types can be incompatible due to different realizations of STL.
With best wishes,
Vita
|
|
|
|
|
Could you please suggest me how can I make the packing size as same between COM and the DLL?
Kings
|
|
|
|
|
Check if the VS2008 project is 64bit while the VS2013 one is 32bit.
|
|
|
|
|
No, both the DLL and COM are compiled in VS2013 and are compiled as 32 bit binaries.
Kings
|
|
|
|
|
_SECURE_SCL was enabled in COM amounting to 4 byte increase in size. Removing that solved the issue.
Kings
|
|
|
|
|
I write a function like:
<pre lang="c++">
void func1(char chx[], int y)
{
int wsn = 0;
wsn = *(int *) (&chx);
if (wsn == 0) {
...
}
}
Compiler works well, no warning, no error. But when the code is running, seems it get a wild pointer. the code crashed.
|
|
|
|
|
Should be:
void func1(char chx[], int y)
{
int wsn = 0;
wsn = *(int *)chx;
if (wsn == 0) {
...
}
}
The variable name chx is already a pointer to the array, adding the addressof operator creates a pointer to that pointer.
|
|
|
|
|
Thanks, but I tested, &chx = chx.
|
|
|
|
|
No it doesn't. I have no idea how you tested this but it is not correct. Build the following, step through it with your debugger and you will see that they are different.
int* pAddressOf = (int *) (&chx);
int* pNormal = (int *)(chx);
|
|
|
|
|
I tested in Visual studio IDE.
char s1[] = {'H', 'e', 'l', 'l', 'o'};
printf("%lX,%lX",s1,&s1);
And I get same value for s1 and &s1.
|
|
|
|
|
And I tested your code in Visual studio, use Printf("%lX"),
It shows same value too
|
|
|
|
|
That may be true, but sending those values to printf is not the same as casting to pointers. You can confirm it by printing out the values of the two pointers created in my two lines of code.
|
|
|
|
|
|
Windows 7, Visual Studio 2008, C++
I am writing a TCP/IP utility that can be run/used by a non-windowing application. An MFC dialog stands in for the main app during development. The utility runs as a separate thread and communicates with the main app via events and a shared memory structure. Keeping this short:
Is there a mechanism that the TCP utility can use to trigger a method in the MFC?
Details
Presume the dialog has: OnBnClickedShowStatus(…) When the button is clicked this method reads some variables from the shared structure and displays them in the dialog. Can that button, or its essential code, be triggered by an event from the TCP utility?
The alternative is to create a timer and have it run every 300 milliseconds or so. I am hoping for something that is as simple as the timer and causes minimal additional coding in the TCP utility.
Thank you for your time
If you work with telemetry, please check this bulletin board: www.irigbb.com
|
|
|
|
|
A better solution would be to implement the TCP utility as a library that can be called from any other application: windows, non-windows, MFC or not. It could incorporate a call back feature that would allow it to call into the controlling app whenever necessary.
|
|
|
|
|
I don't have any idea of how to do that, but it sounds like a good concept. I did some searching and will look into that.
Still, finding this particular concept of having the thread call into the controlling app may be a bit difficult to discover. Can you give me a few words or a link that discusses that in particular?
Thank you for your time
If you work with telemetry, please check this bulletin board: www.irigbb.com
modified 7-Sep-14 11:15am.
|
|
|
|
|
Export an API from the library that takes a function pointer as an argument. Then use this API from the main program to pass a function pointer into the library so it can call back to the main program.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I am having a bit of trouble with that concept. I am currently writing and testing this utility, a TCP/IP class that is run under a thread separate from the main app. The main app instantiates a class call C_Log_Writer to write data to a log file. Main handed a pointer to C_Log_Writer to the thread and it tried to write some data to the log. That crashed the app repeatedly. The prompted the conclusion that since they are in separate threads each with its own execution pointer, that was not a good idea.
Creating a new instance of C_Log_Writer for the thread resolved the problem. There are two log files, but that's okay. That makes me concerned that calling a function across a thread boundary might be a problem.
That said:
When you write: Export an API from the library, I take that to mean export a function from the TCP utility. Do I follow you correctly?
Thank you for your time
If you work with telemetry, please check this bulletin board: www.irigbb.com
|
|
|
|
|
1. Yes, export a function from the utility
2. About the crashing when passing a pointer to your log class: Where did it crash? Can you pinpoint that? It might have something to do with the TCP utility using a different heap from the main exe.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
