|
what are you calling .NET ?
the development environment (Visual Studio .NET 2003) or the .NET framework ?
i mean, is you dll a managed code library, or native ?
|
|
|
|
|
hi Toxcct,
The DLL is a C++ DLL, and .NET is a C# application.
since i am not aware of managed code library, or native i cannot answer that.
Thanks in advance
Abhi Lahare
|
|
|
|
|
wow, i think you have some lacks i have to fill here.
C++ is only a language. you can program for different target system with C++, like Windows, Unix, Mac... the difference (if you code is well written and portable) will not be in your sources, but in the binary the compiler/linker generates. this binary is commonly called "native", as it directly contain the microprocessor instructions.
by opposition to native code, .NET (i mean, the .NET framework) is a framework like the Java Virtual Machine which - is supposed to - allow the code compiled to work on every plateform. this implies the compiler generate an intermediate language (MSIL for .NET, ByteCode for JavaVM). this intermediate language is called Managed code because its execution is done only within the .NET framework.
some languages (like C#) generate only managed code. but C++ can do both.
if you program with Win32/MFC/ATL/WTL libraries, then the code will generate some native instructions. but the Microsoft C++ compiler can also generate "Managed C++" also called (C++/CLI) for the .NET framework.
then, to come back to your problem, when you say the DLL is a C++ DLL, you don't explain much.
also, saying that .NET is a C# application does no only explain nothing, but is wrong in the facts.
now, knowing these things, can you please explain what problem you encounter, and what you want to do ?
|
|
|
|
|
hi Toxctt,
Or do i have to set the debug path and trace through the dll function? but i don't want to do that.
Thanks in advance,
Abhi Lahare
|
|
|
|
|
How are you trying to debug your dll ?
Do you know that, in VC++, you can debug a dll very simply: you can choose an executable for debug session (you have to look in the project properties of your dll project). Then, you simply choose which executble will be started to debug your dll. When a function of your dll is called, you can step inside it (like a normal executable).
|
|
|
|
|
Or an easier way: open your dll project and press F5 (like if you want to start debugging). A dialog will appear in which you can select the executable to will be started (and which of course need to use your dll). Select the executable of your other project.
|
|
|
|
|
It's a COM dll ? you can make a reference in your C# project and use it directly in your code. It automatically makes use of the interop service.
<marquee scrollamount="1" scrolldelay="1" direction="up" height="10" step="1">--[ ]--
[My Current Status]
I dont know why the hell the script for voting 5 is disabled only for me??
|
|
|
|
|
When a program executes some functions(eg in a for loop), all the buttons in the dialog won't work. Is is possible to close that program or stop it it while it is still in a 'for' loop? Something like Ctrl C in Unix? Thanks.
|
|
|
|
|
if u have another thread, in that process u can call ExitProcess() from that thread and exit the application.
nave
|
|
|
|
|
cv_k3n wrote: Is is possible to close that program or stop it it while it is still in a 'for' loop?
It depends of your definition of 'closing' . There is always the option of killing it through the task manager but I don't know if this is what you are looking for.
Anyway, it is in general a very bad idea to have long loops in the same thread as the GUI. A better solution would be to start a thread in background that will take care of this loop. In that case, you won't freeze your GUI.
|
|
|
|
|
Thanks.. I looked up on how to use a thread in my program and i found this article:
To the class (in this example, a CView-derived class), add the following declarations:
<br />
static UINT run(LPVOID p);<br />
void run();<br />
volatile BOOL running;<br />
To start a thread, your handler does
<br />
void CMyView::doInvert()<br />
{<br />
running = TRUE;<br />
AfxBeginThread(run, this);<br />
}<br />
<br />
UINT CMyView::run(LPVOID p)<br />
{<br />
CMyView * me = (CMyView *)p;<br />
me->run();<br />
return 0;<br />
}<br />
<br />
void CMyView::run()<br />
{<br />
for(int x=y = 0; running && y < image.height; y++)<br />
for(int x = 0; running && x < image.width; x++)<br />
changePixel(x, y);<br />
running = FALSE;<br />
}<br />
The command to stop the thread is very simple:
<br />
void CMyView::OnStop()<br />
{<br />
running = FALSE;<br />
}
I've tried this out but whenever i run my function, a 'Debug Assertion Failed' dialog pops up. I don't understand why. BTW, i'm working on a dialog based application and i realised the example above is for an SDI application. But it should still work right?
|
|
|
|
|
What's you dialog class' name?
<marquee scrollamount="1" scrolldelay="1" direction="up" height="10" step="1">--[ ]--
[My Current Status]
I dont know why the hell the script for voting 5 is disabled only for me??
|
|
|
|
|
My dialog class' name is CSimulationDlg. So i replaced all of the CMyView with that. IS that right?
|
|
|
|
|
cv_k3n wrote: Is is possible to close that program or stop it it while it is still in a 'for' loop?
Are you sure you want to do this? What if the application is in the middle of something important (e.g., writing to the disk)?
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
if I do:
<br />
#DEFINE BUFF_SIZE 0x400;
ULONG *buff = null, numBytesRead = 0;<br />
buff = new ULONG[11250000];
Handle hdl = INVALID_HANDLE_VALUE;<br />
...<br />
while(...){<br />
ReadFile(hndlPciAlt, buff, BUFF_SIZE, numBytesRead, NULL);
...<br />
}<br />
<br />
Where:<br />
BOOl ReadFile(<br />
HANDLE hFile,<br />
LPVOID lpBuffer,<br />
DWORD nNumberOfBytesToRead,<br />
LPDWORD lpNumberOfBytesRead,<br />
LPOVERLAPPED lpOverlapped<br />
);<br />
is a windows function.<br />
Questions:
1) So, I pass in the *buff. ReadFile() will dump the data there.
If I do another ReadFile() will it append to the end of *buff?
OR, will it overlap the data already in the *buff, if so,
how do I make subsequent writes into *buff append to the end of it?
2) Does ReadFile() automatically stick each 32-bit word out of the 1024 words it reads into each of the individual array slot of buff? So, that there will be a total of 256 array elements after the 1st call to ReadFile().
3) If "DWORD nNumberOfBytesToRead" is the min number of bytes to read, will
ReadFile() read more bytes if they are available? If so, how can you
limit ReadFile to only read the specified number of bytes?
Kitty5
|
|
|
|
|
kitty5 wrote: 1) So, I pass in the *buff. ReadFile() will dump the data there.
If I do another ReadFile() will it append to the end of *buff?
OR, will it overlap the data already in the *buff, if so,
how do I make subsequent writes into *buff append to the end of it?
No, it copy the data at the address you pass to the function, which is the begining of your array. If you want to append it, you'll have to increment the address (something like buff+Offset). But warning !! As your buffer is a ULONG, it means that a single increment will point to the next ULONG (so 4 bytes further). It is not a good idea in this case to use a pointer to ULONG, use a pointer to UCHAR instead so you don't have to cast the pointer to a char area in order to be able to increment only one byte.
Remember that ReadFile read data un bytes, so it can read only 3 bytes for example (and there you got the problem because it is not a multiple of 4)
kitty5 wrote: 2) Does ReadFile() automatically stick each 32-bit word out of the 1024 words it reads into each of the individual array slot of buff? So, that there will be a total of 256 array elements after the 1st call to ReadFile().
ReadFile is supposed to read bytes, so it has nothing to do with 32-bit words.
kitty5 wrote: 3) If "DWORD nNumberOfBytesToRead" is the min number of bytes to read, will
ReadFile() read more bytes if they are available? If so, how can you
limit ReadFile to only read the specified number of bytes?
No, it is the number of bytes to read. The function won't read more bytes (yup, I checked MSDN and that's strange they say minimum instead of maximum )
|
|
|
|
|
damn. You beat me to it
Cheers
Steen.
"Are you gonna check your makeup when you're done whining?" John Simmons, 05/31/2006
|
|
|
|
|
Cedric Moonen wrote: If you want to append it, you'll have to increment the address (something like buff+Offset). But warning !! As your buffer is a ULONG, it means that a single increment will point to the next ULONG (so 4 bytes further). It is not a good idea in this case to use a pointer to ULONG, use a pointer to UCHAR instead so you don't have to cast the pointer to a char area in order to be able to increment only one byte.
Ok so I do:
<br />
#define BUFF_SIZE = 0X400;<br />
ULONG numBytesRead = 0, offset = 0;<br />
UCHAR *buff = null;<br />
buff = new UCHAR[45000000];<br />
while(...)<br />
{<br />
ReadFile(hndlPciAlt, buff, BUFF_SIZE, numBytesRead, NULL);
}<br />
how would I pass the offsetted buff address in the while loop?
(i.e. buff + numBytesRead)
Since, every time I got into the loop it will be buff then buff + numBytesRead then buff + numBytesRead + numBytesRead, ... etc.
can I:
<br />
#define BUFF_SIZE = 0X400;<br />
ULONG numBytesRead = 0, offset = 0;<br />
UCHAR *buff = null;<br />
buff = new UCHAR[45000000];<br />
while(...)<br />
{<br />
ReadFile(hndlPciAlt, (buff + offset), BUFF_SIZE, numBytesRead, NULL);
offset += numBytesRead;<br />
}<br />
Is (buff + offset) the proper syntax to increment the address of buff?
Thanks.
Kitty5
|
|
|
|
|
kitty5 wrote: Is (buff + offset) the proper syntax to increment the address of buff?
Yes, that's how you need to do it. And your code snippet is correct also. You can stop the loop when offset == the number of bytes you need to read.
|
|
|
|
|
Thank you so much for helping me clear this all up!
Things are so much clearer after a couple cups of coffee ....
Kitty5
|
|
|
|
|
1) it will overwrite. To append, use lpNumberOfBytesRead to offset the buffer pointer in subsequent calls to ReadFile.
2) Yes. lpBuffer is a void pointer, so it will be handled as an array of bytes. If the endian-ness of the words you read is correct you will get an array of 256 ULONGS when you read 1024 bytes.
3) It will read exactly nNumberOfBytesToRead. ReadFile will wait until it has read these bytes (assuming you don't use overlapped I/O, but that's another story), but it will not read more than this number of bytes (this would also wrech havoc on your buffer)
Cheers
Steen.
"Are you gonna check your makeup when you're done whining?" John Simmons, 05/31/2006
|
|
|
|
|
Steen Krogsgaard wrote: ReadFile will wait until it has read these bytes (assuming you don't use overlapped I/O, but that's another story),
Not necessarily. For example, using a serial port you can configure it with some specific timeouts and it often happens that the read function will time out before having read all the data. But of course, you can configure it with an infinite timeout also (and in that case, it will follow what you described).
|
|
|
|
|
Right. In any case, it won't read more than the number of bytes specified.
Will ReadFile return true if there is a timeout?
Cheers
Steen.
"Are you gonna check your makeup when you're done whining?" John Simmons, 05/31/2006
|
|
|
|
|
Steen Krogsgaard wrote: Will ReadFile return true if there is a timeout?
Yes, it returns true only if an error occurs. A timeout in that case is not an error.
|
|
|
|
|
kitty5 wrote: buff = new ULONG[11250000]; //total of 11,250,000 32-bit words
Just an FYI: Avoid declaring such large chucks of memory (be it stack or heap). While this array alone (which will be about 45 MB) won't cripple your system, imagine declaring 10 or 20 of them (throughout your application). Next thing you know, your application requires a full GB of RAM by itself (not good!). If possible, you should try to read a large file in smaller chunks, process the data, and read the next chuck.
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
|
|
|
|
|