|
Lots of suggestions here[^].
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
WPF provides better styling support for controls.
|
|
|
|
|
Some replies here have assumed you are describing "theming:" (even though you never used that word, yourself): where theming means you want to create a control from which you could create any number of different look-and-feel variations from the base control.
Looking at your question: and the example on the web page you linked to: are you really asking how to create a custom-themed control, or are you just asking how to make a drop-down that looks and behaves exactly like the one on that web-page ?
Please clarify exactly what "style" and "styling" mean to you here.
best, Bill
"Last year I went fishing with Salvador Dali. He was using a dotted
line. He caught every other fish." Steven Wright
|
|
|
|
|
I have created a control based on System.Windows.Forms.TabControl. I am painting the entire control myself in order to paint custom tabs and such. This was created for in-house use and I have never had to use a TabControl in which the tabs extend the visible tab area. However, I would like to implement this in case I do need it in the future. However, when I shrink the control so that the left/right scroll buttons appear at the top-right, the tabs do not display correctly.
Here is the code I currently have for drawing the tabs, which works perfectly when there is no scrolling involved:
int tabX = 4;
int tabY = 4;
foreach (TabPage page in this.TabPages)
{
SizeF textSize = g.MeasureString(page.Text, this.Font);
Rectangle tabRect = new Rectangle(tabX, tabY, ((int)textSize.Width + 16), ((int)textSize.Height + 8));
LinearGradientBrush tabBrush = new LinearGradientBrush(tabRect, ThemeManager.Instance.CurrentTheme.FormBackgroundColor,
ThemeManager.Instance.CurrentTheme.ButtonBackgroundDark, 90.0f);
g.FillRectangle(tabBrush, tabRect);
if (this.SelectedTab == page)
g.DrawRectangle(new Pen(ThemeManager.Instance.CurrentTheme.SelectedItemBorderColor), tabRect);
else
g.DrawRectangle(new Pen(ThemeManager.Instance.CurrentTheme.ToolStripBorderColor), tabRect);
StringFormat format = new StringFormat();
format.Alignment = StringAlignment.Center;
format.LineAlignment = StringAlignment.Center;
System.Drawing.Font font;
if (this.SelectedTab == page)
font = new System.Drawing.Font(this.Font, FontStyle.Bold);
else
font = this.Font;
g.DrawString(page.Text, font, Brushes.Black, tabRect, format);
tabX += (tabRect.Width + 4);
}
I know the code is a bit messy but right now I just want it to display correctly. This is mostly because I have never done this before so I am just trying to figure out how to make it LOOK right. Am I missing something here? I have looked at a few articles here on CodeProject which draw custom tabs. But I could not find anything in the code that handles this. I know it was done, I simply could not find where.
Any advice is appreciated. Thanks!
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
