|
I dont know if for that, it will be the same, but I disable usual compiler warnings with
#pragma warning(disable:XXXX)
Hope it helps
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
|
|
|
|
|
Nopes it doesnt work. I have already tried that. In the Linker options, also i tried to add /wd4099 or /ignore:4099..Nothing of them worked.
|
|
|
|
|
Nelek wrote: #pragma warning(disable:XXXX)
you can disable warning .. not error!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
I told it. "usual compiler warnings"
i was referring to the second part of the intial message, not to the liner error
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
|
|
|
|
|
Your 3rd party has provided you with a release-mode lib file. The linker is correctly telling you that it can't find the debugging symbols for the library in question. This means you can't step into it in the debugger (except as assembly code). The warning will not affect your use of the library. You won't get the warnings in your release build.
|
|
|
|
|
Is reading an Inf file same as raeding a normal text file?
If no , then what all has to be done to read an inf file?
|
|
|
|
|
I think it depends on what a format it has, Binary - Text and so on..
but it should be similar about the concept.
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
|
|
|
|
|
Nelek wrote: I think it depends on what a format it has, Binary - Text and so on..
FYI, INF files are always text
Judy
|
|
|
|
|
Suneet.03 wrote: Is reading an Inf file same as raeding a normal text file?
Yes. There are rules governing what is contained within a "valid" INF file, but it is just a text file.
Judy
|
|
|
|
|
Hi everybody!
I am learning WIN32 API. I read in MSDN about this but I can't understand how to use it.
Please show me how to use it by example! or can send me a demo it.
Thanks alot....
|
|
|
|
|
Hi,
for example I used it in my project to select which functionality to use when Enter is pressed. I have a HotKey to open/close windows for parametrization of objects, but I want to have the functionality to accept and check what was written in a edit. So I made:
void CMyView::OnEdit1SetFocus ()
{
m_bEditFocused = TRUE;
return;
}
void CMyView::OnEdit1KillFocus ()
{
m_bEditFocused = FALSE;
return;
}
void CMyView::OnEnterKeyPressed()
{
if (m_bEditFocused )
else if (!m_bEditFocused && m_bOtherBool)
else
return;
}
I hope it helps
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
|
|
|
|
|
thanks for your help
But you're coding in MFC wizard
I'm coding in WIN32 Application, can you show me how to use it on WIN32 Application (C++ only)
Thanks
|
|
|
|
|
take a look in the message below
you can combine his code with my idea
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
|
|
|
|
|
Like this...
LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
switch (message)
{
case WM_COMMAND:
wmId = LOWORD(wParam); // ID of the edit you created
wmEvent = HIWORD(wParam); // Event ID
switch( wmEvent )
{
case EN_SETFOCUS:
// Your code
break;
case EN_KILLFOCUS:
// Your code
break;
}
break;
// Other cases...
default:
return DefWindowProc(hWnd, message, wParam, lParam);
}
return 0;
}
- NS -
|
|
|
|
|
thanks NS17 and Nelek so much specially NS17....
I solve this problem....
|
|
|
|
|
I have to copy files to movable devices using simple file operation such as fread and fwrite in a big loop.
And I found some software do such works more quickly.
I want to know if I used multithread it would be much faster?If it so,multithread would eate much CPU time resource.So,I think it perhaps no good to adding multithread to copy files.
But I also want to know how the softwares can copy more fast?
Thanks.
GOOD LUCK.
|
|
|
|
|
does your software run under a windows os?
if so why don't you use the copyfile api from kernel32.dll?
cheers
markus
|
|
|
|
|
I follow your guide,using CopyFile() first and using C standard io fuctions( using a 512 bytes buffer) at second.The file is 673298KB.The result is:
CopyFile: 73 sec
C Standard: 49 sec
And how it do copying work of kernel32.dll(CopyFile)?
|
|
|
|
|
A friend of mine tried to write the fastest Win32 file copy a few years ago. He used 2 threads and 2 32K buffers (read one then switch and read other while writing the one ) and the Win32 API calls as opposed to the C Library file functions. I don't know if it was the best but it was 4 times faster than using the C library calls, mostly because they use small buffers, and 10 times faster than using Explorer on large files
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Thank you very much.
I will have a try this way,soon.
|
|
|
|
|
If you're copying multiple files, you could spawn a thread for each file to copy so that, with respect to your program, the copying is taking place in parallel.
Judy
|
|
|
|
|
There's just one problem here. First and foremost, it depends on WHERE and TO you copy. The HD is far slower than the processor and memory, so the bottleneck is THERE.
Copying two files (or more) from the same HD and to the same HD, then it will slow down the operation at least 2x.
If the source and destination is different for each file, then yes, you can use threads. Otherwise you're just slowing down things.
|
|
|
|
|
Depends on how the program is written. If it is a series of CopyFile, CopyFile, CopyFile functions calls, I agree 100% with you. If however, the OP is doing things between each CopyFile call, this may speed his process up by _always_ having data at the HD level waiting to be written while the OPs other code is executing.
This is the kind of thing where you need to code it different ways and measure each ways performance in different source files / target disks scenarios. Sometimes you just have to say "sorry, hard drives are slow - you've just got to wait." That's why they made a wait cursor.
Judy
|
|
|
|
|
Ah, of course. You're absolutely right. One thread can take care of copying and one thread can take care of everything else that needs to be done meanwhile... But then again, you don't need to use synchronus file copy either... You can asynchronous. While the file is copying, the program can do other stuff like readying more data copy or something, as long as it doesn't read or write to the same HD, since that would slow things down.
|
|
|
|
|
In fact,the biggest problem is how to copy large file faster?
|
|
|
|