|
Use GetTabRect to get the default bounds of a tab. You also need to override OnFontChanged to get the custom-draw tabs to report their size correctly; see for example this comment[^].
|
|
|
|
|
Hi,
Umm I have used the Serial Port class quite a bit never had any problems with it, but I have had some problems with the later boards we have produced and found I have to use a cludgy method shown below:
int i, j;
byte[] bytes = System.Text.Encoding.ASCII.GetBytes(rtbOutgoing.Text);
j = rtbOutgoing.Text.Length;
for (i = 0; i < j; i++)
{
binaryWriter1.Write(bytes[i]);
}
rtbOutgoing.Text = "";
I have used it with no problems but a colleague got some of source hacked it around and said "Your code doesn't work!" in looking at he was doing ComPort.Write("saasa");
where as I do:
for (int i = 0; i < Length; i++)
{
CommandSent = Command1.Substring(j, 1);
myComPort.Write(CommandSent);
richTextBox1.Text += CommandSent;
j++;
}
myComPort.Write("\r\n");
He now blames his code not working and mine working on Windows or a bug in the Serial Port Write Method. My thinking was ComPort.Write("sasa") sends the string as a whole where my method splits up the string to individual characters. So is it Windows and the Serial Port Class at fault or the boards serial reading function. Interested in any similar experience any one has had.
Glenn
|
|
|
|
|
The thread a couple below this one may be of interest to you.
Dropping characters when sending as a whole but working one at a time sounds like you might have the baud rate set too high for the device with which you're trying to communicate.
|
|
|
|
|
Hi,
Yeah I did read the thread below but it didn't really answer my question of why does my method work (by splitting up the string and sending seperatly the characters) and the straight write method doesn't work. The baudrate is high but is the same I checked it before I wrote the code! (I'm an old hand at getting Windows to talk to the outside world).
Thanks for the reply though.
|
|
|
|
|
I haven't worked with serial ports in years, but this sounds a lot like either a handshaking problem, or an undersized receive buffer on the target system. Have you tried playing with these values?
Will Rogers never met me.
|
|
|
|
|
Ohh yeah, tried and failed the buffer has not changed from when it worked, what is going on, same means Write but if I split it with a substring it works if not FAIL! ??
|
|
|
|
|
glennPattonWork wrote: a colleague got some of source hacked it around
That is usually the problem. You may also note that his code looks like it is sending characters direct, which probably means they are still Unicode (i.e. 16 bits) whereas they need to be ASCII (8 bits).
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
Actually the text-oriented methods apply an encoding, that is what the SerialPort.Encoding property is for. However, while the MSDN doc states it defaults at Encoding.ASCII, that is not in accordance with my experience; and that is why I either set the encoding explicitly, or, preferrably, transmit byte arrays, not char arrays or strings.
|
|
|
|
|
The sample that OP said did not work, didn't have any specific encoding, hence my comment.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
I have been using serial ports quite a lot over the years, and I am unaware of any bug in Windows serial ports that could be relevant here.
Anyway, all your code snippets are doing is slow down the communication in different ways.
In my books, when a simple SerialPort.Write(byteArray, startIndex, length) doesn't work properly, then it is probably one of these two things:
- your serial bytes are bumping into each other due to a bit pattern format error (most common would be sending with just the one stop bit whereas the receiver may require 1.5 or 2)
- the receiver is badly designed and has a timing constraint, e.g. it needs more time to process a byte than it takes the byte to travel the serial line. Reducing the baud rate could solve this.
There are a lot of issues with serially receiving data, especially when data rates are high, and both throughput and latency are of high importance. Then Windows is tricky, as are many other systems. However, transmitting should never pose any problems.
Suggestion: try at lower baud rates first. I tend to develop comm protocols at 9600 Bd until they work perfectly, onlyu then turn up the baud rate.
Some random remarks:
- base-board serial ports tend to have good timing behavior; remote ports (such as USB serial cables, or Ethernet serial ports) tend to suffer delays and packetizing phenomena as they try not to send a whole package for each and every byte you want sent. So make sure to log the hardware aspects too when observing system behavior.
- make sure the GROUND signal in your serial cable is connected properly at both ends; a two-wire serial cable should not work, but it may occasionally work, be it intermittently.
- Windows knows how to buffer and dataflow the outgoing data, just like it does the incoming data; if you're unaware of this, it may continue for a while; and then stop sending data because the other side is "actively refusing to accept any more data". This depends on your handshake settings.
- make sure to setup and open the serial port once, then wait a while before exercising anything. Do not open and close all the time (a serial port is not a database!). That is recommended in general; and in particular in Windows where a fast close-open sequence is known to fail often (and that is a documented "feature").
|
|
|
|
|
"There are a lot of issues with serially receiving data, especially when data rates are high..." has got to be the understatement of the year! 
I worked for 7 years at a hardware store running 50 serial terminals on one IBM desktop PC. Some of the runs were 300' long, via surplus telephone cable that the owner found and installed before I went to work there. It was my unpleasant job to maintain the system and keep it working, despite the fact that it broke every RS232 standard ever published. What a nightmare!
Will Rogers never met me.
|
|
|
|
|
Roger Wright wrote: "There are a lot of issues ..." has got to be the understatement of the year!
I can't see an understatement here.
Now if I had said: "occasionally a thing or two could go wrong..." that would be an understatement.
Roger Wright wrote: Some of the runs were 300' long
Anything can fail when you use it outside the specified conditions. RS232C is spec'd at a maximum of 15m IIRC. Any failure under unsupported conditions should not reflect on the vendors of the subsystems used (PC, Windows, ...).
|
|
|
|
|
It's (in the one revision I'm most used to) 50' at 9600 bps. We used 300' at 19.2 kbps. But I kept the damned thing working for years, while secretly undermining the boss and installing Cat5 in my spare time.
Will Rogers never met me.
|
|
|
|
|
Undermine with cable, I like that.
|
|
|
|
|
Thats good no bug in Serial Port class, I think the problem is down too small a buffer in the Controller, like I thought. Now all I have to ask is how bad is my hack to get around it, my thinking was a bit inefficient but.....
modified 4-Nov-11 5:12am.
|
|
|
|
|
If the board was my design, I would have started slow. Colleague designed it and the phrase used was "well that is done it works with HyperTerm". Told to "learn how to do comms properly", I don't think that helps at all. My knowledge of Serial Port Class comes from Jan Axelsons book & MSDN I used MSComm & MHComm before that!
modified 4-Nov-11 7:01am.
|
|
|
|
|
Hi,
I'm trying to write a function in a c++/cli dll that will receive an empty array from C# (float[] a), use gcnew to allocate the array and then I need to use the array in C#. I tried regular transfer but after the function returns the array is still null in C#. Current trial is:
C#:
float[] a;
InitArray(a);
c++/cli:
void CLIClass::InitArray(array<float>^ a)
{
a = gcnew array<float>(100);
for(int i=0; i<100; i++)
a[i] = 10.0F;
}
I do not wish to return the array as a return value (the function should actually return 3 arrays).
Thanks!
|
|
|
|
|
Does passing a tracking reference work?
void CLIClass::InitArray(array<float>^% a)
Mark Salsbery
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Yes, all I was missing is the % operator. Thanks!
|
|
|
|
|
I gave him a 5. It's nice when you do that when people help you out here.
|
|
|
|
|
|
your C# code should use the out or ref keyword:
float[] a;
InitArray(out a);
float[] a=null;
InitArray(ref a);
ref would fail here as long as a isn't initialized.
Without ref/out your callee can modify the array content, however it can't replace the array.
|
|
|
|
|
******************************************************
the code works as follows.
If you chose them all, works fine, but not all, of one or more than one election, or choose not at all, the program does not work
stands in this code.
if (dr.Cells [0]. Value.ToString ()! = "true")
How do we solve the problem?
List<int> TestId = new List<int>();
for (int i = 0; i < dataGridView2.RowCount; i++)
{
foreach (DataGridViewRow dr in dataGridView2.Rows)
{
if (dr.Cells[0].Value.ToString() != "true")
{
TestId.Add(Convert.ToInt32(dr.Cells[2].Value.ToString()));
}
}
}
if (baglanti.State == ConnectionState.Closed)
baglanti.Open();
komut.Connection = baglanti;
for (int i = 0; i < TestId.Count; i++)
{
komut.CommandText = "update HASTA_SONUCLARI SET ONAYLANDI='" + true + "' where PROTOKOL_NO='" + TextBox6.Text + "' and TEST_NO='" + TestId + "'";
komut.ExecuteNonQuery();
}
MessageBox.Show("Onaylandı.");
baglanti.Close();
}
}
|
|
|
|
|
what a horrible message. The code isn't formatted properly, there are plenty of unjustified ToString() calls and string comparisons, and "doesn't work" doesn't even start to explain what the problem is.
Please read the forum guidelines ("How to get an answer to your question" at the top of this forum), and see how others post their message. Good questions yield good answers here.
|
|
|
|
|
Actually I wanted to report this message to the Hall of Shame.
Look:
- You run in nested loops several times through your DataGridView
for (int i = 0; i < dataGridView2.RowCount; i++) {
foreach (DataGridViewRow dr in dataGridView2.Rows)
- You compare boolean values as a strings - it will fail with localized versions!
if (dr.Cells[0].Value.ToString() != "true")
By the way, I posted such a coding horror some time ago. It was very hard to find out why the program strangely failed on that one computer.
- You create SQL queries by adding strings together. TextBox6 might contain bad code (SQL injection attack). Use parameterized queries instead.
- You add an array of numbers where one number is required:
and TEST_NO='" + TestId + "'";
instead of
and TEST_NO='" + TestId[i] + "'";
And that looks like using strings instead of numbers...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
