|
IMO depends on the situation. eg: if you have lots of string resources and you need to reset its value it would be a good thing to create all of them consecutively to permit looping from the base one to the last just incresing a counter.
Marc Soleda
... she said you are the perfect stranger she said baby let's keep it like this... Tunnel of Love, Dire Straits.
|
|
|
|
|
nice stuff guys.. it seems that i'd use both the ways according to the need..
thank u so much 
regards,
Rookie
Installing MFC...2% complete.
|
|
|
|
|
Hi,
Well you could use either method is correct however, using m_Control has a slight overhead. The reason is that m_Controls are MFC controls while the form has windows controls. So when the form is instantiated the MFC code kicks in and creates the m_Controls. I would prefer this method if I have a lot of interaction with the controls. However if I dont have to interact with the controls or have only to interact with them one time then it is better to use the GetDlgItem method.
Prady
|
|
|
|
|
Overhead you say?
If you use the other method for a lot of controls you typically use not so much (controls in option dialogs for exemple), you create more unnaccesary overhead using more code to initialze and use the controls.
All the unaccessary error checks, function calls are also overhead. The initialization done by MFC is behind the scenes and in GUI applications, the overhead added by MFC doesn't matter very much. So why go through all the fuss of writing pure API code with all the trouble it brings when you can do without?
IMHO, one should write as few lines of Win32 API code for the GUI when he / she uses MFC. This is not only for consistancy, but also saves a lot of troubles.
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
True, but you did not read my post. I said only if you wanted to do one or two interactions with the control you could use GetDlgIt.. fn.
Prady
|
|
|
|
|
If you realize that only 10% of your code is used 90% of the time leaves you 90% of your code that is used almost never. Believing this, most of your controls are almost never used. If I would use your method and write GetDlgItem() code, I would be better off writing pure C windows applications, simply because it would make more sense.
The control variable method on the contrary, fits perfectly in the MFC. Thats one part of the MFC that is specially designed that way, jsut because you don't have to use GetDlgItem() anyore!
Why would you use MFC in the first place if you bypass all the fancy stuff it was designed for?
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
|
There may be times when you create controls dynamically then GetDlgItem() is usually easier, otherwise m_Control makes for clearer and more compact code.
Elaine ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
The tigress is here
|
|
|
|
|
I want to start with audio programming and want to know the advantages and disadvantages of using DirectSound and of the Windows SDK audio functions (waveIn and waveOut).
Which is better to handle? Which is faster or more powerfull? Which is better to use?
Thanks for helping
Heiko Voss
|
|
|
|
|
Basically Win32 API also very good to use i found Direct Sound is more complex.
And within Win32 u can manage all the audio Signal properties i,e Sampling, Mono or stereo. Data rate call back etc....
Anil Kumar
|
|
|
|
|
DirectSound is faster and mroe Powerful. waveOut is better to use.
It all depends on what you want to do. What do you want to do?
Pandoras Gift #44: Hope. The one that keeps you on suffering.
aber.. "Wie gesagt, der Scheiss is' Therapie"
boost your code || Fold With Us! || sighist | doxygen
|
|
|
|
|
I want to do ALL 
Record, play, save as WAV and read WAV. Perhaps some processing.
But my actual task is a full duplex application. I tried the FullDuplex example of DirectX SDK (9.0c) and got a latency of nearly a second!!!
I build also a full duplex application with Win API and got a latency in "normal" range (smaller than 0.1s). I was surprised and posted my question.
If DirectX is more powerfull i want to use it. But what's with this really long latency time? I tried the original example!
Greetings
Heiko
|
|
|
|
|
Hey Heiko,
Can you exactly tell me how do you measure the Latency.
It will be helpfull for me.
Regards
Anil Kumar
|
|
|
|
|
Hi Anil,
I speak in a microphone, the signal is going through the application, send to the output and i listen to it with headphones. The time between talking and hearing is my latency.
It's not really a scientific method but for a first test it's ok. And the difference between the two used samples is clearly to hear.
Later i will measure the latency between input and output with a more exact method.
Greetings
Heiko
|
|
|
|
|
I don't know much about the original example
With DS, I have a playback/capture offset of about 500 samples in a release build (this includes codec delay, but not playback latency - but that's a few ms)
There might be some processing in the default sample (e.g. capturing 1 s of data, processing it, and playing it back), some bad SC config or whatever.
DirectSound shines for playback when you are mixing multiple buffers, do 3D sound effects, etc. Capture is a bit neglected in the DirectSound API.
I am not sure if the waveOut API supports more than the 2 channels / 48kHz API - check that if you need it!
OTOH, the waveI/O is extremely simple compared to DirectSound.
In DirectSound, you cannot get robust duplex without running your own threads. You need some basic understanding of COM, and you have gazillions of soundcard configuraiton options, which you will spend a lot of frustrating time fine-tuning them.
Pandoras Gift #44: Hope. The one that keeps you on suffering.
aber.. "Wie gesagt, der Scheiss is' Therapie"
boost your code || Fold With Us! || sighist | doxygen
|
|
|
|
|
Hi,
Is it possible to use C# as a scripting language in a MFC app?
Any input is welcome.
Thanks
Ning
|
|
|
|
|
Hello Friends
I am developing an application in VC++, but i have stuck at a place
The problem is i want to replace 4-digit value with another 4-digit value
in an exe.
When i am trying to read that 4-digit value from an Exe it is done successfully
but when i am trying to replace that 4-digit value the exe crashes,and exe size comes back to 0 bytes.
Can anybody help with this.
VC++
|
|
|
|
|
any chance to see you code from which you achieve this ?
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
Are you writing in your own executable? This is not recommanded. Assembly programmers used to write self modifiable code, but thank god for the protected mode!
If you are doing just this, use the registry to store your values.
If you try to write to another executable file, please show us your writing code.
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
Hello
i am not writing on the same exe ,i want to make this entry in a new exe
i can successfully read from the exe but it fails to write on the same location
strcpy(RemoteFile,m_DirPath);
strcat(RemoteFile,"\\GoldfishClient.exe");
fstream fileHandle;
fileHandle.open(RemoteFile,ios::in|ios::out);
LONG lActual,loffset=104063;
fileHandle.seekp(loffset,ios::beg);
char testch[4];
fileHandle.read(testch,4);
testch[0]='1';
testch[1]='0';
testch[2]='2';
testch[3]='5';
fileHandle.seekg(loffset);
fileHandle.write(testch,4);
fileHandle.flush();
fileHandle.close();
|
|
|
|
|
Hello,
Sorry that I post this so late, but you didn't reply to my post, so I didn't see this one before.
I see your problem, you use the fstream::seekg() function to position the file pointer to write to the file. The problem here is that fstream object have 2 pointers one for reading and one for writing. Since fstream is derived from basic_iostream and that in turn is derived from basic_istream and basic_ostream. They all have functions to position the pointer in the buffer. One for reading and one for writing. They couldn't give the same name to those functions, so they placed a suffix g for get and p for put after the functions. So your code would look like the following:
<br />
strcpy(RemoteFile,m_DirPath);<br />
strcat(RemoteFile,"\\GoldfishClient.exe");<br />
fstream fileHandle;<br />
fileHandle.open(RemoteFile,ios::in|ios::out);<br />
LONG lActual,loffset=104063;<br />
fileHandle.seekg(loffset,ios::beg);<br />
char testch[4];<br />
fileHandle.read(testch,4);<br />
testch[0]='1';<br />
testch[1]='0';<br />
testch[2]='2';<br />
testch[3]='5';<br />
fileHandle.seekp(loffset, ios::beg); <br />
fileHandle.write(testch,4);<br />
fileHandle.flush();<br />
fileHandle.close();<br />
This should help you
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
Hi all, I am calling the GetConsoleWindow function, and according to the MSDN I defined the _WIN32_WINNT 0x0500, but i still get the error C2065 "GetConsoleWindow: Undeclared identifier", How can I fix it, plz help.
|
|
|
|
|
Have u included Windows.h ?
Steve Mayfield: "Coding in VB is like riding a tricycle...once you figured out how to peddle, its really hard to fall off."
My Articles
|
|
|
|
|
yes i did, but it still happen, i compiled it under Windows 2000 Professional.
|
|
|
|
|
Hi
I am using fstream class for file I/O operations. When I upgrade my compiler to VC++ 7.1 from VC 6.0 I get compilation error on fstream related operation.
With 6.0 I was using include fstream.h, while with VC++ 7.1 I am using fstream as fstream.h is no longer supported with 7.1.
Sample Code:
filebuf *pFb = Fb.open ("abc", ios::out, filebuf::sh_write);
Error:
sh_write is not a member of 'std::basic_filebuf<_Elem,_Traits>'
Regards
Devendra
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
