|
Being signed or unsigned has little to do with the problem other than preventing him from calling C-string routines. You can easily place a 0 in a buffer of characters (I've been doing it for years). You just have to be careful which routines and containers you use.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
char(acter) = byte = 8 bits
Er zit een korstje op mijn aars.
|
|
|
|
|
Abebe wrote:
char(acter) = byte = 8 bits
Yeap, you are right! I Will discuss with about that later! Stay Tuned
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
Hi
There is no need for any head ache there.
Just take it this way and pump it through your serial port. It works !!
char * buff = new char[3];<br />
buff[1] = 0x01;<br />
buff[2] = 0x00;<br />
buff[3] = 0x02;<br />
if(buff)<br />
delete [] buff;
Regards
Sreekanth Muralidharan,
Corporate Systems Consultant [Embedded Systems],
INDIA
|
|
|
|
|
Hi Abebe,
Thanks for your reply.
I know a character is only 1 byte which cannot be accomodated there.
My problem is not that..
See this:
char * buff = new char[5];<br />
buff[0] = 'a';<br />
buff[1] = '\0';
buff[3] = 'c';<br />
printf(buff);
Else any other way to send a 00 through a serial port. I use a serial port monitor to monitor the data from the port. Suppose I have sent this string:
"Code Project"
The monitor should display 00.
Regards
Sreekanth Muralidharan,
Corporate Systems Consultant [Embedded Systems],
INDIA
|
|
|
|
|
'\0' is a terminator not space or EOL.
It is important to keep your terms clear as it leads to more confusion as your work becomes more complex.
If you have a terminator as a member then you must treat it as an array and control the length elsewhere, you cannot use normal string handling functions.
Elaine ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
The tigress is here 
|
|
|
|
|
To acess a control...
* using GetDlgItem(IDC_) is better or using the control Variable m_Control is better?
regards,
Rookie
|
|
|
|
|
Hello,
It's just a matter of preference. Using the GetDlgItem() involves a lot of ugly typecasts and unnassecary code. Using the m_Control variable looks much more cleaner. I even think that it is slightly faster than the other method, since you already have a CWnd derived object. (Unless you use primitive types or CStrings for managing dialog data.)
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
thanx bob 
regards,
Rookie
Installing MFC...2% complete.
|
|
|
|
|
You're welcome
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
as bob said, using GetDlgItem() each time you want to access a control add several function calls to your code that you could avoid.
but of course, using a member variable to store the CWnd* of a control is working unless you initialize it correctly (with... GetDlgItem() )
what i used to do personnaly is having a set of m_p???????? variables in my Dialog classes, that i initialize into OnInitDialog() with a set of GetDlgItem() calls...
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
toxcct wrote:
what i used to do personnaly is having a set of m_p???????? variables in my Dialog classes, that i initialize into OnInitDialog() with a set of GetDlgItem() calls...
You do realize that the return value of GetDlgItem() points to a temporary CWnd object that is only valid for the current Windows message? This means you can't save that return value and use it later, since CWnd object may no longer exist.
Software Zen: delete this;
|
|
|
|
|
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
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
