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

[former_member451944]

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?

[Former Member]

I am having a similar problem with the treeview.  I am using the one from PFC_U_TV also, and when it is rendered at runtime, it just shows the top level.  Nothing else, will not expand.  It works as it should in the development environment and works as it should with Powerbuilder 11.5.

I am using PB 12.6 build 4098.

I went back to build 4081 as it was said it worked in that version.  I still have the same issue there.

I have updated my PFC.

I do believe a bug has been reported to SAP, but that is not helping me as of now. 

Anybody find a reliable solution?

[Former Member]

Not our case: we only had the problem of treeview windows freezing or blowing up. In debug it would blow up at different spots in the code, doing exactly the same thing, really weird.

After going back to build 4081, we had no problems with the treeviews. They also expand perfectly well.

I just checked now and see that we use the "u_tvs" and not the "u_tv". Don't know what's the difference right now, but maybe it could be a solution?

[Former Member]

Yes, I reported it as a bug, but then got tired of "having to provide them (SAP)" with a sample application that isolates and proves the problem, even after they recognized the problem was an existing one.

It seemed so obvious to me that if they fixed it in 4011 and now, after 4081 it's broken again, they still need me to prove it to them?

I just told them to forget about it and hoped Appeon was going to take over soon.

[Former Member]

Hi Miguel;

  I have passed along a "heads up" to the Appeon Engineering Team on this issue that you seem to have encountered on build 4098.

  Note that it may not be PB related. I've found beforehand that PowerSoft or Sybase changed the order or timing of an event. If your code does not expect that, and it doesn't use a lot of IsValid() logic - its easy to get into a GPF problem.

  I have done a lot of work on my frameworks to endure that the above event timing or order can be handled if they change from PB release to release. I don't think that the PFC ever was designed to adjust for this.

Regards ... Chris

Appeon: Director, Developer Relations

[Former Member]

Thanks for forwarding it to Appeon Chris,  (not sure if I mentioned it to Julie Y. previously)

Maybe you're right about the change in timing, but ... that still does not explain to me that opening a little window with a pfc treeview runs fine with powerbuilder 12.6, build 4081 (always) ... and (always) freezes with any later build of powerbuilder 12.6, doing exactly the same thing, same data, etc.

There's no powersoft or sybase involved between those two builds.

I also noted that timing and order of event executions seem to have changed.

I would have sworn that in previous versions (many ago) the constructor events of controls on a userobject would be executed before the constructor of the userobject itself, but not sure of how many versions ago, just like a windows' open() event would be triggered after the creation of the controls that it holds.

Or maybe it's just a different behaviour when you have userobjects on a tab and make use of the "createOnDemand" attribute. No energy to check on those things now.

The only thing I'm sure of right now, is that indeed you are right on not being able to blindly trust on the execution order of things.

regards,

Miguel

PS Happy to see you "on board" with Appeon, that's a good thing.

[Former Member]

Thanks Miguel!

Yes, you have to even be more diligent in your coding approach when using the "CreateOnDemand" feature as object instantiation - thus event timing & firing - changes for sure.

[former_member451944]

Good news!  PB 12.6 build 4011 fixed the issue.

I guess when a release breaks the way PFC works in a very noticeable way (even the current PFC version) then the issue will have already been noticed and possibly fixed.

It's a little curious, since we *just* installed PB12.6, which involves downloading the current install, that they don't include the patches.  Or at least mention them.

The SAP website is not very user friendly either.  Heh.

Ah well, all's well that ends well.

I'll take the idea of upgrading the PFC layer under advisement, ti's probably a good idea, but the product I support is in a fairly advanced portion of its life cycle, I'm more inclined to just let that issue lie as it hasn't been causing any problems until now.

[Former Member]

Ha!

Experiencing a very similar problem with the pfc treeview, doing sort of the same thing.

Beware: SAP might have fixed it in build 4011, but they seem to have "broken it again" in build 4088 and upwards: 4091.

At least that's what I found out "the hard way".

The last good build that does not give me the treeview problem is 4081, so I'll stick to that one.

Regards,

miguelL

[Former Member]

By the way John,

We recently upgraded to the latest PFC's, from a quit older one.

Delete your OLD PFC libraries, keep your old PFE's.

A good way to start is to first get rid of all the errors with "n_cst_platform***" by deleting them.

(..hpux, ...sol2, ...aix, ...., ...win32)

Keep only the "n_cst_platformUnicode" and "n_cst_platform"

The same goes for "n_cst_filesrv*****", keep only the main one and the ..Unicode one.

Then you might have to copy some of the new PFE objects which didn't exist in the old PFE versoin

That will give you a lot less errors to get you started with the migration:

Also, paste the following code in the constructor event of n_cst_platform if you are using 12.6 and not 12.5 of powerbuilder:

// T3, mjl, 06/01/16: adapt to pb 12.6 instead of 12.5 (see instance vars in ancestor class):

//Protected:

//string        is_separator

//string        is_ClassName[] = {"FNWND3125", "FNWNS3125"} // this is for pb 12.5

is_ClassName[1] = "FNWND3126" // pb 12.6

is_ClassName[2] = "FNWNS3126" // pb 12.6

regards,

MiguelL

[Former Member]

Hi John;

  First and foremost ... you should replace the old PFC layer with the PB 12.6 PFC version.  

FYI:  PFC - Home

  However, I see that the highest version on the site is still only v12.5.  

FWIW: I still have issues with PB 12.6 in various areas. All my Canadian government clients are either on PB 12.1 or 12.51 in production and working very well.

HTH

Regards ... Chris

[former_member451944]

Thanks!

I honestly have no idea how old the PFC libraries currently in use are.  Hah.

It's easy enough to try the 12.5 and see if there any improvement.  I'm slightly leery of losing changes made to the PFE layers, since this software has been around for so long and gone through several hands (software development house to in-house supported app).

EDIT:  Initial try at using 12.5 PFC doesn't seem promising, huge cascade of errors.  It seems as though the application code is referencing PFC functions and objects in a large number of places that are no longer present in PFC 12.5.

[Former Member]

Hi John;

Note: Never, ever, ever replace your PFE layer! Its yours to keep and protect as it has your applications specific changes.

Only the PFCxxxxx.pbls get replaced on an upgrade. 

Think of the PFC and PB as a "set of tires" on your car. You should never run mismatched tires (vendor, size, type, etc) for proper performance, handling & safety. You can use different tires on your car of course ... but, its never advised. Its the same for the PFC Vxxxx  on PB Vyyyy - your out of balance and eventually it will catch up with you. I just helped a major Canadian Government client last year migrate from PB 8 to PB 12.5.1 and they were encountering many stability & functional problems. After upgrading the PFC layer and some PFE refactoring I was able to address 80% of their issues on just that one area.

HTH

Regards .. Chris

[former_member190719]

However, I see that the highest version on the site is still only v12.5.   

http://pfc.codeplex.com/SourceControl/latest#12.6/

[former_member451944]

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.

[Former Member]

Hi John;

  Your TV issue could be rooted in PB 12.6 and not the PFC. While changing the PFC layer when upgrading is the recommended migration route - you may want to focus on seeing if a migrated PB 12.x. or 12.5.x will work for you first before tackling the PFC migration issue. Just my $0.02.

Regards ... Chris