|
hey guys!
does anybody have any experience
in C# ? i would need to read data (numbers) from
*.txt file and plot them in ZedGraph in Csharp
it is easy to make a plot of equestion
but i am suppose to plot bar graph like that:
v1 v2 v3 v4 v5
0122 4466 2847 2640 82800
0122 4466 2847 2640 82801
0122 4466 2847 2640 82802
0122 4466 2847 2640 82803
0122 4468 2847 2640 82804
0122 4468 2847 2640 82805
0122 4466 2847 2640 82806
0122 4466 2847 2640 82807
the task is easy, plot every
column seperately like bar
histogram. i have no idea
how to read data from .txt
i am a beginner and it´s
really important for me.
thx!
|
|
|
|
|
This sounds a lot like homework, so I won't give you full code!
Having said that, it's not a complex task, if you just break it down into the various parts:
1) Read data from text file
2) Convert data to numbers
3) Plot data
It's never that simple, though, because 2 and 3 will have some relationship, because ZedGraph will define what it want's in the form of data.
But the principles are the same.
1) Reading from a text file: easy!
string[] lines = File.ReadAllLines(pathToFile); That's it - all done.
2) Convert to numbers: Not too difficult.
First you need to repeat some action for each line, and convert a line into the various values to be plotted. Since your data appears to be separated by spaces, it would make sense to split teh line up on those and then convert the relevant numbers only.
Set up a foreach loop to work on each line of lines above (the info will be in your notes).
For each line, split iot on a space:
string[] parts = line.Split(' ');This gives you an array of separated values, as strings. It looks like you want to plot the second and fifth values since they are the only ones changing. So the strigns you will need to convert to numbers are parts[1] and parts[4] since C# always starts numbering at zero, not one.
To convert a numeric string to a numeber, use int.Parse:
int value = int.Parse(numericString); For example:
int value = int.Parse("123");Would give you the number one hundred and twenty-three in the variable value
3) Put the values together, and pass them to ZedGraph.
This bit is up to you - I don't use ZedGraph and don't want to look up for you how it expects it's data - you probably have some notes giving you a short cut on that anyway!
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
i really appreciate
your advice, and
i am going to try
applying you have
just written me.
Thank you very much!
|
|
|
|
|
You're welcome - good luck!
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
Hello!
I have a question regarding an unsafe code blocks in C#. As is well known, the following code:
int[] x = new int[10];
int* ptr;
fixed (int* fix = x)
{
ptr= fix;
}
*(ptr+1) = 123;
Is bad, because ptr is outside the fixed block and the array might be moved by GC. However, is the following code bad too?
int[] x = new int[10];
GCHandle xH = GCHandle.Alloc(x);
int* ptr;
fixed (int* fix = x)
{
ptr= fix;
}
*(ptr+1) = 123;
xH.Free();
If it is wrong, what is an alternative?
Greetings - Jacek
|
|
|
|
|
You should use the overload of Alloc that takes a GCHandleType, and pass GCHandleType.Pinned.
And then using fixed as well is confusing, but there is AddrOfPinnedObject which you can cast to a pointer.
|
|
|
|
|
Thank you!
What I actually wanted to do was to take fixed statements outside a loop. It's because I have discovered, that these statements bring an overhead and, therefore, a performance drop. So, I had an idea to "cache" pinned pointers but I couldn't use a fixed statement when outside a loop. Finally, here is a result:
string[] oldValues,
int oldCount = oldValues.Length;
GCHandle[] oldHandles = new GCHandle[oldCount];
for (int i = 0; i < oldCount; i++)
{
oldHandles[i] = GCHandle.Alloc(oldValues[i], GCHandleType.Pinned);
}
char* oldFix = oldHandles[i].AddrOfPinnedObject();
fixed (char* oldFix = oldValues[i])
This brought about 1.5x performance increase, so it was worth. But still I'm not sure if it is correct (and is hard to detect experimentally due to unpredictability of GC).
Edit: fixed fixed code
Greetings - Jacek
modified 27-Dec-11 13:15pm.
|
|
|
|
|
I don't know, I'm not 100% sure of this, but it looks to be fixing the strings temporarily and not long enough.
Jacek Gajek wrote: but I couldn't use a fixed statement when outside a loop
Why is this? I've written plenty of loops spanned by a fixed.
Not that many, granted, but I would say that usually when I use fixed, there is P/Invoke or a loop inside it.
edit: I would only use the GCHandle way to pin if something has to remain pinned for a long time or the pinning must survive returning from the function that pins it in a way that can not be refactored in a sane way (typically these things happen at the same time). Or in the rare case that a GCHandle is required anyway.
modified 27-Dec-11 12:49pm.
|
|
|
|
|
harold aptroot wrote: Why is this? I've written plenty of loops spanned by a fixed.
If you have a single pointer then it is possible. But if you had an array of strings A, then you cannot pull the fixed statement outside the loop since you do not have an indexer:
while(...)
for(int i = 0; i<len; i++)
{
fixed(char* str = A[i])
}
Solution:
GCHandle[] handles= new GCHandle[len];
for (int i = 0; i < len; i++)
{
handles[i] = GCHandle.Alloc(A[i], GCHandleType.Pinned);
}
while(...)
for(int i = 0; i<len; i++)
{
char* str = (char*)handles[i].AddrOfPinnedObject()
}
for (int i = 0; i < len; i++)
{
handles[i].Free();
}
Note: I use memcpy and memcmp inside, so yes there is some P/Invoke shift involved.
Greetings - Jacek
modified 27-Dec-11 13:15pm.
|
|
|
|
|
Oh ok, makes more sense now.
Why is the array pinned too though?
|
|
|
|
|
No special reason. It also caused a fatal exception. Now removed.
Greetings - Jacek
|
|
|
|
|
Sometimes I get "handle is unpinned" exception on AddrOfPinnedObject method call. Any ideas how is it possible? As I see in dotPeek, the exception is thrown because a condition ((int) this.m_handle & 1) != 0; is not satisfied. Since I do not call Free until the method's exit point, I really don't get how was it possible to happen  .
Greetings - Jacek
|
|
|
|
|
I don't know, that makes no sense to me.. I would almost say it's a bug in the CLR, but those are rare so I'm probably missing something
|
|
|
|
|
Jacek Gajek wrote: 1.5x performance increase
Compared to what?
And what, exactly, are you trying to accomplish?
|
|
|
|
|
Jacek Gajek wrote: If it is wrong
Probably.
Jacek Gajek wrote: what is an alternative
Set it within the fixed block?
|
|
|
|
|
PIEBALDconsult wrote: Set it within the fixed block?
Thank you for your interest, but I though it was obvious that for some reasons I need another solution than this. 
Greetings - Jacek
|
|
|
|
|
Jacek Gajek wrote: I though it was obvious
Obviously not. 
|
|
|
|
|
Understanding what you are doing and what you think you are achieving would help.
For example the following might or might not be relevant.
- Allocating a block or pool of blocks at application start and using those over and over might be better than any solution that requires re-allocating over and over.
- If you haven't profiled the application under a correct production model load (not test load) then attempting to optimize anything is futile.
|
|
|
|
|
hello guys... Lets suppose I have a TextBox on this Form1. Now when I resize the form, I want the resize the textbox as well. I have been trying to do this, but have not been able to get the <b>Size</b>, <b>Height </b>or <b>Width</b> property of Form1 in <b>IntelliSense</b>. I have <code>System.Drawing</code> in my code file as well.
|
|
|
|
|
Try Anchoring it to both sides of the Form.
|
|
|
|
|
Try TextBox1.Width TextBox1.Height or TextBox1.Dock would be better.
Frazzle the name say's it all
|
|
|
|
|
|
In addition to studying Anchor and Dock properties of Controls, as suggested here, you can also use aspects of Padding and Margin to affect the way Controls are positioned ... in relation to other Controls ... and/or in relation to Container Controls they are "placed within."
Note that WinForms, and many Controls, have MaximumSize and MinimumSize properties, that may affect their re-size behavior, depending on how they are anchored/docked, or affected by Margin, or Padding inside Container Controls, and/or in relation to the position of other Controls.
Specifically with a TextBox: I think an important design issue is what the expected content is: how brief, how long ? A single line TextBox is one beast; a MultiLine another ? Under some conditions I would not be concerned with re-sizing a TextBox; under other conditions: yes.
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
|
|
|
|
|
On a related note, Bill, how does one go about changing the font size when the size of the textbox changes? Is there a reasonably simple way to calculate the proper font size when the textbox is reduced, perhaps, 50%? Just curious...
Will Rogers never met me.
|
|
|
|
|
I once tried a WinForm experiment where I:
a. in the Form Load event:
1. did a recursive parsing of every Control on the Form, to locate all Controls that had a Font property (Labels, TextBoxes, etc.) that one might want to be changed when the Form was resized.
Each of these selected Controls, and their Font, were stored as Dictionary entries:
private Dictionary<Control, Font> cFontDict = new Dictionary<Control, Font>(); The initial Form Size was then stored.
b. in the Form SizeChanged EventHandler:
1. calculated change ratios in width and height based on the obvious.
2. traversed the Dictionary<control, font="">, via for-loop (so I could alter entries), and messed around with changing the Font based on the calculated change ratios.
WinForms does not make this easy since Control.Font.Size, and Control.Font.SizeInPoints are both read-only properties.
A look at the typical Font assignment code in a Designer.cs file:
this.textBox1.Font = new System.Drawing.Font("Arial", 15.75F, System.Drawing.FontStyle.Regular, System.Drawing.GraphicsUnit.Point, ((byte)(0)));Suggests the tediousness involved in changing the whole damn Font just to get a change in FontSize. I did this so long ago I forget exactly how I coded that up.
And what did I end up with: when the app was run, and the Form resized arbitrarily: a lot of bad-looking UI, with the Fonts often looking crummy. I forget whether I limited this to an experiment involving only certain types of Fonts (TrueType ?), or not.
After all, a change in FontSize means you need to have the AutoSize properties of TextBoxes, Labels, etc., set to 'True. And as their "container" size increases or decreases based on new line-height parameters, they then may be out of alignment with other fixed size Controls. So the container itself needs to be scaled.
So, the next step would have been to resize every Control by the same ratios, perhaps address special properties of certain Controls, like the ItemHeight of a ListBox ... but I never took that next step: because, by that time, I had already concluded that reasonable continuous scaling of Fonts in WinForms was a losing proposition, and that if I really had to have that functionality, I should change over to WPF where it appears to me that functionality is ready-to-go out-of-the-box.
The only scenario I can imagine, currently, in WinForms, where I might try to vary FontSize based on the changing Form Size would be one where some client demanded (and was willing to pay for) an App that "snapped" between two or four different sizes, where I could do the right thing, to make all the Fonts that needed to change look good at each size.
best, Bill
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
