1. Tracy Lamb
  2. PowerBuilder
  3. Wednesday, 20 April 2022 16:20 PM UTC

Hi all,

I'm upgrading most of the windows in my app, using PFC objects as much as possible.  I have 5 or 6 windows that use the tab object.  Is there a reason I would use the pfc tab object?  If I use the pfc tab object, do I also need to use the pfc tab page object?  The tab page objects in my app are dependent on instance variables defined in the window object so I'm not seeing how I could create tab objects that stand on their own.  If I define instance variables on each tab object, the I'd have to somehow set those values from the main window.  

Your thought are appreciated.

~~~Tracy

Accepted Answer
Tracy Lamb Accepted Answer Pending Moderation
  1. Friday, 20 May 2022 21:33 PM UTC
  2. PowerBuilder
  3. # Permalink

Here's what I decided...

I have a PFC u_tab ancestor object, utab_folder,  with 4 tab pages (not inherited from u_tabpg) and a u_dw object on each.  utab_folder has functionality that's common to all folders.

In the descendant folders, I add the data objects to the datawindows, and sometimes a few other controls (command buttons).  If I need more tabs, I just add them.  

In the past, I had a few different methods (evolution).  Two of the folders had all custom u_dw's and u_tabpage objects. I found that the levels of inheritance, etc made it very difficult to develop and debug.  For example, I replaced 8 separate user objects with just 1 folder object.

Open/Close/New/Exit are very simple because the utab_folder does the checking for updates for me.  I also use the PFC linking service between all of the u_dw objects on the various tabs.  All set up in the ancestor utab_folder, modified or extended as needed. Adding query/sort/filter where needed is also much easier.

Thanks all for your feedback on this issue,

~~~Tracy

 

Comment
There are no comments made yet.
PowerObject ! Accepted Answer Pending Moderation
  1. Sunday, 22 May 2022 21:52 PM UTC
  2. PowerBuilder
  3. # 1

If a tab/page is going to be re-used on multiple screens or modules, it may make sense to use the PFC objects. Otherwise, PFC tab/page results in code that is scattered all over the place as opposed to using standard tab/pages which will facilitate all the logic in one place on the window - readily accessible and easily maintainable. If the tab/pages are not going to be re-used, there is no benefit to complicating the application with using PFC tab/pages which results in too many superfluous ancestor tab/page objects that are hard to maintain.

Comment
  1. Tracy Lamb
  2. Monday, 23 May 2022 16:41 PM UTC
Helpful, but a little late to the game. 3 folders down, 1 to go.
  1. Helpful
  1. Tracy Lamb
  2. Thursday, 26 May 2022 18:23 PM UTC
Another reason to use the PFC tab object is that all folders share several features, like the FormID, as well as several events and function, such as open form, new form, print form, popup menu, etc.
  1. Helpful
  1. PowerObject !
  2. Thursday, 26 May 2022 22:19 PM UTC
Agree. Reuse stems from inheritance :)
  1. Helpful
There are no comments made yet.
Tracy Lamb Accepted Answer Pending Moderation
  1. Friday, 6 May 2022 12:17 PM UTC
  2. PowerBuilder
  3. # 2

Still testing a few things... hang tight!

~~~Tracy

Comment
There are no comments made yet.
Kevin Ridley Accepted Answer Pending Moderation
  1. Thursday, 21 April 2022 14:40 PM UTC
  2. PowerBuilder
  3. # 3

Getting values from the window is easy.  If you use the pfc objects, there's a of_getparentwindow function I believe (or something similar to that) that will give you a reference to the window.  I recommend having getter/setter methods on the window to get the values instead of just using dot notation - mywindowref.myvariable .

Comment
There are no comments made yet.
John Fauss Accepted Answer Pending Moderation
  1. Wednesday, 20 April 2022 16:54 PM UTC
  2. PowerBuilder
  3. # 4

Hi, Tracy - 

I've worked on several PFC-based applications over the last 25+ years, some internal-use only and some commercial, ranging in size from moderate to quite large -- all of them making fairly extensive use of the tab control.

I've rarely, if ever, seen the u_tab and u_tabpg objects used. The PFC does a very good job of recursively identifying all of the updateable objects (DW's, ostensibly) that are contained within the non-PFC-based tab pages of a non-PFC-based tab control for retrieval and updating via the Linkage service and Logical Unit-of-Work service, even when a tab page contains a "nested", secondary tab control that contains several tab pages.

The ancestor pfc_u_tabpg object is an empty "placeholder" object... it contains no code or properties, so there's no real functionality being added by using it.

One benefit of using the u_tab object is it helps you to implement a user-interface that is a little easier to update, whenever (or if) your GUI standards change, but IMHO that has not a major selling/benefit point in the applications I've worked over the years.

I'll be curious to learn what others in the Community have to say on this topic

HTH, John

Comment
  1. Venugopal r
  2. Friday, 30 September 2022 17:23 PM UTC
@Rene Ullrich, So you mean this is non resolvable issue in PB ?

Could you please suggest your thoughts to resolve this issue ?
  1. Helpful
  1. John Fauss
  2. Friday, 30 September 2022 17:57 PM UTC
If you are running into resource constraints using any framework's tab page user object versus a base, empty user object may be worse, since each instantiation of the framework's tab page object will necessitate the ancestor object(s) be instantiated also. Unless all 150 tab pages need to be instantiated and available for use simultaneously, I suggest you consider using CreateOnDemand, or OpenTab/MoveTab/CloseTab, and/or creating an alternative user interface.
  1. Helpful
  1. PowerObject !
  2. Monday, 3 October 2022 18:58 PM UTC
Here is a very MINOR enhancement ticket I submitted sometime back. It is a matter of enabling the disabled "Insert Tabpage" and "Insert UserObject" popup menu items at the WINDOW level on custom tab objects with a huge ROI that would reduce the number of superfluous custom tabpage objects that get created - scattering the code all over the place - even though most of them never get "re-used". With this change, developers can still implement custom tabpages the old fashioned way (insert in the custom tab object at the TAB level) or be able to insert system/custom tabpage/userobjects into a custom tab object at the WINDOW level.



Please vote on it if you like the idea -



https://www.appeon.com/standardsupport/track/view?id=8573
  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.
We use cookies which are necessary for the proper functioning of our websites. We also use cookies to analyze our traffic, improve your experience and provide social media features. If you continue to use this site, you consent to our use of cookies.