C# equivalent of the SQL CASE statement?

Off Topic
1

No right or wrong answers, just looking for a cleaner way to do this.

So, I’m still no coder, but I will admit, setting variables in widgets is absurd when you have 24 to do like I am dealing with. So I’m doing this in C#. Yes, let’s hear it. I’m ready. :boxing_glove: :boxing_glove:

I started with the green commented-out section at the end (dataset field = input). That worked fine.

Then a lightbulb - if my user passes a blank (empty string) for a value, do I interpret that as

  • The user wants to overwrite the data to now be blank?
  • Or they just want to skip over it and leave it as the original value?

And the answer was that he wanted blank to mean “leave it alone.” On the flip side, if he wants to actually clear a field (set it to an empty string), we agreed to send over the string "NULL".

image
image1085×482 47.3 KB

So, the new code I made works fine, too. It’s just ugly. I did nested ternary operators () ? :

In short, it says:
field1 = (input1 == "") ? field1 : (input1 == "NULL") ? "" : input1

But it just seems excessive when I do it for 24 fields (this example has 9; another has 24).

If it were SQL, I’d write
case input1 when '' then field1 when 'NULL' then '' else input1 end

OK, I guess that’s literally the same length. But I guess my point is that it would scale better if I had more “whens.”

Anyway, if there’s some more intelligent strategy to this, please share.

2

What if you put the current value into all your fields? That way when you re-write their values to update, you don’t have to check if they wanted it to be blank vs. leave it alone.

3

I’m not grasping it, though it sounds elegant.

Can you maybe put that into pseudocode?

4

I’m not sure what your form looks like… but I’m saying display to the user in the fields they can edit what the current value is. Like bind the field to the appropriate view/column on that form. Then the fields would act like any other field where when you load the form, the existing values populate there and if you want to change them you can… or you can leave them as is.

5

Oh, OK, sure, I would, but I actually don’t control the frontend in this case (yes!).

So I asked the person who does, and that’s what he said he wanted, is that blank means leave it alone, and not actually blank.

6
1 Like
7

I’ll still play along.

What if you turned it into a function? something like this:

private static void UpdateValues(string fieldName, string updatedValue)
{
  switch (updatedValue)
  {
    case "":
      break;

    case "NULL":
      dsInspPart.UD13[0][fieldName] = "";
      break;

    default:
      dsInspPart.UD13[0][fieldName] = updatedValue;
      break;
  }
}

Then just looped through each value in a foreach statement and pass the fieldName and value into the function?

1 Like
8

Disclaimer: I used the term function in the generic sense… didn’t mean to write a function in Epicor… though you could do that also.

9

You also have a built in function:

String.IsNullOrEmpty(yourString), returns a boolean

1 Like
10

I think that is probably what my brain wanted.

So then my setter statements would just be

UpdateValues(field1, input1);
UpdateValues(field2, input2);
//etc...

I like this.

11

Either that or you could possibly have it loop through each column in the row but I’m not sure what that syntax would be. I’m used to looping through rows, not columns. So instead of writing UpdateValues 9 - 24 times you could write a single foreach statement that would be something like this:

foreach (var eachColumn in dsInspPart.UD13[0].Columns)
{
  UpdateValues(eachColumn.Name, eachColumn.Value);
}

But I have no idea if that’s even close to valid properties. Nor if there are more columns than the ones you mentioned that it would then try to update even if you didn’t want them to.

12

@dr_dan

Hmm, so is that not allowed in a code block widget?

image

13

Nope, you can’t make methods in BPM. But you can make actions (no return) or functions (returns something). You have to put them at the top of your code because they must be created before you call them, but once they are made, you can call them like any other method.

Add as many inputs as you need.

Action<string, string> WT = (myVar, myVar2) =>
    {
        //do stuff here, myVar, myVar2  are your parameters passed in
        
    };

Add as many inputs as you need, then the last one is your output.

Func<string, string> GetFunction = (inString) =>
{   
   
   //do stuff here using inString
  return myResult;
};

I’m not sure if my syntax is exactly right, but should be close enough for you to get the gist.

2 Likes
14

@Banderson

It sure is. This works:

image

I found Func by searching for the error on here, but I would never have known about Action.

Func would work, but I was returning a value for no good reason.

Sweet!

15

I like this; this is traditional VBA-style stuff. I’ve done plenty of Excel macros, so this is familiar.

Now, the adapters and all that… yikes. Give me widgets.

1 Like