Row-update expression formats?

Kinetic ERP
1

I’m using Kinetic 11.2.200. Where might I find examples of the different formats that can be used in the row-update expressions?

1 Like
2

If I understand what you’re looking for, it’s generally a string with placeholders …
like "{Dataview.Field}"
or if needed: "Contant string data {Dataview.Field}"

1 Like
3

It’s Javascript.
The only thing unique to App Studio is what @jwphillips mentioned for using fields.

4

I have seen expressions like ‘{Dataview.Field}’ and #‘(new Date(new Date().getFullYear() + 1, new Date().getMonth(), new Date().getDate())).toLocaleDateString()’#

I’m not sure when to use ‘{…}’ and when to use #’ … '#. I also don’t know if there are other allowable format. Do you know all of the formats that are acceptable?

2 Likes
5

I thought it was Javascipt and I’ve used Javascipt in the pass, but I don’t remember ever needed the #’ … '# before. Why that format?

1 Like
6

If you want to access the value in a dataview field.

I don’t actually know if this is still required but I still use it out of habit. It was an indicator that you were using Javascript (I think). Someone who knows more about JS than I do might be able to answer that.

3 Likes
7

Doesn’t appear to be. Might as well just ignore it for now. If something doesn’t work, add it back in and see if it helps, but it seems to work fine without it.

2 Likes
8

I wanted to take a column from one dataset and divide it by another number from a different column to produce a quotient that I will insert back into another column in the first dataset. Like this: ds1.Quotient = {ds1.Number} / {ds2.Number} when a button triggers a row-update event and I was unsure of the expression.

1 Like
9

It would look more like this:

#’ {ds1.Number} > 0 && {ds2.Number} > 0 ? {ds1.Number} / {ds2.Number} : 0 '#

Should this work?

10

Don’t put the single quotes unless you want it to evaluate into a string and during my brief test, you could probably do without the pound sign.

{ds1.Number} > 0 && {ds2.Number} > 0 ? {ds1.Number} / {ds2.Number} : 0
3 Likes
11

Thanks. I was confused when I saw the #’ formatting because I remember reading the ‘{fieldName}’ returned a string value and later read the plain {fieldName} would return a numeric value. When I saw #’ I assumed that was a way to execute javascript and wasn’t sure if there were more formats or not.

BTW, I’ve watched one of your videos and was totally impressed. I like the way you present!

1 Like
12

I have videos?? :sweat_smile:

1 Like
13

CoPilot told me the following:
a{text-decoration:none;color:#464feb}

In Epicor, the `#_’ syntax is used to wrap expressions to ensure they are evaluated correctly within the context of Business Activity Queries (BAQs) or other similar functionalities. This syntax helps in handling complex expressions, ensuring that they are interpreted as intended by the system.

For example, if you have a calculated field or a condition that needs to be evaluated, wrapping it with `#_’ ensures that the expression is processed correctly by Epicor’s query engine.

Is there a specific scenario or expression you’re working with that you need help with?

So do you think I should or shouldn’t use that format for my calculation?

14

If you test it and it works, then leave it out.
If it makes you nervous to exclude, keep them in.

As long as the expression works in your testing everything else doesn’t really matter.

1 Like
15

ChatGPT’s opinions for what it’s worth:

Why You Might Use #_ and _#:

  1. Explicitly Marking Dynamic Expressions:
  • Epicor’s Application Studio uses #_ and _# as delimiters to clearly identify and separate dynamic expressions from other static or non-executing content (like plain text, labels, or static fields).
  • Without these delimiters, Epicor might not know that the content between the markers should be treated as JavaScript, a calculation, or a dynamic field, especially in contexts where the system expects a runtime evaluation.
  • For instance, if you’re working with a form field or calculation, using #_ and _# makes it clear that the enclosed content should be dynamically evaluated based on the context when the form or process is run.
  1. Contextual Evaluation:
  • Dynamic behavior can vary depending on the surrounding context. In certain fields or sections of the application (such as user-defined fields, customization scripts, or business rules), Epicor expects dynamic expressions to be enclosed in #_ and _# to indicate that they should be evaluated dynamically.
  • If you omit these delimiters, the system may treat the expression as plain text, bypassing evaluation altogether, especially in cases where expressions are meant to interact with database fields, user input, or system variables.
  1. Preventing Errors or Unexpected Behavior:
  • When you’re working within customizations, especially in BPMs (Business Process Management), user-defined fields (UDFs), or custom forms, incorrect delimiters can lead to incorrect behavior or runtime errors.
  • The presence of #_ and _# helps prevent Epicor from interpreting the expression as a literal string rather than a dynamic, executable command. This is particularly important if you’re dealing with formulas, conditional logic, or date calculations.

When You Might Not Need #_ and _#:

In some cases, particularly if you’re simply embedding a JavaScript expression in a field or variable that doesn’t need explicit evaluation (e.g., when working in a script editor or calculated field), the system might be able to infer the dynamic nature of the content without the delimiters.

However, even in these cases, leaving out the #_ and _# markers could lead to ambiguity or issues if the context changes or if you later decide to use the expression in a different part of the application that requires explicit identification as a dynamic expression.

2 Likes