Re: Modifying multiple fields based on a condition - C# Discussion Boards

Re: Modifying multiple fields based on a condition

Bice908-Feb-20 4:12

8-Feb-20 4:12

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.

Re: Modifying multiple fields based on a condition

Eddy Vluggen8-Feb-20 2:51

Eddy Vluggen

8-Feb-20 2:51

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 Suspicious | :suss:

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.

Re: Modifying multiple fields based on a condition

Bice908-Feb-20 4:15

Bice90

8-Feb-20 4:15

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!

Re: Modifying multiple fields based on a condition

phil.o8-Feb-20 3:04

phil.o

8-Feb-20 3:04

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);
}

// Usage:
Label1.Text = FormatVoltage(value1);
Label2.Text = FormatVoltage(value2);
// etc...

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."

Re: Modifying multiple fields based on a condition

Bice908-Feb-20 4:17

Bice90

8-Feb-20 4:17

Thank you for this very elegant solution for the formatting. I copied this because it is so nice! It works well.

Re: Modifying multiple fields based on a condition

phil.o8-Feb-20 4:53

phil.o

8-Feb-20 4:53

You're welcome!

"Five fruits and vegetables a day? What a joke!
Personally, after the third watermelon, I'm full."

Re: Modifying multiple fields based on a condition

Gerry Schmitz8-Feb-20 3:41

Gerry Schmitz

8-Feb-20 3:41

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

Re: Modifying multiple fields based on a condition

Bice908-Feb-20 4:25

Bice90

8-Feb-20 4:25

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.

Re: Modifying multiple fields based on a condition

Gerry Schmitz8-Feb-20 4:52

Gerry Schmitz

8-Feb-20 4:52

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

Re: Modifying multiple fields based on a condition

Bice908-Feb-20 6:22

Bice90

8-Feb-20 6:22

Yes, exactly what I am doing.

private void Myport_DataReceived(object sender, SerialDataReceivedEventArgs e)
{
in_data = serialPort.ReadLine(); //Reading one line from the serial port
this.Invoke(new Action(dataProcessing)); //start processing data
}

split = in_data.Split('\t'); 
//this is in the dataProcessing() method.

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.

C# Interviews on the horizon

Andrew Torrance7-Feb-20 3:11

Andrew Torrance

7-Feb-20 3:11

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.

Re: C# Interviews on the horizon

OriginalGriff7-Feb-20 3:52

OriginalGriff

7-Feb-20 3:52

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!

Re: C# Interviews on the horizon

Andrew Torrance7-Feb-20 6:51

Andrew Torrance

7-Feb-20 6:51

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).

Re: C# Interviews on the horizon

phil.o7-Feb-20 23:05

phil.o

7-Feb-20 23:05

New Features in C# 6.0[^]
New Features of C# 8[^]

These should keep you updated about new language features since C# 5.

"Five fruits and vegetables a day? What a joke!
Personally, after the third watermelon, I'm full."

Performance penalty of Debug.Assert in .NET

Rob Philpott4-Feb-20 23:44

Rob Philpott

4-Feb-20 23:44

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.

Re: Performance penalty of Debug.Assert in .NET

OriginalGriff4-Feb-20 23:57

OriginalGriff

4-Feb-20 23:57

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!

Re: Performance penalty of Debug.Assert in .NET

OriginalGriff5-Feb-20 0:17

OriginalGriff

5-Feb-20 0:17

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!

Re: Performance penalty of Debug.Assert in .NET

Rob Philpott5-Feb-20 0:36

Rob Philpott

5-Feb-20 0:36

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.

Re: Performance penalty of Debug.Assert in .NET

Richard Deeming5-Feb-20 0:44

Richard Deeming

5-Feb-20 0:44

Does your release build still have the DEBUG conditional compilation symbol defined?

Reference Source[^]
ConditionalAttribute Class (System.Diagnostics) | Microsoft Docs[^]

"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer

Re: Performance penalty of Debug.Assert in .NET

Rob Philpott5-Feb-20 1:13

Rob Philpott

5-Feb-20 1:13

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.

Re: Performance penalty of Debug.Assert in .NET

Rob Philpott5-Feb-20 0:40

Rob Philpott

5-Feb-20 0:40

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. Smile | :)

Regards,
Rob Philpott.

Re: Performance penalty of Debug.Assert in .NET

OriginalGriff5-Feb-20 1:23

OriginalGriff

5-Feb-20 1:23

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!

Re: Performance penalty of Debug.Assert in .NET

Luc Pattyn5-Feb-20 8:54