|
I think this message was meant for the OP.
|
|
|
|
|
I agree with Richard: have an array.
It might be worth doing it this way:
Create a class to hold the value and it's associated label. You can then create an array or other collection of class instances, and just loop through them, doing the same code once.
To help with that, override the ToString method in the class, and have it return the "human readable" value:
public class DisplayValue
{
public double Value { get; set; }
public Label Label { get; set; }
public override string ToString()
{
return Value < 1.0 ? (1000 * value).ToString("0.###") + " mV"
: Value.ToString("0.###") + " V";
}
}
That way, it can be rather more flexible than just setting a label value.
foreach (DisplayValue dv in Values)
{
dv.Label.Text = dv.ToString();
}
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Thank you for the very detailed response, I really appreciate it!
I made it with lists at this moment, just to clean up the code and test if I am able to do it. So far, it works, but I create a new branch for the code where I implement your solution.
|
|
|
|
|
Would be a good candidate to create a custom control; one that exposes the value, and has a dropdownlist to select the desired unit/multiplier for visualization purposes (meaning, without overwriting the value it is showing for editing).
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Thank you, this is a good idea! However, I only have either Volts or miliVolts, so I don't know if it is necessary to create a dropdown list just for two different units. But, when there's a broader range, I think it is a very good approach!
|
|
|
|
|
You could create a method which would take care of the formatting:
private static string FormatVoltage(double voltage)
{
return (voltage < 1d)
? string.Format("{0:f3} mV", 1000 * voltage)
: string.Format("{0:f3} V", voltage);
}
Label1.Text = FormatVoltage(value1);
Label2.Text = FormatVoltage(value2);
The advantage of this approch is that you define the logic in a single place, that you can use wherever you need. If you were to change the display format, you would then have to change it only in a single place.
"Five fruits and vegetables a day? What a joke!
Personally, after the third watermelon, I'm full."
|
|
|
|
|
Thank you for this very elegant solution for the formatting. I copied this because it is so nice! It works well.
|
|
|
|
|
You're welcome!
"Five fruits and vegetables a day? What a joke!
Personally, after the third watermelon, I'm full."
|
|
|
|
|
1) Every label will have a "parent", and that label will be a child of that parent's "control collection" which you can iterate without having to create a separate array.
2) The "values" can come from anywhere (you weren't specific). The "Tag" property of a label can be used to "address" these values.
3) Instead of creating a new "value class", you can define a "property" where the "getter" returns the appropriate string:
public string foo { get { return condition ? A : doSomething(A); } }
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Thank you for the answer!
To answer the 2nd point and make things more specific:
An Arduino Nano is sending values to the serial port in the following formatting:
value1 \t value2 \t ... value8 \n
Each new line of the above series of values will trigger an event handler which will start the processing of the data. Then, for example, I show the values in labels or plot them real time on a chart. Since, I want to filter what I want to see (e.g. only value5), I use check boxes to turn different channels on and off. This is where I needed the plenty of if statements.
|
|
|
|
|
Your "values" can be string.Split on "tabs / spaces" and you have your values array. If the values arrive "too fast", your event handler may be inadequate and you need to queue the results and handle them on a separate thread.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Yes, exactly what I am doing.
private void Myport_DataReceived(object sender, SerialDataReceivedEventArgs e)
{
in_data = serialPort.ReadLine();
this.Invoke(new Action(dataProcessing));
}
split = in_data.Split('\t');
The split is an array, where I take the channels as split[0], split[1]...etc. And yes, above ~500 samples/second, the data starts to lag and "pile up". I will do this queuing later, when I really need these high speeds.
|
|
|
|
|
I picked up C# in the early 2000's but I have been writing Python for the last 3 years but I am looking at moving back into C#. The last time I wrote C# proffesionally I remember .net Core being talked about but had not had a need to use it. If I had say a week to prepare for interviews are there any tips as to what should I read up on ?
Thanks in advance.
|
|
|
|
|
Probably lots: C# is not the language it was back in 2005 or so.
It has lambdas, generics, a bunch of different syntax added, and that's scratching the surface of .NET changes / .NET Core.
Back then, it didn't have var, much less dynamic, generic collections, Linq, anonymous methods, of quite of lot of the stuff we use everyday without thinking about. A week to catch up? That's pushing it ... I doubt you would get to the point where you'd impress enough at an interview to make it worth your investment. I'd go for a month, and get a good solid book - the update on the text you used back then might help - and see how far you can get.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I think you misunderstand, I was programming c# from alpha up to the end of 2016. I was using lambdas , var and dynamic at that point. I was using features of c# V5 with asynch and await , and using mvc 5.2 but I have not had my eye on the c# ball since then . So I am looking for anything that has caught on recently. E.g Being in the Mac and Linux world for the last 3 years I was excited by the potential of .net core, but I do not know what has really caught on. (trying to seperate the marketting hype from reality on the ground if that makes sense).
|
|
|
|
|
|
I'm writing some low level C# which is doing bit level operations (shifting/logic) which needs to be very high performance (real time application). Usually, I'd just do some checks and throw an exception if things aren't right, but I can't afford the overhead of that here.
Back in the day, in C++ I'd just use assertions for my checks which would cease to exist completely in the release build. In C#, we have Debug.Assert but its use seems greyer to me, because debug vs. release in .NET is greyer. Macros disappear depending on switches, but it seems the only way a Debug.Assert can disappear is if its hardedcoded in the JIT that way.
So my question I guess is does the Debug.Assert make it into the MSIL regardless of debug/release, and then does the JIT just remove it for release and remove it completely?
What happens with something like this in a release build, does the counter increment?
Debug.Assert(++counter != 100);
Regards,
Rob Philpott.
|
|
|
|
|
See here: Assertions in Managed Code - Visual Studio | Microsoft Docs[^]
Quote: In Visual Basic and Visual C#, you can use the Assert method from either Debug or Trace, which are in the System.Diagnostics namespace. Debug class methods are not included in a Release version of your program, so they do not increase the size or reduce the speed of your release code.
I'd be tempted to check with ILSpy, but I believe all the assertion code including the condition check are discarded in Release builds.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I just checked, and Debug.Assert is completely removed from Release code:
Code:
private void FrmMain_Shown(object sender, EventArgs e)
{
...
string[] dataWithCounts = dataFromTextBox.GroupBy(d => d).Select(g =>$"{g.Key}({g.Count()})").ToArray();
Debug.Assert(dataWithCounts.Count() != 3);
}
Debug:
IL_008c: call class [mscorlib]System.Collections.Generic.IEnumerable`1<!!1> [System.Core]System.Linq.Enumerable::Select<class [System.Core]System.Linq.IGrouping`2<string, string>, string>(class [mscorlib]System.Collections.Generic.IEnumerable`1<!!0>, class [mscorlib]System.Func`2<!!0, !!1>)
IL_0091: call !!0[] [System.Core]System.Linq.Enumerable::ToArray<string>(class [mscorlib]System.Collections.Generic.IEnumerable`1<!!0>)
IL_0096: stloc.1
IL_0097: ldloc.1
IL_0098: call int32 [System.Core]System.Linq.Enumerable::Count<string>(class [mscorlib]System.Collections.Generic.IEnumerable`1<!!0>)
IL_009d: ldc.i4.3
IL_009e: ceq
IL_00a0: ldc.i4.0
IL_00a1: ceq
IL_00a3: call void [System]System.Diagnostics.Debug::Assert(bool)
IL_00a8: nop
IL_00a9: ret
} // end of method FrmMain::FrmMain_Shown Release:
IL_0089: call class [mscorlib]System.Collections.Generic.IEnumerable`1<!!1> [System.Core]System.Linq.Enumerable::Select<class [System.Core]System.Linq.IGrouping`2<string, string>, string>(class [mscorlib]System.Collections.Generic.IEnumerable`1<!!0>, class [mscorlib]System.Func`2<!!0, !!1>)
IL_008e: call !!0[] [System.Core]System.Linq.Enumerable::ToArray<string>(class [mscorlib]System.Collections.Generic.IEnumerable`1<!!0>)
IL_0093: pop
IL_0094: ret
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
That's interesting. I just tried a similar thing with dotPeek, and the assertion is still visible in the release code, though your explanation above seems more plausible. Thanks for the link also - it backs up what you have above.
I'm wondering if there is some other optimization switch in play here which explains why I can still see it...
Regards,
Rob Philpott.
|
|
|
|
|
|
Nope, good thought though. TRACE is defined. Explanation is below, dotPeek uses the actual source rather than reconstituted when available, so it was showing even for the release build.
Regards,
Rob Philpott.
|
|
|
|
|
Ok explained. dotPeek will use the actual source when its available rather than disassemble. Indeed the assertion never makes into MSIL. I'm learning all sorts of new things today. 
Regards,
Rob Philpott.
|
|
|
|
|
Yeah, I like dotPeek, but that "use the source" bit has thrown me a couple of times.
ILSpy is a bit more basic, but sometimes that's exactly what you want.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Quote: a bit more basic, but sometimes that's exactly what you want.
We have a special forum for that 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
