Adding complex computed column at run-time fails in PB 12.6

Question

I support a large 'vintage' application that was originally written in the late 90's, and has been migrated from version to version over the years.  Currently I'm working to get it working in PB 12.6 Classic, build 3506, migrating it from PB 11.5
The first issue I've come across is that PFC treeviews are not working properly.  After some debugging, I determined that the cause of the failure is the PFC code's creation of 'key' column in the datawindows being used to populate each level.
In the pfc_u_tv.of_createkey function, it looks at the linkages between the levels of a treeviews data, and then crafts an expression, and then uses that to create a computed column, which is subsequently used to uniquely identify the data.
The expression is a series of string concatenations, such as this:
expression='String(ctg_cd) + "#$%" + String(app_cd) + "#$%" + String(app_cd) + "#$%" + String(win_id) + "#$%" + String(ctg_cd) + "#$%"'
This expression is then used in a modify statement to create the new compute key column:
ls_rc = ads_obj.Modify("create compute(band=detail x='0' y='0' " + &
  "height='0' width='0' name=pfc_tvi_key " + ls_Exp + ")")
In earlier versions, this works, and when you do a getitemstring afterward you get a long concatenated value that PFC uses to uniquely identify treeview items.
Such as 'a/r#$%plcy#$%plcy#$%w_m_plcy_fncl_tran#$%a/r#$%'
However, in PB 12.6, only the first portion of the expression is processed.  There is no error returned from the Modify function, and the column is created, but the expression is only evaluating one part of the expression.  In this partiular case, it results in
'plcy'
I just noticed that this isn't the *first* item in the set of concatenated columns and string literals, which is interesting.  In any case, when the computed key values are not correct, the whole method PFC is using to populate and run the treeview falls apart, and you get all children under each parent, and selections on the treeview object do not work properly because the key column values are not unique.
I can copy the expression value from a debugging session, and use that to create a computed column at design time, pasting the expression in, and naming it the same as the created column (pfv_tvi_key), and this then allows the treeview to work properly.  However, this is a very cumbersome and problematic workaround.  The application has a lot of treeviews, with a very large number of datawindows operating as all the different types of items on different levels of different trees.  I don't think it's a practical workaround, and future maintenance would be very difficult.
bu the workaround still demonstrates it is not an issue with the syntax of the compute expression, just an issue with the way it is handled by PowerBuilder when a column is created at run time,vs. at design time.
Has anyone else encountered this issue?  I would think there are a fair number of older apps still around that are using PFC treeviews.
My next step will be to install PB 12.6 build 4011 and cross my fingers.  Other than that, perhaps try 12.5?

Answer 1

Updating the PFC layers has started to lead down a rabbit hole of hundreds and hundreds of errors.
Granted, many of these are probably rooted in a few ancestor issues.
But I'm not sure this will lead to a solution.
The problem lies in using a modify statement to create a computed column at run time containing an expression with multiple concatenated values.
If I look at the pfc_u_tv.of_createkey function from the newer PFC version, I see the same code there:
ls_rc = ads_obj.Modify("create compute(band=detail x='0' y='0' " + &
  "height='0' width='0' name=pfc_tvi_key " + ls_Exp + ")")
And the same code above it which creates the expression used in the modify.
So after doing all the patching for the new PFC version, I somehow suspect I'll still be facing the same datastore.modify problem.
Not to say that isn't a good thing to do, just not sure it addresses the root of the problem.