1. Tim Rehder
  2. PowerBuilder
  3. Monday, 28 November 2022 11:28 AM UTC

Hello,

at our company we are currently in the process of migrating our relativly big PowerBuilder project to Git.
So far that has worked fairly well, but we have encountered an issue where it would be interesting to know how this was ment to work and how others are dealing with this.

The problem is that PowerBuilder moves the functions at the end of the exported source code of windows and other objects after they have been altered.

As long as only one person is working on that object this is not realy an issue. It is not ideal since you cannot see the actual changes that were made to the object, but only that the whole function has moved to the end of the source code. But this is not realy a big deal to us.

The actual problem are merge conflicts with such objects.
That is because you have to copy every modified function from the source code to a different comparrison tool to check if the function has been modified and then try to manualy pease these thigs together.

We have a few very big windows with a lot of functions and events.
As soon as two or more people have worked on one of those objects at the same time it is everything but easy to merge them together at the end.

Has someone here had some expirience with this problem and any ideas how we can avoid it in the future?

Are there any plans from appeon to approach this issue with the rearanged code in the exported files? Maybe an option in the PowerBuilder settings so that functions and events are exported in alphabetical order?

 

Armeen Mazda @Appeon Accepted Answer Pending Moderation
  1. Thursday, 1 December 2022 17:17 PM UTC
  2. PowerBuilder
  3. # 1

These problems are deep in the compiler that Appeon inherited from PB 12.x code base.... not sure if this problematic design was from PowerSoft or Sybase days.  Anyway, point is it requires a major revamp of the compiler to resolve and is not simply a bug.

In the next major version of PowerBuilder, as part of our plans to revamp the IDE, we also plan to also revamp the compiler.  You might even be able to see a preview/beta of the new compiler in the upcoming PowerBuilder 2022 R2.

Comment
  1. Armeen Mazda @Appeon
  2. Friday, 2 December 2022 16:12 PM UTC
We will definitely highlight this scenario to the engineering team, but the compiler also has issues.
  1. Helpful
  1. Tim Rehder
  2. Thursday, 8 June 2023 15:55 PM UTC
Hi Armeen,



the PowerBuilder 2022 R2 Beta is now available, but unfortunately this issue has not been addressed as far as I can tell.

Do you have any further information on this topic and how far the development is?
  1. Helpful
  1. Andreas Mykonios
  2. Friday, 9 June 2023 08:36 AM UTC
I don't think it's in 2022 R2. If there was a preview/beta of the new compiler in 2022 R2 Beta it would be mentioned to what's new section. But let's see what Armeen will answer. Another thing that need's to be clarified is about 2022 R2 release status. As I understood, it's now probable that 2022 R2 won't be an LTS version. If this is right it means we should expect an R3? That preview/beta of the new compiler may be in an R3? Finally when will we have an estimate of the timeframe we should expect the next Major Release?

Andreas.
  1. Helpful
There are no comments made yet.
Tobias Roth Accepted Answer Pending Moderation
  1. Tuesday, 29 November 2022 18:03 PM UTC
  2. PowerBuilder
  3. # 2

Hi Tim,

we have exactly the same problem. We have built our review process with MergeRequests in GitLab. As soon as the prototype of a function is changed or e.g. several objects are selected in DWs, blocks in the source code are moved.

I have already opened tickets for this in the past and hope that this problem will be addressed with the next major release. (new sourcecode editor, refactoring ...)

Bug 8208 - IDE: Codeblock moving (datawindow)
Bug 8086 - IDE: Block moving (prototype change / function name change)

Maybe Armeen or Julie here can make an official statement about this problem, whether it is already being worked on or something is planned.
I think that moving the source code blocks should bother everyone who works with source code management.

Moving makes any tracking of changes (e.g. git blame) or any review process very difficult.
The only workaround we sometimes use is to manually correct the moved blocks before committing.

Regards Tobi

 
Comment
  1. Tim Rehder
  2. Thursday, 1 December 2022 11:05 AM UTC
Hi Tobi,



thanks for your reply!

It´s good to know that Appeon is at least aware of this issue and hopefully workling on a solution.



Regards

Tim
  1. Helpful
  1. John Fauss
  2. Thursday, 8 June 2023 18:14 PM UTC
FWIW - We use a PB-cognizant diff tool (ProDiff, previously PBDelta) and it significantly reduces the impact of method signature changes. It's not a perfect tool, but it is a good tool. You can try free for 30 days: http://www.pbdr.com/prodiff/index.htm
  1. Helpful
There are no comments made yet.
Julie Jiang @Appeon Accepted Answer Pending Moderation
  1. Friday, 9 June 2023 08:56 AM UTC
  2. PowerBuilder
  3. # 3

Hi all, 

Now our engineering team has made some progress on their research of this "moved code block" issue and the new compiler.  We can now officially expect that these two features can become available in the next major version. 

Best regards, Julie

Comment
  1. Andreas Mykonios
  2. Friday, 9 June 2023 10:02 AM UTC
That's Great Julie. But next version after 2022 R2 will be a major release or not?

Andreas.
  1. Helpful
  1. Chris Pollach @Appeon
  2. Friday, 9 June 2023 12:11 PM UTC
Hi Andreas;

The next release will be PB 2022 R3 - estimated for Q1 2024. The next "major" PB version will be *after* R3.

Regards ... Chris
  1. Helpful 1
There are no comments made yet.
René Ullrich Accepted Answer Pending Moderation
  1. Monday, 28 November 2022 13:27 PM UTC
  2. PowerBuilder
  3. # 4

To avoid this problems I often use Edit Source tp change a function signature.

Comment
  1. René Ullrich
  2. Monday, 28 November 2022 14:08 PM UTC
Yes, it's not what I really want to do. It's only a workaround.
  1. Helpful
  1. Roland Smith
  2. Monday, 28 November 2022 14:34 PM UTC
I'm pretty sure that only happens when the function signature changes.
  1. Helpful 1
  1. René Ullrich
  2. Monday, 28 November 2022 14:40 PM UTC
No. It's also if you change the Front-to-Back-Order of controls or datawindow objects. :-(
  1. Helpful 2
There are no comments made yet.
Benjamin Gaesslein Accepted Answer Pending Moderation
  1. Monday, 28 November 2022 16:06 PM UTC
  2. PowerBuilder
  3. # 5

Hi Tim,

Powerbuilder's infuriating inabilty to leave the location of code blocks alone aside, I think having thousands of lines of code in a single UI object is a problem in and of itself. Breaking up the code into more usable chunks and using nonvisual objects to encapsulate connected functions might pay off in the long term. Many smaller classes will automatically lead to fewer conflicts because each developer only has to touch the one he needs to.

Comment
  1. Tim Rehder
  2. Tuesday, 29 November 2022 07:59 AM UTC
Hello Benjamin,

I completely agree with you. That is definitely a big part of the problem.

But still even if most functions and events are outsourced to nonvisual objects, the underlying problem still remains. Automatically changing the location of code blocks completely defeats the point of a version control like git. It would still be nearly impossible to figure out what kind of changes were actually made to windows with a lot of controls on them.

Does someone know if Appeon has ever said something on this topic?
  1. Helpful
  1. Roland Smith
  2. Tuesday, 29 November 2022 18:18 PM UTC
When PowerBuilder was first created, source control wasn't a consideration. It didn't become a IDE feature until version 4.



The z-order of objects is determined by the order they appear in the source code. Adding an actual z-order property would help with that problem.
  1. Helpful 2
  1. David Peace (Powersoft)
  2. Tuesday, 13 June 2023 15:04 PM UTC
There used to be a limit in number of lines that the compiler could handle. So we have always broken code out into userobjects. We only allow one person to work on a userobject/window at a time. If parallel projects require work on same components then we allocate all that work to the same developer, it's much more efficient. The person working on the code has already looked at it to understand what it does so making 1 or 2 changes makes no difference in time and you save the planning time for the second developer. Better still you are not wasting time managing merge issues and then fixing the bugs that creates. It’s all about proper project management at the higher level. It does require someone with that top level view.
  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.