Hi Luca Muraca
I seen this normalization behaviour.In Mendix 11.4.0, the runtime changed how empty string values ('') are handled when passing objects between nanoflows and microflows they are now normalized to empty (null) values.
I heared this from few others also, but it is safer to use always the empty check instead of ''.
Jut to share that Mendix added a flag to avoif this kind of regression in 11.6.3
Hi,
After updating to Mendix 11.4.0, the platform changed how empty string ('') and empty/null values are handled when passing objects between nanoflows and microflows. In this version, '' values are now normalized to empty (null) when objects are passed back and forth.
This means expressions like:
$Object/Attr != ''
may no longer behave the same, because the value may now be empty instead of ''.
Don’t compare only to '' anymore
Use empty instead:
$Object/Attr != empty
or combine both if needed:
$Object/Attr != empty and trim($Object/Attr) <> ''
= '', <> '', != ''empty or trim() checks insteadThis change was introduced to normalize string handling between client and server.
All the points mentioned above are valid, but you didn’t take into account the effort required to find all the occurrences and the time needed to fix them without any automatic tool to search and replace the findings or assist the developer in fixing them. If you multiply this by multiple solutions with thousands of lines of code, I think it's too much just to “normalize” the behavior without any additional benefit (such as performance improvements).
Hi Luca,
Yes, this topic has been a long-standing and well-known topic. Developers who were aware of this issue have usually preferred to use $object/attribute != empty, because when $object/attribute != '' is used, the attribute can be null, which may lead to unexpected behavior. This became especially problematic with the conversions between nanoflows and microflows.
What Mendix has been doing in recent versions is trying to standardize this behavior. As you mentioned, they later introduced a setting to control it. In that sense, what you’re saying and what the others have said are not conflicting; they all point to the same underlying issue.
The real challenge is that there is no practical or automated way to apply this fix across a project. Because Mendix is low-code, the logic is encapsulated, and we don’t have a classic IDE-style global find-and-replace like in VS Code. On top of that, these comparisons are not only used in decisions. They can appear in many places such as page visibility settings, conditional logic inside Change Object activities, and other conditional configurations throughout the app.
Because of this, the most realistic approach is to use Studio Pro’s Edit → Find feature to manually search for patterns like != '', = '', or != empty. Since this can result in a lot of findings, the best way to handle it is to split the work across the team by assigning different modules to different developers so the effort is shared.
A follow up question; I see different answers regarding the usage of trim(). Will it still work properly if you use trim($Object/Attr) != '' ? Or will you need to add the empty check there as well?