<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/">
	<channel>
		<title>Valence Forum - Valence 6.X Bug Reports</title>
		<link>https://forums.cnxcorp.com/web/</link>
		<description>Post suspected Valence 6.X bugs here.  Along with a description, please provide your simplified code that demonstrates how to replicate the bug.</description>
		<language>en</language>
		<lastBuildDate>Sat, 10 Oct 2026 15:12:07 GMT</lastBuildDate>
		<generator>vBulletin</generator>
		<ttl>60</ttl>
		<image>
			<url>images/misc/rss.png</url>
			<title>Valence Forum - Valence 6.X Bug Reports</title>
			<link>https://forums.cnxcorp.com/web/</link>
		</image>
		<item>
			<title>Form Fields Mapped to AppVariables Not Populating When Datasource Returns No Records</title>
			<link>https://forums.cnxcorp.com/web/forum/valence-bug-reports/valence-6-x-bug-reports/20690-form-fields-mapped-to-appvariables-not-populating-when-datasource-returns-no-records</link>
			<pubDate>Thu, 24 Sep 2026 18:40:28 GMT</pubDate>
			<description>On grid row click, a form is opened using a filter to retrieve a matching record. If a record is found, the form opens correctly and allows updates....</description>
			<content:encoded><![CDATA[On grid row click, a form is opened using a filter to retrieve a matching record. If a record is found, the form opens correctly and allows updates.<br />
If no matching record exists, the expected behavior is for the form to open in add mode and populate key fields using App Variables passed from the grid via field links to App Variables. This approach was working correctly previously, but appears to have stopped working in a recent release (unsure which release introduced the change).<br />
Currently, when no matching record exists:<ul><li>The form opens in add mode.</li>
<li>The App Variables contain the expected values.</li>
<li>Fields linked to those App Variables remain blank.</li>
</ul>]]></content:encoded>
			<category domain="https://forums.cnxcorp.com/web/forum/valence-bug-reports/valence-6-x-bug-reports">Valence 6.X Bug Reports</category>
			<dc:creator>atulmengane</dc:creator>
			<guid isPermaLink="true">https://forums.cnxcorp.com/web/forum/valence-bug-reports/valence-6-x-bug-reports/20690-form-fields-mapped-to-appvariables-not-populating-when-datasource-returns-no-records</guid>
		</item>
		<item>
			<title>Form Widgets Losing Original Order</title>
			<link>https://forums.cnxcorp.com/web/forum/valence-bug-reports/valence-6-x-bug-reports/20689-form-widgets-losing-original-order</link>
			<pubDate>Wed, 23 Sep 2026 18:11:22 GMT</pubDate>
			<description>Hello CNX, 
 
I have discovered that when I create a form widget in Valence, and the form widget has too many fields, then the order of the fields...</description>
			<content:encoded><![CDATA[Hello CNX,<br />
<br />
I have discovered that when I create a form widget in Valence, and the form widget has too many fields, then the order of the fields from top to bottom will change each time I save the widget (from the widget editor in Nitro App Builder).<br />
<br />
I have noticed that the nature of this bug (particularly the point where the order stops staying consistent between saves) is dependent on a variety of factors, such as ...<ul><li>If I have defined a number of columns for the form widget, instead of just using the default, which is 1 column (verified)</li>
<li>If I have placed any of the form fields into their own &quot;groups&quot; (verified)</li>
<li>How many fields are in each group (verified)</li>
<li>Maybe even the size of the fields (not verified, but I have seen evidence of this)</li>
</ul><br />
Because of all of these factors, this bug may be hard to narrow down, so I wanted to provide you with a simple example, so that narrowing down the source of the problem is easier for your team.<br />
<br />
<br />
Here is my example:<br />
<br />
<br />
Start by creating a data source.<br />
Select from the SysIBM.SysDummy1 table.<br />
Start making up fields, and all of them with the same exact hardcoded value of 1 (numeric)<br />
Name the first field &quot;field001&quot;, the second field &quot;field002&quot;, and so on.<br />
<br />
<br />
Here is an example that you can copy-and-paste:<br />
<br />
<span style="font-size:10px"><i><b>SELECT<br />
1 AS field001,<br />
1 AS field002,<br />
1 AS field003,<br />
1 AS field004,<br />
1 AS field005,<br />
1 AS field006,<br />
1 AS field007,<br />
1 AS field008,<br />
1 AS field009,<br />
1 AS field010,<br />
1 AS field011,<br />
1 AS field012,<br />
1 AS field013,<br />
1 AS field014,<br />
1 AS field015,<br />
1 AS field016,<br />
1 AS field017,<br />
1 AS field018,<br />
1 AS field019,<br />
1 AS field020,<br />
1 AS field021,<br />
1 AS field022,<br />
1 AS field023,<br />
1 AS field024,<br />
1 AS field025,<br />
1 AS field026,<br />
1 AS field027,<br />
1 AS field028,<br />
1 AS field029,<br />
1 AS field030,<br />
1 AS field031,<br />
1 AS field032,<br />
1 AS field033,<br />
1 AS field034,<br />
1 AS field035,<br />
1 AS field036,<br />
1 AS field037,<br />
1 AS field038,<br />
1 AS field039,<br />
1 AS field040,<br />
1 AS field041,<br />
1 AS field042,<br />
1 AS field043,<br />
1 AS field044,<br />
1 AS field045,<br />
1 AS field046,<br />
1 AS field047,<br />
1 AS field048,<br />
1 AS field049,<br />
1 AS field050,<br />
1 AS field051,<br />
1 AS field052,<br />
1 AS field053,<br />
1 AS field054,<br />
1 AS field055,<br />
1 AS field056,<br />
1 AS field057,<br />
1 AS field058,<br />
1 AS field059,<br />
1 AS field060,<br />
1 AS field061,<br />
1 AS field062,<br />
1 AS field063,<br />
1 AS field064,<br />
1 AS field065,<br />
1 AS field066,<br />
1 AS field067,<br />
1 AS field068,<br />
1 AS field069,<br />
1 AS field070,<br />
1 AS field071,<br />
1 AS field072,<br />
1 AS field073,<br />
1 AS field074,<br />
1 AS field075,<br />
1 AS field076,<br />
1 AS field077,<br />
1 AS field078,<br />
1 AS field079,<br />
1 AS field080,<br />
1 AS field081,<br />
1 AS field082,<br />
1 AS field083,<br />
1 AS field084,<br />
1 AS field085,<br />
1 AS field086,<br />
1 AS field087,<br />
1 AS field088,<br />
1 AS field089,<br />
1 AS field090,<br />
1 AS field091,<br />
1 AS field092,<br />
1 AS field093,<br />
1 AS field094,<br />
1 AS field095,<br />
1 AS field096,<br />
1 AS field097,<br />
1 AS field098,<br />
1 AS field099<br />
FROM<br />
sysibm.sysdummy1</b></i></span>​<br />
<br />
Then, make a form widget.<br />
Select &quot;field001&quot; first, then &quot;field002&quot; second, then &quot;field003&quot; third, and so on, so that the order of the fields matches the number on each field's label.<br />
That way, the order of the fields is easy to see.<br />
​<br />
<br />
<br />
If you create a widget like I described above, and the # of fields on that widget is any number between 1 and 99, you can define the order, save the widget, and open up the widget again in Nitro App Builder, and no matter how many times you open the widget back up again, the order that you defined will stay the same. It will always start with field001, then field002, all the way to field099.<br />
<br />
But, if you create that same widget again, with the fields defined and ordered in the exact same way, but this time, you create 100 fields instead of 99, then, if you save the widget and open up the widget again in Nitro App Builder, the order will not match the order that you defined before saving. As a matter of fact, the 100th field will now be placed between field019 and field020. If you save the widget again and open it back up a second time, field099 will now be placed between field019 and field100. And then after that, if you save the widget and open it up a third time, then field098 will now be placed between field019 and field099. Essentially, the field at position 100 at the point of saving will always be placed directly after the field at position 19 when opening back up the application.<br />
<br />
<br />
Now, I am never going to create a form with 100 fields, that are all numbers of length 1, in a 100-by1 grid.<br />
<br />
But I most certainly will create a form with various fields of various lengths and arrange them into a number of groups and columns.<br />
<br />
For example, I have recently created an application for my company that contains a form widget much like I described above. The fields within that form widget all have different data types and lengths, and they are currently arranged into 14 groups, with 6 columns per group, and one extra field below the 14 groups, giving me a total of 85 different fields ((6 * 14) + 1). Once I add a 15th group (with 6 columns), the order of the fields starts changing between saves. My users are wanting more than 14 groups, but I am limited to 14 because of this bug.<br />
<br />
<br />
<br />
In conclusion, it looks like there may be an issue with the underlying data in the widget editor in Nitro App Builder.<br />
<br />
Particularly, there seems to be an issue with whatever logic is responsible for ordering the fields.<br />
<br />
With the simple example used earlier, the logic seems to be failing after creating a form with 100 numbers of length 1.<br />
<br />
<br />
Can you look into this?<br />
<br />
Thank you for your time.<br />
<br />
<br />
- TonyDB]]></content:encoded>
			<category domain="https://forums.cnxcorp.com/web/forum/valence-bug-reports/valence-6-x-bug-reports">Valence 6.X Bug Reports</category>
			<dc:creator>TonyDB</dc:creator>
			<guid isPermaLink="true">https://forums.cnxcorp.com/web/forum/valence-bug-reports/valence-6-x-bug-reports/20689-form-widgets-losing-original-order</guid>
		</item>
	</channel>
</rss>
