C / C++ / MFC

Sunil Bhaskar18-Oct-07 23:35

Sunil Bhaskar

18-Oct-07 23:35

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.

ThatsAlok19-Oct-07 0:38

ThatsAlok

19-Oct-07 0:38

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

Nelek29-Oct-07 21:53

29-Oct-07 21:53

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

Wink | ;)

JudyL_MD19-Oct-07 2:38

19-Oct-07 2:38

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.

Reading an inf file

Suneet.0318-Oct-07 23:07

Suneet.03

18-Oct-07 23:07

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?

Re: Reading an inf file

Nelek18-Oct-07 23:30

18-Oct-07 23:30

I think it depends on what a format it has, Binary - Text and so on..

but it should be similar about the concept.

Re: Reading an inf file

JudyL_MD19-Oct-07 2:39

19-Oct-07 2:39

Nelek wrote:
I think it depends on what a format it has, Binary - Text and so on..

FYI, INF files are always text

Judy

Re: Reading an inf file

JudyL_MD19-Oct-07 2:40

About EN_KILLFOCUS or EN_SETFOCUS in WIN32 API

19-Oct-07 2:40

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

hkim_zoro18-Oct-07 22:16

hkim_zoro

18-Oct-07 22:16

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....

Nelek18-Oct-07 22:37

18-Oct-07 22:37

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;
}

//This is the message that has a related HotKey
void CMyView::OnEnterKeyPressed() 
{
	if (m_bEditFocused )
		//Get and validate what in the edit is
	else if (!m_bEditFocused && m_bOtherBool)
		//Do another thing
	else
		//Close this window
	
	return;
}

I hope it helps

hkim_zoro18-Oct-07 23:18

hkim_zoro

18-Oct-07 23:18

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

Nelek18-Oct-07 23:29

18-Oct-07 23:29

take a look in the message below Wink | ;)

you can combine his code with my idea Roll eyes | :rolleyes:

Nishad S18-Oct-07 23:07

Nishad S

18-Oct-07 23:07

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 -

How to copy file much faster?

hkim_zoro19-Oct-07 6:12

hkim_zoro

19-Oct-07 6:12

thanks NS17 and Nelek so much specially NS17....
I solve this problem....

kcynic18-Oct-07 22:07

18-Oct-07 22:07

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.

MarkusStr18-Oct-07 22:41

MarkusStr

18-Oct-07 22:41

does your software run under a windows os?
if so why don't you use the copyfile api from kernel32.dll?

cheers

markus

kcynic19-Oct-07 19:59

19-Oct-07 19:59

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)?

Matthew Faithfull18-Oct-07 22:53

Matthew Faithfull

18-Oct-07 22:53

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 WTF | :WTF:

Nothing is exactly what it seems but everything with seems can be unpicked.

kcynic19-Oct-07 20:00

19-Oct-07 20:00

Thank you very much.
I will have a try this way,soon.

JudyL_MD19-Oct-07 2:44

19-Oct-07 2:44

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

Tydia-kun19-Oct-07 3:53

Tydia-kun

19-Oct-07 3:53

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.

JudyL_MD19-Oct-07 4:01

19-Oct-07 4:01

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

Tydia-kun19-Oct-07 4:05

Tydia-kun

19-Oct-07 4:05

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.

kcynic19-Oct-07 20:01